Dagger2 入门解析

前言

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

作者:@Ryan-Miao
本文为作者原创,转载请注明出处:http://www.cnblogs.com/woshimrf/p/hello-dagger.html

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

HelloWorld

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

demo source: 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; // Create a possibly costly heater only when we use it.
    private final Pump pump;

    @Inject
    CoffeeMaker(Lazy 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之间可以互相注入。

注入原理

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

以下来自详解Dagger2

  • @Inject: 通常在需要依赖的地方使用这个注解。换句话说,你用它告诉Dagger这个类或者字段需要依赖注入。这样,Dagger就会构造一个这个类的实例并满足他们的依赖。
  • @Module: Modules类里面的方法专门提供依赖,所以我们定义一个类,用@Module注解,这样Dagger在构造类的实例的时候,就知道从哪里去找到需要的 依赖。modules的一个重要特征是它们设计为分区并组合在一起(比如说,在我们的app中可以有多个组成在一起的modules)。
  • @Provide: 在modules中,我们定义的方法是用这个注解,以此来告诉Dagger我们想要构造对象并提供这些依赖。
    @Component: Components从根本上来说就是一个注入器,也可以说是@Inject和@Module的桥梁,它的主要作用就是连接这两个部分。
  • Components可以提供所有定义了的类型的实例,比如:我们必须用@Component注解一个接口然后列出所有的@Modules组成该组件,如 果缺失了任何一块都会在编译的时候报错。所有的组件都可以通过它的modules知道依赖的范围。
  • @Scope: Scopes可是非常的有用,Dagger2可以通过自定义注解限定注解作用域。后面会演示一个例子,这是一个非常强大的特点,因为就如前面说的一样,没 必要让每个对象都去了解如何管理他们的实例。在scope的例子中,我们用自定义的@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为子类。

但是, 引用注入的时候却和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.

针对Component上的注解

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

首先观察DripCoffeeModule,里面目前声明了一个Provider, 并且includePumpModule。显然,我们的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

其中,Factory是正宗的工厂。为毛还要专门继承出来一个接口?可以学习下这种抽象方法,虽然Factory和Provider几乎一模一样,但分出来是为了标记。或者说归类。比如,区别于DoubleCheck。看名字都能才出来,DoubleCheck是一个代理类。

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

/** Returns a {@link Provider} that caches the value from the given delegate provider. */
public static  Provider provider(Provider 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(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实现了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 provider;
  private volatile Object instance = UNINITIALIZED;

  private DoubleCheck(Provider 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 Lazy} is independent, and remembers its value in isolation of other {@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作为后缀

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

参考

  • http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0519/2892.html
  • http://www.cnblogs.com/tiantianbyconan/p/5095426.html

你可能感兴趣的:(DI,Dagger2)