我们想要一个咖啡机来做一杯咖啡，没有依赖注入的话，我们就需要在咖啡机里自己去new泵(pump)和加热器(heater)，而手动依赖注入的实现则将依赖作为参数，然后传入，而不是自己去显示创建。在没有依赖注入的时候，我们丧失了灵活性，因为一切依赖是在内部创建的，所以我们根本没有办法去替换依赖实例，比如想把电加热器换成火炉或者核加热器，看一看下图，是不是更清晰了：

为什么我们需要DI库

但问题在于，在大型应用中，把这些依赖全都分离，然后自己去创建的话，会是一个很大的工作量——毫无营养的公式化代码，一堆Factory类。不仅仅是工作量的问题，这些依赖可能还有顺序的问题，A依赖B，B依赖C，B依赖D，如此一来C、D就必须在A、B的后面，手动去做这些工作简直是一个噩梦 =。=（哈哈，是不是想到了appliation初始化那些依赖）。Google的工程师碰到的问题就是在Android上有3000行这样的代码，而在服务器上的大型程序则是100000行。

你会想自己维护这样的代码吗？

Why Dagger2

先来看看如果用Spring实现上面提到的咖啡机依赖，我们需要做什么：

不错，就是xml，当然，我们也不需要去关心顺序了，Spring会帮我们解决前后顺序的依赖问题。

但仔细想想，你会想去自己写这样的xml代码吗？layout.xml已经写得我很烦了。而且Spring是在运行时验证配置和依赖图的，你不会想在外网运行的app里让用户发现你的依赖注入出了问题的（比如bean名字打错了）。再加上xml和Java代码分离，很难追踪应用流。

Guice虽然较Spring进了一步，干掉了xml，通过Java声明依赖注入比起Spring好找多了，但其跟踪和报错（运行时的图验证）实在令人抓狂，而且在不同环境注入不同实例的配置也挺恶心的（if else各种判断），感兴趣的可以去看看，项目就在GitHub上，Android版本的叫RoboGuice。

而Dagger2和Dagger1的差别在上节已经提到了，更专注于开发者的体验，从半静态变为完全静态，从Map式的API变成申明式API（@Module），生成的代码更优雅，更高的性能（跟手写一样），更简单的debug跟踪，所有的报错也都是在编译时发生的。

Dagger2使用了JSR 330的依赖注入API，其实就是Provider了：

<span class="line" style="height: 20px;">1</span>
<span class="line" style="height: 20px;">2</span>
<span class="line" style="height: 20px;">3</span>
<span class="line" style="height: 20px;">4</span>
<span class="line" style="height: 20px;">5</span>
<span class="line" style="height: 20px;">6</span>
<span class="line" style="height: 20px;">7</span>

<span class="line" style="height: 20px;"><span class="keyword">public</span> <span class="class"><span class="keyword">interface</span> <span class="title">Provider</span>&lt;<span class="title">T</span>&gt; </span>{</span>
<span class="line" style="height: 20px;">  <span class="function">T <span class="title">get</span><span class="params">()</span></span>;</span>
<span class="line" style="height: 20px;">}</span>

<span class="line" style="height: 20px;"><span class="comment">// Usage:</span></span>
<span class="line" style="height: 20px;">Provider&lt;T&gt; coffeeMakerProvider = ...;</span>
<span class="line" style="height: 20px;">CoffeeMaker coffeeMaker = coffeeMakerProvider.get();</span>

Dagger2基于Component注解：

<span class="line" style="height: 20px;">1</span>
<span class="line" style="height: 20px;">2</span>
<span class="line" style="height: 20px;">3</span>
<span class="line" style="height: 20px;">4</span>
<span class="line" style="height: 20px;">5</span>
<span class="line" style="height: 20px;">6</span>
<span class="line" style="height: 20px;">7</span>
<span class="line" style="height: 20px;">8</span>
<span class="line" style="height: 20px;">9</span>

<span class="line" style="height: 20px;"><span class="annotation">@Component</span>(modules = DripCoffeModule.class)</span>
<span class="line" style="height: 20px;"><span class="class"><span class="keyword">interface</span> <span class="title">CoffeeMakerComponet</span> </span>{</span>
<span class="line" style="height: 20px;">  <span class="function">CoffeeMaker <span class="title">getCoffeeMaker</span><span class="params">()</span></span>;</span>
<span class="line" style="height: 20px;">}</span>

<span class="line" style="height: 20px;"><span class="comment">// 会生成这样的代码，Dagger_CoffeeMakerComponent里面就是一堆Provider，</span></span>
<span class="line" style="height: 20px;"><span class="comment">// 或者是单例，或者是通过DripCoffeeModule申明new的方式，开发者不必关心依赖顺序</span></span>
<span class="line" style="height: 20px;">CoffeeMakerComponent component = Dagger_CoffeeMakerComponent.create();</span>
<span class="line" style="height: 20px;">CoffeeMaker coffeeMaker = component.getCoffeeMaker();</span>

除了上面提到的各种好处，不得不提的是也有对应问题：丧失了动态性，在之后的实践中我会举个例子描述一下，但相对于那些好处来说，我觉得是可接受的。Everything has a Price to Pay。啊，对了，还有另一点，没法自动升级，从Dagger1到Dagger2，当然如果你的app是没有历史负担的（本系列的前提），那这不算问题。

如果对性能感兴趣的话，可以去看看

如上是一个我现在使用的Dagger2的依赖图的简化版子集。

ApplicationComponent作为root，拆分出了3个module

• ApplicationModule（application context，lbs服务，全局设置等）
• ApiModule（Retrofit那堆Api在这里）
• RepositoryModule（各种repository）。
  这里为了妥协内聚和简洁所以保持了这三个module。你不会想看到自己的di package下有一大堆module类，或者某个module里面掺杂着上百个实例注入的。

UserComponent用在用户主页、登录注册，以及好友列表页。所以你能看到UserModule（用户系统以及那些UseCase）以及需要的赞Module、相册Module。

TagComponent是标签系统，有自己的标签Module以及赞Module（module重用），用在了标签搜索、热门标签等页面。

是不是很好理解？位于上层的component是看不到下层的，而下层则可以使用上层的，但不能引用同一层相邻component内的实例。

如果你的应用是强登录态的，则更可以只把UserComponent放在第二层，Module构造函数传入uid（PerUser scope，没有uid则为游客态，供deeplink之类使用），而所有需要登录态的则都放在第三层。

一个简单的应用就是这样了，而Component继承，SubComponent（共享的放在上层父类），不同component的module复用（一样可以生成实例绑定，只是没法共享component中暴露的接口罢了）这些则是不同场景下的策略，如果有必要我会再开一篇讲讲这些深入的使用。

具体应用和心得体会

• No Proguard rules need。因为0反射，所以完全不需要去配置proguard规则。

• 因为需要静态地去inject，如果一些参数需要运行时通过用户行为去获得，就只能使用set去设置注入实例的参数（因为我们的injection通常在最早，比如onCreate就需要执行）。这就是上文提到过的，因为完全静态而丧失了一定的动态性。

• Singleton是线程安全的，请放心，如果实在怀疑，可以去检查生成的源码，笔者已经检查过了…

• 粒度的问题，如果基于页面去划分的话，老实说笔者觉得实在太细太麻烦，建议稍微粗一点，按照大功能去分，完全可以通过拆分module或者SubComponent的形式去解决复用的问题，而不用拆分出一大堆component，module只要足够内聚就可以，而不需要拆分到某个页面使用的那些。

• fragment的问题，因为其诡异的生命周期，所以建议在实在需要fragment的时候，让activity去创建component，fragment通过接口（比如HasComponent）去获得component（一个activity只能inject一个component哦）。

• 举一个我遇到的例子来说说方便的地方，有一个UseCase叫做SearchTag，原先只需要TagRepository，ThreadExecutor，PostThreadExecutor三个参数。现在需求改变了，需要在发起请求前先进行定位，然后把位置信息也作为请求的参数。我们只需要简单地在构造函数增加一个LbsRepository，然后在buildUseCaseObservable通过RxJava组合一下，这样既避免了底层repository的耦合，又对上层屏蔽了复杂性。

• 再讲讲之前提到的依赖吧，我们有很多同级的实例，以Singleton为例，比如有一个要提供给第三方sdk的Provider依赖了某个Repository，直接在构造函数里加上那个Repository，然后加上@Inject，完全不需要关心前后顺序了，省不省心？还可以随时在单元测试的包注入一个不需要物理环境的模拟repository。想想以前你怎么做，或者在调用这个的初始化前init依赖的实例，或者在初始化里去使用依赖类的getInstance()，是不是太土鳖？

• 强烈推荐你在自己的项目里使用上，初期可能怀着装逼的心情觉得有点麻烦，熟练后你会发现简直太方便了，根本离不开（其实是我的亲身经历 哈哈）。

总结

本篇讲了讲Dagger2，主要还是在安利为什么要用Dagger2，以及一些正确的使用姿势，因为时间原因来不及写个demo来说说具体实现，欢迎大家提出意见和建议。
有空的话我最近会在GitHub上写一下demo，你如果有兴趣可以follow一下等等更新:markzhai（希望在4月能完成，哈哈…）。

下集预告

怎么用Retrofit、Realm和RxJava搭建data层。

参考文献

• DAGGER 2 – A New Type of dependency injection: https://youtu.be/oK_XtfXPkqw
• Dagger 2 Official Site: http://google.github.io/dagger/
• Dagger 2 Design Doc: http://goo.gl/mW474Z

扩展阅读

• What determines the lifecycle of a component (object graph) in Dagger 2?
• Dependency injection with Dagger 2 – Custom scopes