Dagger2浅析

一、Dagger2简介

Dagger2起源于Dagger，是一款基于Java注解来实现的完全在编译阶段完成依赖注入的开源库，主要用于模块间解耦、提高代码的健壮性和可维护性。Dagger2在编译阶段通过apt利用Java注解自动生成Java代码，然后结合手写的代码来自动帮我们完成依赖注入的工作。

可见，Dagger2框架的核心编程思想：依赖注入（DI）
那么，什么是依赖注入呢？
这里，谈起依赖注入，做过J2EE开发的同学一定会想起Spring框架中的：控制反转（IoC）

此处借鉴了几位技术大神的文章，通俗易懂，特此分享：

• Iteye对 IoC 和 DI 的理解，原文地址：https://jinnianshilongnian.iteye.com/blog/1413846
• 门心叼龙对Dagger2的理解，原文地址：https://blog.csdn.net/geduo_83/article/details/90380191
• Val0050对Dagger2的理解，原文地址：https://www.open-open.com/lib/view/open1482201981550.html#articleHeader6

二、Dagger2核心

Dagger2框架的核心编程思想：控制反转（IoC）和依赖注入（DI）

2.1 控制反转（IoC）是什么？

IoC—Inversion of Control，即“控制反转”，不是什么技术，而是一种设计思想。在Java开发中，IoC意味着将你设计好的对象交给容器控制，而不是传统的在你的对象内部直接控制。

如何理解好IoC呢？理解好IoC的关键是要明确“谁控制谁，控制什么，为何是反转（有反转就应该有正转了），哪些方面反转了”，那我们来深入分析一下：

• 谁控制谁，控制什么：传统Java SE程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建依赖对象；而IoC是有专门一个容器来创建这些对象，即由Ioc容器来控制对 象的创建；谁控制谁？当然是IoC 容器控制了对象；控制什么？那就是主要控制了外部资源获取（不只是对象包括比如文件等）。

• 为何是反转，哪些方面反转了：有反转就有正转，传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象，也就是正转；而反转则是由容器来帮忙创建及注入依赖对象；为何是反转？因为由容器帮我们查找及注入依赖对象，对象只是被动的接受依赖对象，所以是反转；哪些方面反转了？依赖对象的获取被反转了。

用图例说明一下，传统程序设计如图2-1，都是主动去创建相关对象然后再组合起来：

当有了IoC/DI的容器后，在客户端类中不再主动去创建这些对象了，如图2-2所示:

IoC不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。

其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。

IoC很好的体现了面向对象设计法则之一——好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。

2.2 依赖注入（DI）是什么？

DI—Dependency Injection，即“依赖注入”：组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。

依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。

理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：

• 谁依赖于谁：当然是应用程序依赖于IoC容器；
• 为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
• 谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
• 注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

2.3 IoC 和 DI 有什么关系呢？

其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。

2.4 三种常见的依赖注入方式

2.4.1、构造注入： 通过给构造函数传参给依赖的成员变量赋值，从而实现注入。

public class Car{
   

    private Engine engine;

    public Car(Engine engine){
   
        this.engine = engine;
    }
}

2.4.2、接口注入： 实现接口方法，同样以传参的方式实现注入。

public interface Injection<T>{
   

    void inject(T t);
}

public class Car implements Injection<Engine>{
   

    private Engine engine;

    public Car(){
   }

    public void inject(Engine engine){
   
        this.engine = engine;
    }

}

2.4.3、注解注入： 使用Java注解在编译阶段生成代码实现注入或者是在运行阶段通过反射实现注入。

public class Car{
   

    @Inject
    Engine engine;

    public Car(){
   }
}

前两种注入方式需要我们编写大量的模板代码，而机智的Dagger2则是通过Java注解在编译期来实现依赖注入的。

三、Dagger2注解

Dagger2是基于Java注解来实现依赖注入的，那么在正式使用之前我们需要先了解下Dagger2中的注解。Dagger2使用过程中我们通常接触到的注解主要包括：@Inject, @Module, @Provides, @Component, @Qulifier, @Scope, @Singleten。

• @Inject：@Inject有两个作用，一是用来标记需要依赖的变量，以此告诉Dagger2为它提供依赖；二是用来标记构造函数，Dagger2通过@Inject注解可以在需要这个类实例的时候来找到这个构造函数并把相关实例构造出来，以此来为被@Inject标记了的变量提供依赖；

• @Module：@Module用于标注提供依赖的类。你可能会有点困惑，上面不是提到用@Inject标记构造函数就可以提供依赖了么，为什么还需要@Module？很多时候我们需要提供依赖的构造函数是第三方库的，我们没法给它加上@Inject注解，又比如说提供以来的构造函数是带参数的，如果我们之所简单的使用@Inject标记它，那么他的参数又怎么来呢？@Module正是帮我们解决这些问题的。

• @Provides：@Provides用于标注Module所标注的类中的方法，该方法在需要提供依赖时被调用，从而把预先提供好的对象当做依赖给标注了@Inject的变量赋值；

• @Component：@Component用于标注接口，是依赖需求方和依赖提供方之间的桥梁。被Component标注的接口在编译时会生成该接口的实现类（如果@Component标注的接口为CarComponent，则编译期生成的实现类为DaggerCarComponent）,我们通过调用这个实现类的方法完成注入；

• @Qulifier：@Qulifier用于自定义注解，也就是说@Qulifier就如同Java提供的几种基本元注解一样用来标记注解类。我们在使用@Module来标注提供依赖的方法时，方法名我们是可以随便定义的（虽然我们定义方法名一般以provide开头，但这并不是强制的，只是为了增加可读性而已）。那么Dagger2怎么知道这个方法是为谁提供依赖呢？答案就是返回值的类型，Dagger2根据返回值的类型来决定为哪个被@Inject标记了的变量赋值。但是问题来了，一旦有多个一样的返回类型Dagger2就懵逼了。@Qulifier的存在正式为了解决这个问题，我们使用@Qulifier来定义自己的注解，然后通过自定义的注解去标注提供依赖的方法和依赖需求方（也就是被@Inject标注的变量），这样Dagger2就知道为谁提供依赖了。----一个更为精简的定义：当类型不足以鉴别一个依赖的时候，我们就可以使用这个注解标示；

• @Scope：@Scope同样用于自定义注解，我能可以通过@Scope自定义的注解来限定注解作用域，实现局部的单例；

• @Singleton：@Singleton其实就是一个通过@Scope定义的注解，我们一般通过它来实现全局单例。但实际上它并不能提前全局单例，是否能提供全局单例还要取决于对应的Component是否为一个全局对象。

我们提到@Inject和@Module都可以提供依赖，那如果我们即在构造函数上通过标记@Inject提供依赖，有通过@Module提供依赖Dagger2会如何选择呢？具体规则如下：

• 步骤1：首先查找@Module标注的类中是否存在提供依赖的方法。
• 步骤2：若存在提供依赖的方法，查看该方法是否存在参数。
  a：若存在参数，则按从步骤1开始依次初始化每个参数；
  b：若不存在，则直接初始化该类实例，完成一次依赖注入。
• 步骤3：若不存在提供依赖的方法，则查找@Inject标注的构造函数，看构造函数是否存在参数。
  a：若存在参数，则从步骤1开始依次初始化每一个参数
  b：若不存在，则直接初始化该类实例，完成一次依赖注入。

四、Dagger2使用

前面长篇大论的基本都在介绍概念，下面我们看看Dagger2的基本应用。我们还是拿前面的Car和Engine来举例。

1、案例A

Car类是需求依赖方，依赖了Engine类；因此我们需要在类变量Engine上添加@Inject来告诉Dagger2来为自己提供依赖。

public class Car {
   

    @Inject
    Engine engine;

    public Car() {
   
        DaggerCarComponent.builder().build().inject(this);
    }

    public Engine ge