初衷
Dagger2的初衷就是通过依赖注入让你少些很多公式化代码，更容易测试，降低耦合，创建可复用可互换的模块。你可以在Debug包，测试运行包以及release包优雅注入三种不同的实现。
依赖注入
使用依赖注入可以带来以下好处：
- 依赖的注入和配置独立于组件之外。
- 因为对象是在一个独立、不耦合的地方初始化，所以当注入抽象方法的时候，我们只需要修改对象的实现方法，而不用大改代码库。
- 依赖可以注入到一个组件中：我们可以注入这些依赖的模拟实现，这样使得测试更加简单。
举个栗子，如下图所示，左边是没有依赖注入的实现方式，右边是手动的依赖注入：
我们想要一个咖啡机来做一杯咖啡，没有依赖注入的话，我们就需要在咖啡机里自己去new泵(pump)和加热器(heater)，而手动依赖注入的实现则将依赖作为参数，然后传入，而不是自己去显示创建。在没有依赖注入的时候，我们丧失了灵活性，因为一切依赖是在内部创建的，所以我们根本没有办法去替换依赖实例，比如想把电加热器换成火炉或者核加热器，看一看下图，是不是更清晰了：
为什么我们需要DI库
但问题在于，在大型应用中，把这些依赖全都分离，然后自己去创建的话，会是一个很大的工作量——毫无营养的公式化代码，一堆Factory类。不仅仅是工作量的问题，这些依赖可能还有顺序的问题，A依赖B，B依赖C，B依赖D，如此一来C、D就必须在A、B的后面，手动去做这些工作简直是一个噩梦 =。=（哈哈，是不是想到了appliation初始化那些依赖）。Google的工程师碰到的问题就是在Android上有3000行这样的代码，而在服务器上的大型程序则是100000行。
Dagger2
想要了解Dagger2，就必须要知道依赖注入的基础和这其中的每一个概念：
- @Inject: 通常在需要依赖的地方使用这个注解。换句话说，你用它告诉Dagger这个类或者字段需要依赖注入。这样，Dagger就会构造一个这个类的实例并满足他们的依赖。
- @Module: Modules类里面的方法专门提供依赖，所以我们定义一个类，用@Module注解，这样Dagger在构造类的实例的时候，就知道从哪里去找到需要的 依赖。modules的一个重要特征是它们设计为分区并组合在一起（比如说，在我们的app中可以有多个组成在一起的modules）。
- @Provide: 在modules中，我们定义的方法是用这个注解，以此来告诉Dagger我们想要构造对象并提供这些依赖。
- @Component: Components从根本上来说就是一个注入器，也可以说是@Inject和@Module的桥梁，它的主要作用就是连接这两个部分。 Components可以提供所有定义了的类型的实例，比如：我们必须用@Component注解一个接口然后列出所有的@Modules组成该组件，如 果缺失了任何一块都会在编译的时候报错。所有的组件都可以通过它的modules知道依赖的范围。
- @Scope: Scopes可是非常的有用，Dagger2可以通过自定义注解限定注解作用域。后面会演示一个例子，这是一个非常强大的特点，因为就如前面说的一样，没 必要让每个对象都去了解如何管理他们的实例。在scope的例子中，我们用自定义的@PerActivity注解一个类，所以这个对象存活时间就和 activity的一样。简单来说就是我们可以定义所有范围的粒度(@PerFragment, @PerUser, 等等)。
- Qualifier: 当类的类型不足以鉴别一个依赖的时候，我们就可以使用这个注解标示。例如：在Android中，我们会需要不同类型的context，所以我们就可以定义 qualifier注解“@ForApplication”和“@ForActivity”，这样当注入一个context的时候，我们就可以告诉 Dagger我们想要哪种类型的context。
使用示例
使用示例需要参考别人的博文，比如如下图片
参考详解Dagger2 泡在网上的日子
另一张图是
参考从零开始的Android新项目4 - Dagger2篇
当然最权威的示例是谷歌提供的，在github上已经开源了，请戳googlesamples/android-architecture
