Dagger2 入门解析

谁践踏了优雅 2022-02-02 07:31 299阅读 0赞

![demo-uml.svg][]

# 前言 #

在为dropwizard选择DI框架的时候考虑了很久。Guice比较成熟，Dagger2主要用于Android。虽然都是google维护的，但Dagger2远比guice更新的频率高。再一个是，Dagger2不同于guice的运行时注入，编译时生成代码的做法很好。提前发现问题，更高的效率。

还是那句话，百度到的dagger2资料看着一大堆，大都表层，而且和Android集成很深。很少有单独讲Dagger2的。不得已，去看官方文档。

# HelloWorld #

官方的example是基于maven的，由于maven天然结构的约定，compile的插件生成可以和maven集成的很好。而我更喜欢gradle，gradle随意很多，结果就是编译结构需要自己指定。

demo source： [https://github.com/Ryan-Miao/l4dagger2][https_github.com_Ryan-Miao_l4dagger2]

结构如下：

.
    ├── build.gradle
    ├── gradle
    │   └── wrapper
    │       ├── gradle-wrapper.jar
    │       └── gradle-wrapper.properties
    ├── gradlew
    ├── gradlew.bat
    ├── readme.md
    ├── settings.gradle
    └── src
        └── main
            ├── java
            │   └── com
            │       └── test
            │           └── l4dagger2
            │               └── hello
            │                   ├── CoffeeApp.java
            │                   ├── CoffeeMaker.java
            │                   ├── DripCoffeeModule.java
            │                   ├── ElectricHeater.java
            │                   ├── Heater.java
            │                   ├── Pump.java
            │                   ├── PumpModule.java
            │                   └── Thermosiphon.java
            ├── resources
            └── webapp
    
    11 directories, 15 files

# 加载依赖 #

build.gradle

plugins {
        id "net.ltgt.apt" version "0.12"
        id "net.ltgt.apt-idea" version "0.12"
        id "net.ltgt.apt-eclipse" version "0.12"
    }
    
    
    repositories {
        mavenLocal()
        maven {
            url "http://maven.aliyun.com/nexus/content/groups/public/"
        }
        mavenCentral()
    }
    
    group 'com.test'
    version '1.0-SNAPSHOT'
    
    apply plugin: 'java'
    apply plugin: 'war'
    apply plugin: 'idea'
    
    sourceCompatibility = 1.8
    
    
    dependencies {
        compile 'com.google.dagger:dagger:2.12'
        apt 'com.google.dagger:dagger-compiler:2.12'
    
        testCompile group: 'junit', name: 'junit', version: '4.12'
    }

**Note that**：

*  `plugins`插件需要放到最开头。然后，由于设计编译时生成sourceSet类，针对IDE需要添加对应的插件。
 *  `dagger2`生成的类放在`build/generated/source/apt/main`

# Coding Time #

接下来的内容就和官方的demo一样了。

com.test.l4dagger2.hello.CoffeeApp

public class CoffeeApp {
        @Singleton
        @Component(modules = { DripCoffeeModule.class })
        public interface CoffeeShop {
            CoffeeMaker maker();
        }
    
        public static void main(String[] args) {
            CoffeeShop coffeeShop = DaggerCoffeeApp_CoffeeShop.builder().build();
            coffeeShop.maker().brew();
        }
    }

com.test.l4dagger2.hello.DripCoffeeModule

@Module(includes = PumpModule.class)
    class DripCoffeeModule {
        @Provides
        @Singleton
        Heater provideHeater() {
            return new ElectricHeater();
        }
    }

com.test.l4dagger2.hello.PumpModule

@Module
    abstract class PumpModule {
        @Binds
        abstract Pump providePump(Thermosiphon pump);
    }

com.test.l4dagger2.hello.Pump

interface Pump {
        void pump();
    }

com.test.l4dagger2.hello.Thermosiphon

class Thermosiphon implements Pump {
        private final Heater heater;
    
        @Inject
        Thermosiphon(Heater heater) {
            this.heater = heater;
        }
    
        @Override public void pump() {
            if (heater.isHot()) {
                System.out.println("=> => pumping => =>");
            }
        }
    }

com.test.l4dagger2.hello.Heater

interface Heater {
        void on();
        void off();
        boolean isHot();
    }

com.test.l4dagger2.hello.ElectricHeater

class ElectricHeater implements Heater {
        boolean heating;
    
        @Override public void on() {
            System.out.println("~ ~ ~ heating ~ ~ ~");
            this.heating = true;
        }
    
        @Override public void off() {
            this.heating = false;
        }
    
        @Override public boolean isHot() {
            return heating;
        }
    }

com.test.l4dagger2.hello.CoffeeMaker

class CoffeeMaker {
        private final Lazy<Heater> heater; // Create a possibly costly heater only when we use it.
        private final Pump pump;
    
        @Inject
        CoffeeMaker(Lazy<Heater> heater, Pump pump) {
            this.heater = heater;
            this.pump = pump;
        }
    
        public void brew() {
            heater.get().on();
            pump.pump();
            System.out.println(" [_]P coffee! [_]P ");
            heater.get().off();
        }
    }

针对`DaggerCoffeeApp_CoffeeShop`不识别问题，运行编译后就可以了。

sh gradlew build

# 结果 #

Run main method

~ ~ ~ heating ~ ~ ~
    => => pumping => =>
     [_]P coffee! [_]P

# 用法分析 #

Dagger暴露的最外层为component，而Component的注入来自module。Component之间不能互相注入，module之间可以互相注入。  
![dagger%E8%B0%83%E7%94%A8%E5%B1%82%E6%AC%][dagger_E8_B0_83_E7_94_A8_E5_B1_82_E6_AC]

## 注入原理 ##

编译时扫描注解，生成对应的builder和factory。这点和spring不同，spring是运行时通过反射生成instance。另一个问题就是由于是静态工厂，那么就不能动态绑定了。不过可以通过其他的手段弥补。

以下来自[详解Dagger2][Dagger2]

*  @Inject: 通常在需要依赖的地方使用这个注解。换句话说，你用它告诉Dagger这个类或者字段需要依赖注入。这样，Dagger就会构造一个这个类的实例并满足他们的依赖。
 *  @Module: Modules类里面的方法专门提供依赖，所以我们定义一个类，[用@Module注解][Module]，这样Dagger在构造类的实例的时候，就知道从哪里去找到需要的 依赖。modules的一个重要特征是它们设计为分区并组合在一起（比如说，在我们的app中可以有多个组成在一起的modules）。
 *  @Provide: 在modules中，我们定义的方法是用这个注解，以此来告诉Dagger我们想要构造对象并提供这些依赖。  
    @Component: Components从根本上来说就是一个注入器，[也可以说是@Inject和@Module的桥梁][Inject_Module]，它的主要作用就是连接这两个部分。
 *  Components可以提供所有定义了的类型的实例，比如：[我们必须用@Component注解一个接口然后列出所有的@Modules组成该组件][Component_Modules]，如 果缺失了任何一块都会在编译的时候报错。所有的组件都可以通过它的modules知道依赖的范围。
 *  @Scope: Scopes可是非常的有用，Dagger2可以通过自定义注解限定注解作用域。后面会演示一个例子，这是一个非常强大的特点，因为就如前面说的一样，没 必要让每个对象都去了解如何管理他们的实例。在scope的例子中，[我们用自定义的@PerActivity注解一个类][PerActivity]，所以这个对象存活时间就和 activity的一样。简单来说就是我们可以定义所有范围的粒度(@PerFragment, @PerUser, 等等)。
 *  Qualifier: 当类的类型不足以鉴别一个依赖的时候，我们就可以使用这个注解标示。例如：在Android中，我们会需要不同类型的context，所以我们就可以定义 qualifier注解“@ForApplication”和“@ForActivity”，这样当注入一个context的时候，我们就可以告诉 Dagger我们想要哪种类型的context。

## 1. 入口 ##

@Singleton
    @Component(modules = { DripCoffeeModule.class })
    public interface CoffeeShop {
        CoffeeMaker maker();
    }

dagger中Component就是最顶级的入口，dagger为之生成了工厂类`DaggerCoffeeApp_CoffeeShop`, 目标是构建`CoffeeMaker`， 在`CoffeeMaker`中使用了`Injection`，那么依赖要由工厂类来提供。工厂类是根据`modules`的参数来找依赖绑定的。

本例中，指向了`DripCoffeeModule`，意思是`CoffeeMaker`的依赖要从这个module里找。

**工厂名称生成规则**

*  如果Component是接口, 则生成`Dagger`\+接口名
 *  如果Component是内部接口，比如本例，则生成`Dagger`\+类名+ `_`\+ 接口名

## 2. 依赖管理 ##

module看起来似乎和spring里的configuration有点相似，负责声明bean。**而且同样支持继承，子module拥有父亲的元素**。 这点和spring的context也很像，子context可以从父context里获取instance。对应的Java里的继承也同样，子类可以使用父类的属性和方法。

这里可以把`DripCoffeeModule`当做父类，而`PumpModule`为子类。  
![module-extend.svg][]

但是， **引用注入的时候却和spring相反，module之间** ！

在spring里，子context拥有所有的bean，所以在子context里可以注入任何bean。而父context只能注入自己声明的bean。

而在dagger2的这个module里，module可以看做是一个打包。最外层的包显然包含了所有的bean。因此，在`CoffeeShop`中引入的是父module `DripCoffeeModule`。在子module `PumpModule`中的`Thermosiphon`可以注入声明在`DripCoffeeModule`里的`Heater`实例。

当然，造成这个问题的原因是生成的时候的顺序有关。调整下顺序，把`PumpModule`引入Component里，然后，把`DripCoffeeModule` include到`PumpModule`里。此时一样没啥问题，只是掉了个。不同的是，父子对调导致Pump变成了父亲的元素，Heater成了子类的元素。然而，一样可以将heater注入到Pump。为啥？等看了源码再了解，这里先搞定用法scop。*猜测会不会是在创建Pump的时候发现缺少Heater，然后压栈，去子module里找声明，找到后，弹出栈*。

Anyway，demo的注入就是这么简单。module起到定义bean的范围的作用, **module之间只要连接就是互通的，可以相互注入**, 但打包bean还是要靠最外层的module。

## 3. 具体实现方式 ##

简单的说，就是一个工厂模式，由Dagger负责创建工厂，帮忙生产instance。遵从Java规范[JSR 330][]，可以使用这些注解。现在不研究Dagger2是如何根据注解去生成工厂的，先来看看工厂是什么东西，理解为什么可以实现了DI(Dependency Injection)，如何创建IoC(Inverse of Control)容器。

从入口出发。

CoffeeApp.CoffeeShop coffeeShop = DaggerCoffeeApp_CoffeeShop.builder().build();
    CoffeeMaker maker = coffeeShop.maker();

`DaggerCoffeeApp_CoffeeShop` 是生成的工厂类，实现了我们定义`Component`的接口`CoffeeShop`.  
![DaggerCoffeeApp\_CoffeeShop.svg][DaggerCoffeeApp_CoffeeShop.svg]

针对Component上的注解

@Singleton
    @Component(modules = { DripCoffeeModule.class })

首先观察`DripCoffeeModule`，里面目前声明了一个`Provider<Heater>`, 并且`include`了`PumpModule`。显然，我们的Component就是由这两个东西决定的。因此，`DripCoffeeModule`把这两个当做成员变量，这样就有了操纵这两个东西来生成instance的可能。

下一步，就是`build()`方法了：

public CoffeeApp.CoffeeShop build() {
        if (dripCoffeeModule == null) {
        this.dripCoffeeModule = new DripCoffeeModule();
        }
        if (pumpModule == null) {
        this.pumpModule = new PumpModule();
        }
        return new DaggerCoffeeApp_CoffeeShop(this);
    }

这里显然就是初始化这两个成员变量。然后创建我们的工厂`DaggerCoffeeApp_CoffeeShop`

private void initialize(final Builder builder) {
    this.provideHeaterProvider =
        DoubleCheck.provider(
            DripCoffeeModule_ProvideHeaterFactory.create(builder.dripCoffeeModule));
    this.pumpModule = builder.pumpModule;
    }

到这里才开始核心的依赖管理。

### initialize分析 ###

先看第一部分，这是关于`Heater`的。由于Heater声明了`Singleton`，Dagger通过经典的`double-check`来实现单例。面试必备。来看看dagger是怎么用的。这里有两种`Provider`  
![DripCoffeeModule\_ProvideHeaterFactory.sv][DripCoffeeModule_ProvideHeaterFactory.sv]  
其中，`Factory`是正宗的工厂。为毛还要专门继承出来一个接口？可以学习下这种抽象方法，虽然Factory和Provider几乎一模一样，但分出来是为了标记。或者说归类。比如，区别于`DoubleCheck`。看名字都能才出来，`DoubleCheck`是一个代理类。

虽然简单，但还是有好多可以学习的编程要点。

/** Returns a {
            @link Provider} that caches the value from the given delegate provider. */
    public static <T> Provider<T> provider(Provider<T> delegate) {
        checkNotNull(delegate);
        if (delegate instanceof DoubleCheck) {
            /* This should be a rare case, but if we have a scoped @Binds that delegates to a scoped
            * binding, we shouldn't cache the value again. */
            return delegate;
        }
        return new DoubleCheck<T>(delegate);
    }

看看，同样是创建一个新对象，比我们平时多了两步。一是检查Null，我表示遇到最多的生产事故是由`NullPointException`造成的，然后检查是否需要代理，如果本来就是代理类则直接返回，这里就实现了方法的幂等性，重复调用的结果一致。

接下来看我们的工厂`DripCoffeeModule_ProvideHeaterFactory`, 真就是一个工厂。但也不能不看，因为这是和我们代码关联最紧密的一步。工厂是如何根据我们的注解生产instance的呢？后面再看。学习源码真心提高抽象思维。

至此，initialize 方法结束。下一步就是生成我们的Component了。

### Make instance ###

public CoffeeMaker maker() {
        return new CoffeeMaker(
            DoubleCheck.lazy(provideHeaterProvider),
            Preconditions.checkNotNull(
                pumpModule.providePump(new Thermosiphon(provideHeaterProvider.get())),
                "Cannot return null from a non-@Nullable @Provides method"));
    }

果然就是直接用构造函数new了一个，因此，不要以为在Component上标记了Singleton就会生产出同一个Component了，每次生产的最外一层的instance，即Component，就是new了一个。但他的依赖就不同了。看看两个依赖的不同生命周期就能明白。

**Heater**  
Heater做了两个处理，一个是Singleton，一个是Lazy， 即懒汉式。Singleton和Lazy是两种设计模式。  
![DoubleCheck.svg][]  
DoubleCheck实现了Provider和Lazy的接口，而Provider和Lazy除了名字不同以为，一模一样。都是提供一个Get方法。再次体现了接口抽象的命名标记法。

而我们的Heater自然也是集Lazy和Singleton为一体的。这里的CoffeeMaker直接就是一个Lazy，一个代理，暂时不做任何操作。进下一步。

**PumpModule**  
直接调用方法生产数据，因为没有声明为Singleton，则直接new一个就好。其实就是我们平时写的工厂模式的get，不过我们写的时候直接返回一个new值，人家这里帮忙new了，丢进来。没啥大问题。真正的问题又回到了Heater，由于是单例的，必然不能直接new，需要去找持有单例的工厂类拿。而`provideHeaterProvider`就是前面的`DoubleCheck`代理。

private static final Object UNINITIALIZED = new Object();
    
      private volatile Provider<T> provider;
      private volatile Object instance = UNINITIALIZED;
    
      private DoubleCheck(Provider<T> provider) {
        assert provider != null;
        this.provider = provider;
      }
    
      @SuppressWarnings("unchecked") // cast only happens when result comes from the provider
      @Override
      public T get() {
        Object result = instance;
        if (result == UNINITIALIZED) {
          synchronized (this) {
            result = instance;
            if (result == UNINITIALIZED) {
              result = provider.get();
              /* Get the current instance and test to see if the call to provider.get() has resulted
               * in a recursive call.  If it returns the same instance, we'll allow it, but if the
               * instances differ, throw. */
              Object currentInstance = instance;
              if (currentInstance != UNINITIALIZED && currentInstance != result) {
                throw new IllegalStateException("Scoped provider was invoked recursively returning "
                    + "different results: " + currentInstance + " & " + result + ". This is likely "
                    + "due to a circular dependency.");
              }
              instance = result;
              /* Null out the reference to the provider. We are never going to need it again, so we
               * can make it eligible for GC. */
              provider = null;
            }
          }
        }
        return (T) result;
    }

经典的双重检查实现了懒汉单例模式。值得学习的是，这里并没有将null当做初始值，而是给了一个Object。然后把真正的生产数据的功能抽象，提出来称为Provider。这个Provider就是前面提到的真正干事情的工厂`DripCoffeeModule_ProvideHeaterFactory`。负责new一个instance出来。然后，值得学习的地方来了。因为单例模式已经不再需要工厂了，那么这个工厂类可以回收了。我们自己的编程习惯是扔着不管，请保姆(垃圾收集器)来干活。这里直接设置为null，值得注意，虽然大家都懂但不一定都会这样写。

至此，全部分析结束。生成的代码不复杂，但抽象度极高，虽然看的容易，但想象出并设计成这样就很难了。百度里一堆自己实现一个DI啥的，说起来简单，DI就是一个工厂模式。但你设计的DI有考虑这么多东西吗。如果没有这么高度的抽象，你如何才能少量的代码实现如此众多高效的功能？是时候学习源码了。

## Lazy and Singleton ##

上面的例子，使用DoubleCheck实现了单例模式的懒汉式。同时，又是懒加载Lazy。让人以为，Lazy和Singleton是一回事。但并不是这样。Lazy的javac注释中有：

> Note that each injected [\{@code][code] Lazy\} is independent, and remembers its value in isolation of other [\{@code][code] Lazy\} instances.

Lazy是一种延迟加载手段，其实就是在真实instance外面增加了一层包裹，只有当需要调用的时候才会启用`get`方法创建一个instance。而DoubleCheck同时继承了Provider和Lazy，因此看着像是单例和延迟加载同体了。

## 4. SubComponent ##

事实上，到这里dagger的用法对于服务端来说已经足够了。通过module的连接特性可以定义IoC容器范围，再结合dropwizard，就和springboot一样了。然而，毕竟dagger2是为了Android而打造的，为了适应其复杂的继承体系和生命周期的限制，dagger提供了SubComponent模型。也就是子组件。

刚看到这里会好奇，module已经可以把bean提供出来注入了，为啥还需要子组件？

我并没有真实的在生产环境中使用过dagger，全部认知也就来自对官方文档里的理解。对于Subcomponent的作用，大概有两点: 1)继承扩展功能并绑定生命周期，2）封装。

继承体现在subcomponent可以使用parent的module，共享其生命周期。

封装则是因为但其他人都不可以使用subcomponent的依赖，只能使用subcomponent本身。也就是parent里的Component不能调用subcomponent里的module。

暂时没能理解subcomponent和scope的使用，感觉有些复杂。将在项目中简单使用Module，因为期待得到的DI是最小侵入性的提供inject功能，而考虑这些层次关系以及作用范围，会导致耦合性增强，偏离了最初引入DI的意愿。目前掌握：我需要一个instance，dagger给一个instance给我injec。不需要考虑任何其他问题。

# 用法总结 #

*  `@Component`用来标注Component，最外层，the bean could only be exposed
 *  `@Module`负责管理依赖
 *  使用`@Provides`可以提供instance，当无法自动绑定的时候，比如接口和实现类
 *  使用`@Inject`可以让IoC容器负责生成instance，如果没有这个注解，dagger将不认识，当做普通类，无法代理
 *  在使用`@Component`的时候必须要提供scope范围，标准范围是`@Singleton`
 *  `@Component`在使用`@Module`的时候必须匹配相同的scope
 *  通过`@Component.modules`或者`@Module.includes` 可以把依赖连接成一个图，可以互相inject
 *  能使用Singleton的时候，要注意标注，否则默认多例

# 命名规约 #

*  @Provides方法用provide前缀命名
 *  @Module 用Module后缀命名
 *  @Component 以Component作为后缀

此文为官方文档读后感，至于生产环境的应用问题，将在后面使用后补充。  
<未完待续>

本文转自Ryan.Miao博客园博客，原文链接：http://www.cnblogs.com/woshimrf/p/hello-dagger.html，如需转载请自行联系原作者

[demo-uml.svg]: http://oe20lp6p0.bkt.clouddn.com/blog/2017/dagger/demo-uml.svg
[https_github.com_Ryan-Miao_l4dagger2]: https://github.com/Ryan-Miao/l4dagger2
[dagger_E8_B0_83_E7_94_A8_E5_B1_82_E6_AC]: http://oe20lp6p0.bkt.clouddn.com/blog/2017/dagger/dagger%E8%B0%83%E7%94%A8%E5%B1%82%E6%AC%A1.svg
[Dagger2]: http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0519/2892.html
[Module]: mailto:%E7%94%A8@Module%E6%B3%A8%E8%A7%A3
[Inject_Module]: mailto:%E4%B9%9F%E5%8F%AF%E4%BB%A5%E8%AF%B4%E6%98%AF@Inject%E5%92%8C@Module%E7%9A%84%E6%A1%A5%E6%A2%81
[Component_Modules]: mailto:%E6%88%91%E4%BB%AC%E5%BF%85%E9%A1%BB%E7%94%A8@Component%E6%B3%A8%E8%A7%A3%E4%B8%80%E4%B8%AA%E6%8E%A5%E5%8F%A3%E7%84%B6%E5%90%8E%E5%88%97%E5%87%BA%E6%89%80%E6%9C%89%E7%9A%84@Modules%E7%BB%84%E6%88%90%E8%AF%A5%E7%BB%84%E4%BB%B6
[PerActivity]: mailto:%E6%88%91%E4%BB%AC%E7%94%A8%E8%87%AA%E5%AE%9A%E4%B9%89%E7%9A%84@PerActivity%E6%B3%A8%E8%A7%A3%E4%B8%80%E4%B8%AA%E7%B1%BB
[module-extend.svg]: http://oe20lp6p0.bkt.clouddn.com/blog/2017/dagger/module-extend.svg
[JSR 330]: https://jcp.org/en/jsr/detail?id=330
[DaggerCoffeeApp_CoffeeShop.svg]: http://oe20lp6p0.bkt.clouddn.com/blog/2017/dagger/DaggerCoffeeApp_CoffeeShop.svg
[DripCoffeeModule_ProvideHeaterFactory.sv]: http://oe20lp6p0.bkt.clouddn.com/blog/2017/dagger/DripCoffeeModule_ProvideHeaterFactory.svg
[DoubleCheck.svg]: http://oe20lp6p0.bkt.clouddn.com/blog/2017/dagger/DoubleCheck.svg
[code]: mailto:%7B@code