Dagger2重点概念讲解

前言

dagger2的整个依赖注入框架已经构建完成，所以dagger2中剩下的Qualifier（限定符）、Singleton（单例）、Scope（作用域）,SubComponent概念基本都是在对整个依赖注入框架进行细节上的完善。

Qualifier（限定符）

上一节已经提到，Component是一个注入器（Injector），同时也起着桥梁的作用，一端是创建类实例端（创建类实例即负责生产类实例，下面会用该词来指代），另一端是目标类端（目标类需要进行依赖初始化的类，下面都会用目标类一词来指代），请看下图：

创建类实例有2个维度可以创建：

• 通过用Inject注解标注的构造函数来创建（以下简称Inject维度）
• 通过工厂模式的Module来创建（以下简称Module维度）
  这2个维度是有优先级之分的，Component会首先从Module维度中查找类实例，若找到就用Module维度创建类实例，并停止查找Inject维度。否则才是从Inject维度查找类实例。所以创建类实例级别Module维度要高于Inject维度。
  现在有个问题，基于同一个维度条件下，若一个类的实例有多种方法可以创建出来，那注入器（Component）应该选择哪种方法来创建该类的实例呢？如下图，基于Inject维度
  

我把上面遇到的问题起个名字叫依赖注入迷失。
那么可以给不同的创建类实例的方法用标识进行标注，用标识就可以对不同的创建类实例的方法进行区分（标识就如给不同的创建类实例方法起了一个id值）。同时用要使用的创建类实例方法的标识对目标类相应的实例属性进行标注。那这样我们的问题就解决了，提到的标识就是Qualifier注解，当然这种注解得需要我们自定义。

Qualifier（限定符）就是解决依赖注入迷失问题的。
注意 dagger2在发现依赖注入迷失时在编译代码时会报错。

Scope

Dagger2可以通过自定义Scope注解，来限定通过Module和Inject方式创建的类的实例的生命周期能够与目标类的生命周期相同。或者可以这样理解：通过自定义Scope注解可以更好的管理创建的类实例的生命周期。

Component组织方式

一个app中应该根据什么来划分Component？

假如一个app（app指的是Android app）中只有一个Component，那这个Component是很难维护、并且变化率是很高，很庞大的，就是因为Component的职责太多了导致的。所以就有必要把这个庞大的Component进行划分，划分为粒度小的Component。那划分的规则这样的：

要有一个全局的Component(可以叫ApplicationComponent),负责管理整个app的全局类实例（全局类实例整个app都要用到的类的实例，这些类基本都是单例的，后面会用此词代替）
每个页面对应一个Component，比如一个Activity页面定义一个Component，一个Fragment定义一个Component。当然这不是必须的，有些页面之间的依赖的类是一样的，可以公用一个Component。

Singleton没有创建单例的能力

• 在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就是包含方式的具体实现。

Scope

前面也提到Scope的一些基本概念，那Scope的真正用处就在于Component的组织。

• 更好的管理Component之间的组织方式，不管是依赖方式还是包含方式，都有必要用自定义的Scope注解标注这些Component，这些注解最好不要一样了，不一样是为了能更好的体现出Component之间的组织方式。还有编译器检查有依赖关系或包含关系的Component，若发现有Component没有用自定义Scope注解标注，则会报错。
• 更好的管理Component与Module之间的匹配关系，编译器会检查 Component管理的Modules，若发现标注Component的自定义Scope注解与Modules中的标注创建类实例方法的注解不一样，就会报错。

• 可读性提高，如用Singleton标注全局类，这样让程序猿立马就能明白这类是全局单例类。
  

假设要初始化目标类中的其中一个依赖类的实例，那具体步骤就在下面：

1. 步骤1：查找Module中是否存在创建该类的方法。

2. 步骤2：若存在创建类方法，查看该方法是否存在参数
   • 步骤2.1：若存在参数，则按从步骤1开始依次初始化每个参数
   • 步骤2.2：若不存在参数，则直接初始化该类实例，一次依赖注入到此结束
3. 步骤3：若不存在创建类方法，则查找Inject注解的构造函数，看构造函数是否存在参数
   • 步骤3.1：若存在参数，则从步骤1开始依次初始化每个参数
   • 步骤3.2：若不存在参数，则直接初始化该类实例，一次依赖注入到此结束

下面在说下注意的几点

• 一个app必须要有一个Component（名字可以是ApplicationComponent）用来管理app的整个全局类实例
• 多个页面可以共享一个Component
• 不是说Component就一定要对应一个或多个Module，Component也可以不包含Module
• 自定义Scope注解最好使用上，虽然不使用也是可以让项目运行起来的，但是加上好处多多。