dragger---依赖注入式框架

本人比较懒，为了加深自己的印象，一般都是看着别人的博客，然后自己打上去，也算是抄袭吧。传送门

依赖是什么

我的理解是，a和b，如果b要进行下一步操作，必须从a那里获得数据，那么b就是依赖a。

   private Module2 module2;
   public Module1(){
      module2 = new Module2();
   }
   public void doSomething(){
      ...
      module2.doSomethingElse();
      ...
   } 
}

我们可以看出1依赖2，
但是这样的依赖是有风险的，例如说2的构造方法发生了变化，如果让需要1进行操作，就不得不改变1里面的方法。那么我们应该怎么解决这样的问题呢，很好理解。
我们可以直接传递进去一个2的对象，而不是在里面new出来一个。那么问题来了，如果1中依赖有其他2，3，4，那么是不是说我们在其他地方new出来，这样看来似乎又是麻烦了。这时候我们就需要一个依赖注入器。

依赖注入器

怎么理解他呢，我觉得他就像一个针管，病人（1）需要什么药，我就给他什么注入什么药。而dragger就是一个依赖注入器。
学习dragger我们就必须了解一下注解的

什么是注解

Annotation(注解)是JDK1.5及以后版本引入的。它可以用于创建文档，跟踪代码中的依赖性，甚至执行基本编译时检查。注解是以‘@注解名’在代码中存在的，根据注解参数的个数，我们可以将注解分为：标记注解、单值注解、完整注解三类。它们都不会直接影响到程序的语义，只是作为注解（标识）存在，我们可以通过反射机制编程实现对这些元数据（用来描述数据的数据）的访问。另外，你可以在编译时选择代码里的注解是否只存在于源代码级，或者它也能在class文件、或者运行时中出现（SOURCE/CLASS/RUNTIME）。
那么dragger到底是干嘛的呢，我现在似乎有一个模糊的概念。
当引用类在使用的时候需要使用被引用类的对象，那么在寻常的条件下，我们必须要new出来这个，然而dragger2自动根据我们的声明生成这个被引用了类。那么它是怎么实现的呢？
这时候我们必须要了解，inject component，model

   class A{
        @Inject
        B b;
        }

   class B{
       @Inject
       B(){
       }
   }

a方法中引用b，为了让dragger自动为我们实例化，那么我们在a的方法里@inject注解，那么我们知道了要引用b的实例，dragger为我们自动创建，用哪个构造方法呢。于是在b的方法里，在其构造方法上面同样进行处理@inject。
这时候似乎a和b进行了微妙的关联，那么最终b的实例是由谁进行构建的呢？Component，他在引用类和被引用类之间起到了桥梁作用。 首先a需用以Component进行注解，于是Component通过@inject找到被引用的类b，随后进入b，再次@inject的构造方法。于是乎它开始初始化b，并进行赋值。
总结一下，Component现在是一个注入器，就像注射器一样，Component会把目标类依赖的实例注入到目标类中，来初始化目标类中的依赖。

那么问题来了，如果说我们要 引用的是第三方类库的c，那么我们总不可能对其构造方法加上@inject这些吧。当然dragger为我们进行了解决，把第三方类库的代码放在modul中，如下：

    @Module
    public class ModuleClass{
          //C是第三方类库中的一个类
          C provideC(){
               return C();
          }
    }

modul其实是一个简单的工厂模式，里面都是创建类的实例的方法。那么我们应该怎么把modul跟component进行关联呢？这时候，Provides开始登场了
component是一个桥梁作用，当它在目标类搜寻到inject，就会跑到module里面查找有Provides注解的方法，于是找到队形的方法创建实例。
贴出来参考的文章，传送门

Qualifier（限定符）、Singleton（单例）、Scope（作用域）

我们知道component是一个桥梁作用，可以从modul和inject注解标注的构造方法获得实例。那么总会有一个先后之分吧，那么component先从modul中进行寻找，如果找不到再次寻找@inject。
说到这里，加入我们的b方法有几个构造方法，无参和有参。那么我们怎么知道用哪个构造方法进行实例化呢。这叫做依赖注入迷失，怎么解决呢，我们可以对不同的构造方法进行标注，这样似乎解决了，这也就是
Qualifier（限定符）的作用了。

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

首页所有文章行业动态技术分享产品设计工具资源安卓小组更多频道▼
伯乐在线 > 安卓 - 伯乐在线 > 所有文章 > 技术分享 > dagger2 让你爱不释手：重点概念讲解、融合篇
dagger2 让你爱不释手：重点概念讲解、融合篇

2016/04/01 · 技术分享 · 1 评论 · dagger2
分享到： 4
本文作者： 伯乐在线 - 牛犇 。未经作者许可，禁止转载！
欢迎加入伯乐在线 专栏作者。
前言

《dagger2 让你爱不释手：基础依赖注入框架篇》这篇讲解了Inject，Component，Module，Provides是如何构成dagger2整个依赖注入框架的

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

我还是依然从抽象概念的角度讲解，讲解每个概念在整个依赖注入框架中到底起了什么作用，因为dagger2本身不容易上手，只有真正的了解了每个概念的作用，在使用时才会得心应手，大家别急，后面的章节会有dagger2的sample。

本节内容

Qualifier（限定符）、Singleton（单例）、Scope（作用域）、Component的组织方式概念讲解
dagger2能带来哪些实惠？
在讲解时，我还依然沿用上一节的讲解方式，由简入难不断深入的进行。
Qualifier（限定符）是什么鬼？

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

新的关系.png
创建类实例有2个维度可以创建：

通过用Inject注解标注的构造函数来创建（以下简称Inject维度）
通过工厂模式的Module来创建（以下简称Module维度）
这2个维度是有优先级之分的，Component会首先从Module维度中查找类实例，若找到就用Module维度创建类实例，并停止查找Inject维度。否则才是从Inject维度查找类实例。所以创建类实例级别Module维度要高于Inject维度。

现在有个问题，基于同一个维度条件下，若一个类的实例有多种方法可以创建出来，那注入器（Component）应该选择哪种方法来创建该类的实例呢？如下图，基于Inject维度：

Qualifier_迷失.png
我把上面遇到的问题起个名字叫依赖注入迷失。
那么可以给不同的创建类实例的方法用标识进行标注，用标识就可以对不同的创建类实例的方法进行区分（标识就如给不同的创建类实例方法起了一个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就是包含方式的具体实现。
Scope真正用武的时候了

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

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

dragger2的好处

1.增加开发效率，减少了很多不必要的重复的操作，例如不需要时刻进行new的操作
2 更好的管理类实例

每个app中的ApplicationComponent管理整个app的全局类实例，所有的全局类实例都统一交给ApplicationComponent管理，并且它们的生命周期与app的生命周期一样。

每个页面对应自己的Component，页面Component管理着自己页面所依赖的所有类实例。

因为Component，Module，整个app的类实例结构变的很清晰
3 假如不用dagger2的话，一个类的new代码是非常可能充斥在app的多个类中的，假如该类的构造函数发生变化，那这些涉及到的类都得进行修改。设计模式中提倡把容易变化的部分封装起来