前言
Android武器库中又增加了一项新技能——Dagger2。对于新手来说，最重要的是理解其中的概念，直接上代码难免会适得其反，当看到牛晓伟在简书上的博客后，豁然开朗。学习之后进行一下笔记和总结，主要是参考了以上博客，感谢作者的无私分享。
Gradle 配置
要在Android中使用Dagger2, 先添加Gradle配置，最新的版本可在GitHub找到。
Dagger 2
compile 'com.google.dagger:dagger:2.10'
annotationProcessor 'com.google.dagger:dagger-compiler:2.10'
基础依赖注入框架篇
概述
dagger2的大名我想大家都已经很熟了，它是解决Android或java中依赖注入的一个类库（DI类库）。当我看到一些开源的项目在使用dagger2时，我也有种匆匆欲动的感觉，因此就立马想一探它的究竟，到底能给我带来怎样的好处。在学习使用dagger2的过程中，我遇到了以下的一些困惑：
dagger2中的Inject, Component, Module, Provides 等等都是什么东东，有什么作用?
dagger2到底能带来哪些好处？
怎样把dagger2应用到具体项目中？
在具体学习dagger2的时候，看了好多博客，看的时候感觉挺简单的，但是在真正使用到项目中时候，脑袋就懵了，无从下手，Component应该怎么用，能放些什么方法? Module应该放些啥内容？Scope怎么起到作用域控制？…..各种疑问就横空而出。所以也许会有正在学习或即将要使用dagger2的同学在使用过程中遇到和我一样的困惑，因此我决定把我对dagger2的理解、使用经验分享给大家，希望能对大家有帮助。
正文
大纲
Inject，Component，Module，Provides 它们是什么？怎么去理解它们？各自有什么作用？主要从抽象的概念讲解，不会涉及到具体代码的剖析。
提前科普知识点
在讲解之前，我希望大家对以下知识点有所了解（知道的同学可以跳过）
- 依赖注入（Dependency Injection简称DI）
- java中注解(Annotation)
依赖注入：就是目标类（目标类需要进行依赖初始化的类，下面都会用目标类一词来指代）中所依赖的其他的类的初始化过程，不是通过手动编码的方式创建，而是通过技术手段可以把其他的类的已经初始化好的实例自动注入到目标类中。
正式开始
以下的内容我会尝试着去模仿dagger2的作者是怎样一步步完成dagger2这样伟大的依赖注入类库的场景来讲解（模仿该场景主要目的是为了能由简到难一步步更深入的了解dagger2）。
Inject是什么鬼
先看一段代码：
class A{
B b = new B(...);
C c = new C();
D d = new D(new E());
F f = new F(.....);
}
上面的代码完全没任何问题，但是总感觉创建对象的这些代码基本都是重复的体力劳动，那何尝不想个办法，把这些重复的体力劳动用一种自动化的、更省力的方法解决掉，这样就可以让开发的效率提高，可以把精力集中在重要的业务上了。
我们可以用注解(Annotation)来标注目标类中所依赖的其他类，同样用注解来标注所依赖的其他类的构造函数，那注解的名字就叫Inject。
class A{
@Inject
B b;
}
class B{
@Inject
B(){
}
}
这样我们就可以让目标类中所依赖的其他类与其他类的构造函数之间有了一种无形的联系。但是要想使它们之间产生直接的关系，还得需要一个桥梁来把它们之间连接起来。那这个桥梁就是Component了。
Component又是什么鬼
Component 也是一个注解类，一个类要想是Component，必须用Component注解来标注该类，并且该类是 接口或抽象类。我们不讨论具体类的代码，我想从抽象概念的角度来讨论Component。上文中提到Component在目标类中所依赖的其他类与其他类的构造函数之间可以起到一个桥梁的作用。
那我们看看这桥梁是怎么工作的：
Component需要引用到目标类的实例，Component会查找目标类中用 Inject注解标注的属性，查找到相应的属性后会接着查找该属性对应的用Inject标注的构造函数（这时候就发生联系了），剩下的工作就是初始化该属性的实例并把实例进行赋值。因此我们也可以给Component叫另外一个名字注入器（Injector）。
小结
目标类想要初始化自己依赖的其他类：
- 用Inject注解标注目标类中其他类；
- 用Inject注解标注其他类的构造函数；
- 若其他类还依赖于其他的类，则重复进行上面2个步骤；
- 调用Component（注入器）的injectXXX（Object）方法开始注入（injectXXX方法名字是官方推荐的名字,以inject开始）。
Component现在是一个注入器，就像注射器一样，Component会把目标类依赖的实例注入到目标类中，来初始化目标类中的依赖。
为啥又造出个Module
现在有个新问题：项目中使用到了第三方的类库，第三方类库又不能修改，所以根本不可能把Inject注解加入这些类中，这时我们的Inject就失效了。
那我们可以封装第三方的类库，封装的代码怎么管理呢，总不能让这些封装的代码散落在项目中的任何地方，总得有个好的管理机制，那Module就可以担当此任。
可以把封装第三方类库的代码放入Module中，像下面的例子：
@Module
public class ModuleClass{
//A是第三方类库中的一个类
A provideA(){
return A();
}
}
Module 其实是一个 简单工厂模式，Module里面的方法基本都是创建类实例的方法。接下来问题来了，因为Component是注入器（Injector），我们怎么能让Component与Module有联系呢？
Component的新职责
Component是注入器，它一端连接目标类，另一端连接目标类依赖实例，它把目标类依赖实例注入到目标类中。上文中的Module是一个提供类实例的类，所以Module应该是属于Component的实例端的（连接各种目标类依赖实例的端），Component的新职责就是管理好Module，Component中的modules属性可以把Module加入Component，modules可以加入多个Module。
那接下来的问题是怎么把Module中的各种创建类的实例方法与目标类中的用Inject注解标注的依赖产生关联，那Provides注解就该登场了。
Provides最终解决第三方类库依赖注入问题
Module中的创建类实例方法用Provides进行标注，Component在搜索到目标类中用Inject注解标注的属性后，Component就会去Module中去查找用Provides标注的对应的创建类实例方法，这样就可以解决第三方类库用dagger2实现依赖注入了。
总结
Inject，Component，Module，Provides是dagger2中的最基础最核心的知识点。奠定了dagger2的整个依赖注入框架。
- Inject主要是用来标注目标类的依赖和依赖的构造函数；
- Component它是一个桥梁，一端是目标类，另一端是目标类所依赖类的实例，它也是注入器（Injector）负责把目标类所依赖类的实例注入到目标类中，同时它也管理Module；
- Module 和 Provides 是为解决第三方类库而生的，Module是一个简单工厂模式，Module可以包含创建类实例的方法，这些方法用Provides来标注。
component-module
重点概念讲解、融合篇
概述
因为dagger2的整个依赖注入框架已经构建完成，所以dagger2中剩下的Qualifier（限定符）、Singleton（单例）、Scope（作用域）, SubComponent 概念基本都是在对整个依赖注入框架进行细节上的完善。
本节还是依然从抽象概念的角度讲解，讲解每个概念在整个依赖注入框架中到底起了什么作用，因为dagger2本身不容易上手，只有真正的了解了每个概念的作用，在使用时才会得心应手。
正文
大纲
- Qualifier（限定符）、Singleton（单例）、Scope（作用域）、Component的组织方式概念讲解；
- dagger2能带来哪些实惠？
在讲解时，还依然沿用上一节的讲解方式，由简入难不断深入的进行。
正式开始
Qualifier（限定符）是什么鬼？
上一节已经提到，Component是一个注入器（Injector），同时也起着桥梁的作用，一端是创建类实例端（创建类实例即负责生产类实例，下面会用该词来指代），另一端是目标类端（目标类需要进行依赖初始化的类，下面都会用目标类一词来指代），请看下图：
创建类实例有2个维度可以创建：
- 通过用Inject注解标注的构造函数来创建（以下简称Inject维度）；
- 通过工厂模式的Module来创建（以下简称Module维度）
这2个维度是有优先级之分的，Component会首先从Module维度中查找类实例，若找到就用Module维度创建类实例，并停止查找Inject维度。否则才是从Inject维度查找类实例。所以创建类实例级别Module维度要高于Inject维度。
现在有个问题，基于同一个维度条件下，若一个类的实例有多种方法可以创建出来，那注入器（Component）应该选择哪种方法来创建该类的实例呢？如下图，基于Inject维度：
我把上面遇到的问题起个名字叫依赖注入迷失。
那么可以给不同的创建类实例的方法用标识进行标注，用标识就可以对不同的创建类实例的方法进行区分（标识就如给不同的创建类实例方法起了一个id值）。同时用要使用的创建类实例方法的标识对目标类相应的实例属性进行标注。那这样我们的问题就解决了，提到的标识就是Qualifier注解，当然这种注解得需要我们自定义。
Qualifier（限定符）就是解决依赖注入迷失问题的。
注意：dagger2在发现依赖注入迷失时在编译代码时会报错。
Scope（作用域）你真是挺坑的一个东东
我们暂且不介绍Singleton，因为它是Scope的一个默认实现，理解了Scope自然就理解Singleton了。
为什么要说Scope比较坑呢，在刚开始接触Scope的时候，看了网上各种关于Scope的介绍，总结Scope的作用是：
Dagger2可以通过自定义Scope注解，来限定通过Module和Inject方式创建的类的实例的生命周期能够与目标类的生命周期相同。或者可以这样理解：通过自定义Scope注解可以更好的管理创建的类实例的生命周期。
网上也有各种例子比如：自定义一个PerActivity注解，那创建的类实例就与Activity“共生死“。
或者用Singleton注解标注一个创建类实例的方法，该创建类实例的方法就可以创建一个唯一的类实例。
我对PerActivity和Singleton这些魔法性的注解产生了好奇，同时也产生了迷惑？迷惑是：
- 自定义Scope注解到底是怎么工作的；
- 自定义的注解应该怎么定义名字，是不是定义一个名字就可以达到相应名字的效果。比如Singleton就可以实现单例，PerActivity就可以创建的类实例与Activity“共生死“，是不是我定义一个PerFragment的注解，同样可以达到创建的类实例就与Fragment“共生死“。大家别对我这幼稚的想法千万别见笑，当时我就把dagger2的Scope注解想的如此神通广大了
于是乎我在网上进行各种搜索，并且分析源码，最后的得到的结果也是让我大吃一惊。自定义的Singleton、PerActivity注解根本就没有这些功能。所以也可以说我被Scope坑了，或者是由于自己没有对Scope有一个深入的理解，被自己坑了。这先卖个关子，后面会具体介绍Scope。
Component组织方式重点中的重点
为什么说Component组织方式是重点中的重点呢？因为前面的各种概念都是在做铺垫工作，现在我们会从一个app的角度来把这些概念融合在一起。
一个app中应该根据什么来划分Component？
假如一个app（app指的是Android app）中只有一个Component，那这个Component是很难维护、并且变化率是很高，很庞大的，就是因为Component的职责太多了导致的。所以就有必要把这个庞大的Component进行划分，划分为粒度小的Component。那划分的规则这样的：
- 要有一个全局的Component(可以叫ApplicationComponent),负责管理整个app的全局类实例（全局类实例整个app都要用到的类的实例，这些类基本都是单例的，后面会用此词代替）；
- 每个页面对应一个Component，比如一个Activity页面定义一个Component，一个Fragment定义一个Component。当然这不是必须的，有些页面之间的依赖的类是一样的，可以公用一个Component。
第一个规则应该很好理解，具体说下第二个规则，为什么以页面为粒度来划分Component？
一个app是由很多个页面组成的，从组成app的角度来看一个页面就是一个完整的最小粒度了。
一个页面的实现其实是要依赖各种类的，可以理解成一个页面把各种依赖的类组织起来共同实现一个大的功能，每个页面都组织着自己的需要依赖的类，一个页面就是一堆类的组织者。
划分粒度不能太小了。假如使用mvp架构搭建app，划分粒度是基于每个页面的m、v、p各自定义Component的，那Component的粒度就太小了，定义这么多的Component，管理、维护就很非常困难。
所以以页面划分Component在管理、维护上面相对来说更合理。
Singleton没有创建单例的能力
为什么要谈到创建单例呢？因为上面谈到一个app要有一个全局的Component（我们暂且叫ApplicationComponent），ApplicationComponent负责管理整个app用到的全局类实例，那不可否认的是这些全局类实例应该都是单例的，那我们怎么才能创建单例？
上一节提到过Module的作用，Module和Provides是为解决第三方类库而生的，Module是一个简单工厂模式,Module可以包含创建类实例的方法。
现在Modlule可以创建所有类的实例。同时
Component会首先从Module维度中查找类实例，若找到就用Module维度创建类实例，并停止查找Inject维度。否则才是从Inject维度查找类实例。所以创建类实例级别Module维度要高于Inject维度。
所以利用以上2点，我们就可以创建单例。
- 在Module中定义创建全局类实例的方法；
- ApplicationComponent管理Module；
- 保证ApplicationComponent只有一个实例（在app的Application中实例化ApplicationComponent）。
dagger2中真正创建单例的方法就是上面的步骤，全局类实例的生命周期也和Application一样了，很关键的一点就是保证ApplicationComponent是只初始化一次。那估计有朋友就会问Singleton那岂不是多余的？
答案当然是 no no no。Singleton 有以下作用：
- 更好的管理ApplicationComponent和Module之间的关系，保证ApplicationComponent和Module是匹配的。若ApplicationComponent和Module的Scope是不一样的，则在编译时报错。
- 代码可读性，让程序猿更好的了解Module中创建的类实例是单例。
组织Component
我们已经把一个app按照上面的规则划分为不同的Component了，全局类实例也创建了单例模式。问题来了其他的Component想要把全局的类实例注入到目标类中该怎么办呢？这就涉及到类实例共享的问题了，因为Component有管理创建类实例的能力。因此只要能很好的组织Component之间的关系，问题就好办了。具体的组织方式分为以下3种：
依赖方式
一个Component是依赖于一个或多个Component，Component中的dependencies属性就是依赖方式的具体实现
包含方式
一个Component是包含一个或多个Component的，被包含的Component还可以继续包含其他的Component。这种方式特别像Activity与Fragment的关系。SubComponent就是包含方式的具体实现。
继承方式
官网没有提到该方式，具体没有提到的原因我觉得应该是，该方式不是解决类实例共享的问题，而是从更好的管理、维护Component的角度，把一些Component共有的方法抽象到一个父类中，然后子Component继承。
Scope真正用武的时候了
前面也提到Scope的一些基本概念，那Scope的真正用处就在于Component的组织。
- 更好的管理Component之间的组织方式，不管是依赖方式还是包含方式，都有必要用自定义的Scope注解标注这些Component，这些注解最好不要一样了，不一样是为了能更好的体现出Component之间的组织方式。还有编译器检查有依赖关系或包含关系的Component，若发现有Component没有用自定义Scope注解标注，则会报错。
- 更好的管理Component与Module之间的匹配关系，编译器会检查 Component管理的Modules，若发现标注Component的自定义Scope注解与Modules中的标注创建类实例方法的注解不一样，就会报错。
- 可读性提高，如用Singleton标注全局类，这样让程序猿立马就能明白这类是全局单例类。
app-architecture总结
关于dagger2概念性的东西基本都已经介绍完毕，剩下的比如Lazy、Provide等注解就不做介绍了，它们太简单了。同时也着重介绍了Scope，Qualifier等概念。还从整个app的角度来分析Component的组织方式。希望对大家能有帮助，因为dagger2上手还是比较复杂的，其实关键一点就是对于各种概念性的东东不了解，不知道它们到底有啥用途。所以我希望能帮到初学者对dagger2有一个整体性概念性的了解，然后在看网上的例子时能神清气爽。终结篇
正文
大纲
- dagger2到底能带来哪些好处？
- dagger2怎么使用？
正式开始
dagger2到底有哪些好处？
增加开发效率、省去重复的简单体力劳动
首先new一个实例的过程是一个重复的简单体力劳动，dagger2完全可以把new一个实例的工作做了，因此我们把主要精力集中在关键业务上、同时也能增加开发效率上。
省去写单例的方法，并且也不需要担心自己写的单例方法是否线程安全，自己写的单例是懒汉模式还是饿汉模式。因为dagger2都可以把这些工作做了。
更好的管理类实例
每个app中的ApplicationComponent管理整个app的全局类实例，所有的全局类实例都统一交给ApplicationComponent管理，并且它们的生命周期与app的生命周期一样。
每个页面对应自己的Component，页面Component管理着自己页面所依赖的所有类实例。
因为Component，Module，整个app的类实例结构变的很清晰。
解耦
假如不用dagger2的话，一个类的new代码是非常可能充斥在app的多个类中的，假如该类的构造函数发生变化，那这些涉及到的类都得进行修改。设计模式中提倡把容易变化的部分封装起来。
我们用了dagger2后。
假如是通过用Inject注解标注的构造函数创建类实例，则即使构造函数变的天花乱坠，我们基本上都不需要修改任何代码。
假如是通过工厂模式Module创建类实例，Module其实就是把new类实例的代码封装起来，这样即使类的构造函数发生变化，只需要修改Module即可。
有个网友问过一个这样的问题，Module的构造函数也会发生变化，发生变化后，相应的new Module的类也发生变化，这就没有达到解耦的效果。首先解耦不是说让类之间或模块之间真的一点关系都没有了，解耦达到的目的是让一个类或一个模块对与自己有关联的类或模块的影响降到最低，不是说这种影响就完全没有了，这是不可能的。
解耦还有个好处，就是方便测试，若需要替换为网络测试类，只需要修改相应的Module即可。
项目中使用dagger2注意点
具体的代码就不讲了，这里重点说下dagger2对目标类进行依赖注入的过程，现在假设要初始化目标类中的其中一个依赖类的实例，那具体步骤就在下面：
查找Module中是否存在创建该类的方法。
若存在创建类方法，查看该方法是否存在参数：
2.1. 若存在参数，则按从步骤1开始依次初始化每个参数；
2.2. 若不存在参数，则直接初始化该类实例，依次依赖注入到此结束；
若不存在创建类方法，则查找Inject注解的构造函数，看构造函数是否存在参数：
3.1. 若存在参数，则从步骤1开始依次初始化每个参数；
3.2. 若不存在参数，则直接初始化该类实例，依赖注入到此结束；
以上是dagger2进行的一次依赖注入的步骤，其实这个步骤是一个递归的过程，并且在查找类的实例的过程中Module的级别要高于Inject，这概念在上一篇讲过。
下面在说下注意的几点：
- 一个app必须要有一个Component（名字可以是ApplicationComponent）用来管理app的整个全局类实例
- 多个页面可以共享一个Component
- 不是说Component就一定要对应一个或多个Module，Component也可以不包含Module
- 自定义Scope注解最好使用上，虽然不使用也是可以让项目运行起来的，但是加上好处多多。
总结
好了关于dagger2的所有的概念知识点到此终于结束了，希望能帮助大家，与大家共勉，有问题可以随时与我沟通。
dagger2 sample地址
再次感谢原作者！！！
