Dagger2:Scope, Component间依赖和subComponent

在上一篇文章(http://www.jianshu.com/p/f56d5b7e8b4d)中,我们接触到了Dagger2的基本用法。然而在实际Android开发当中,还会有更进一步的需求:需要有多个不同生命周期的多个Component,例如,有些依赖图是全局单例的,而有些依赖图会与Activity/Fragment同周期,或者有些依赖图是要与用户登录同周期。在这些情况下,我们就需要自定义Scope来维护多个Component各自依赖图的生命周期。更进一步的,我们讨论利用Component间的依赖和subComponent两种方法来创建多个Component。

1. Scope

Scope注解是JSR-330标准中的,该注解是用来修饰其他注解的。 前篇文章提到的@Singleton就是一个被Scope标注的注解,是Scope的一个默认实现。
Scope的注解的作用,是在一个Component的作用域中,依赖为单例的。也就是说同一个Component对象向各个类中注入依赖时候,注入的是同一个对象,而并非每次都new一个对象。
在这里,我们再介绍自定义的Scope注解,如:

@Scope
public @interface ActivityScope {
}

如上,ActivityScope就是一个我们自己定义的Scope注解,其使用方式与上篇文章中我们用Singleton的用法类似的。顾名思义,在实际应用中Singleton代表了全局的单例,而我们定义ActivityScope代表了在Activity生命周期中相关依赖是单例的。
Scope的注解具体用法如下:
(1). 首先用其修饰Component
(2). 如果依赖由Module的Provides或Binds方法提供,且该依赖在此Component中为单例的,则用Scope相关注解修饰Module的Provides和Binds方法。
(3). 如果依赖通过构造方式注入,且该依赖在此Component中为单例的,则要用Scope修饰其类。
我们通过如下例子详细说明,并进行测试和分析其原理:

以Singleton这个Scope是实现为例:
首先用它来修饰Component类:

@Singleton
@Component
public interface AppComponent {
    void inject(MainActivity mainActivity);
}

用通过构造方法注入依赖图的,用@Singleton修饰其类:

@Singleton
public class InfoRepository {
    private static final String TAG = "InfoRepository";

    @Inject
    InfoRepository() {
    }

    public void test() {
        Log.d(TAG, "test");
    }
}

实际注入到Activity类中如下:

public class MainActivity extends Activity {
    @Inject
    InfoRepository infoRepositoryA;
    @Inject
    InfoRepository infoRepositoryB;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        MyApplication.getComponent().inject(this);
        setContentView(R.layout.activity_main);
        Log.d("test", "a:"+infoRepositoryA.hashCode());
        Log.d("test", "b:"+infoRepositoryB.hashCode());
    }
}

如上代码测试结果如下:

10-19 19:25:08.253 26699-26699/com.qt.daggerTest D/test: a:442589
10-19 19:25:08.254 26699-26699/com.qt.daggerTest D/test: b:442589

如上可见,两次注入的InfoRepository对象为同一个。
如果将上面修饰InfoRepository的@Singleton注解去掉,结果是什么呢?经过测试如下:

10-19 19:23:00.092 23014-23014/com.qt.daggerTest D/test: a:442589
10-19 19:23:00.092 23014-23014/com.qt.daggerTest D/test: b:160539730

也就是说在不加@Singleton注解时候,每次注入的时候都是new一个新的对象。
注意,如果我们将上面所有的@Singleton替换成我们自己的Scope注解其结果也是一致的,如替换成上文的ActivityScope。

下面,我们通过分析Dagger自动生成的代码来分析如何实现单例的:

在注入类不加@Singleton注解时,生成的DaggerAppComponent类的initialize()方法如下:

  @SuppressWarnings("unchecked")
  private void initialize(final Builder builder) {
    this.mainActivityMembersInjector =
        MainActivity_MembersInjector.create(InfoRepository_Factory.create());
  }

而加@Singleton注解后的initialize()方法变成了:

  @SuppressWarnings("unchecked")
  private void initialize(final Builder builder) {

    this.infoRepositoryProvider = DoubleCheck.provider(InfoRepository_Factory.create());

    this.mainActivityMembersInjector =
        MainActivity_MembersInjector.create(infoRepositoryProvider);
  }

也是就是说提供InfoRepository的InfoRepositoryProvider替换成了DoubleCheck.provider(InfoRepository_Factory.create())。用DoubleCheck包装了原来对象的Provider。DoubleCheck顾名思义,应该是通过双重检查实现单例,我们看源码确实如此:

public final class DoubleCheck<T> implements Provider<T>, Lazy<T> {
  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;
  ...
  }

其get方法就用了DoubleCheck方式保证了单例,其中还判断如果存在循环依赖的情况下抛出异常。

注意,Scope只的单例是在Component的生命周期中相关依赖是单例的,也就是同一个Component对象注入的同类型的依赖是相同的。按上面例子,如果我们又创建了个AppComponent,它注入的InfoRepository对象与之前的肯定不是一个。

2. Component间依赖

在Android应用中,如果我们需要不止一个Component,而Component的依赖图中有需要其他Component依赖图中的某些依赖时候,利用Component间依赖(Component Dependency)方式是个很好的选择。在新建Component类时候可以在@Component注解里设置dependencies属性,确定其依赖的Component。在被依赖的Component中,如果要暴露其依赖图中的某个依赖给其他Component,要显示的在其中定义方法,使该依赖对其他Component可见如:

@Singleton
@Component(modules = AppModule.class)
public interface AppComponent {
    Application application();
}
@ActivityScope
@Component(dependencies = AppComponent.class, modules = ActivityModule.class)
public interface ActivityComponent {
    void inject(MainActivity mainActivity);
}

在ActivityComponent中,就可以使用AppComponent依赖图中暴露出的Application依赖了。
非常清晰,Component依赖(Component Dependency)的方式适用于Component只将某个或某几个依赖暴露给其他Component的情况下。

3.subComponent

定义subComponent是另一种方式使Component将依赖暴露给其他Component。当我们需要一个Component,它需要继承另外一个Component的所有依赖时,我们可以定义其为subComponent。
具体用法如下:首先在父Component的接口中定义方法,来获得可以继承它的subComponent:

@Singleton
@Component(
        modules = {AppModule.class}
)
public interface AppComponent {

    UserComponent plus(UserModule userModule);

}

其次,其subComponent被@SubComponent注解修饰,如下:

@UserScope
@Subcomponent(
        modules = {UserModule.class}
)
public interface UserComponent {
  ...
}

Dagger会实现上面在接口中定义的plus()方法,我们通过调用父Component的plus方法或者对应的subComponent实例,具体如下:

userComponent = appComponent.plus(new UserModule(user));

这样,我们就获得了userComponent对象,可以利用他为其他类注入依赖了。
注意,subComponent继承了其父Component的所有依赖图,也就是说被subComponent可以向其他类注入其父Component的所有依赖。

4. 用多个Component组织你的Android应用

前面几部分中,我们介绍了如何创建多个Component/subComponent并使其获得其他Component的依赖。这就为我们在应用中用多个Component组织组织应用提供了条件。文章http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/ 提供了一个常用的思路:我们大概需要三个Component:AppComponent,UserComponent,ActivityComponent,如下:

摘自http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/

上文介绍了,各个Component要有自己的Scope且不能相同,所以这几个Component对应的Scope分别为@Singleton ,@UserScop,@ActivityScope。也就是说,依赖在对应的Component生命周期(同个Component中)中都是单例的。而三个Component的生命周期都不同:AppComponent为应用全局单例的,UserComponent的生命周期对应了用户登录的生命周期(从用户登录一个账户到用户退出登录),ActivityComponent对应了每个Activity的生命周期,如下:

Scopes lifecycle 摘自http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/

在具体代码中,我们通过控制Component对象的生命周期来控制依赖图的周期,以UserComponent为例,在用户登录时候创建UserComponent实例,期间一直用该实例为相关类注入依赖,当其退出时候将UserComponent实例设为空,下次登录时候重新创建个UserComponent,大致如下:

    public class MyApplication extends Application {
      ...
    private void initAppComponent() {
        appComponent = DaggerAppComponent.builder()
                .appModule(new AppModule(this))
                .build();
    }

    public UserComponent createUserComponent(User user) {
        userComponent = appComponent.plus(new UserModule(user));
        return userComponent;
    }

    public void releaseUserComponent() {
        userComponent = null;
    }

    public AppComponent getAppComponent() {
        return appComponent;
    }

    public UserComponent getUserComponent() {
        return userComponent;
    }

}

createUserComponent和releaseUserComponent在用户登入和登出时候调用,所以在不同用户中用的是不同UserComponent对象注入,注入的依赖也不同。而AppComponent对象只有一个,所以其依赖图中的依赖为全局单例的。而对于ActivityComponent,则可以在Activity的onCreate()中生成ActivityComponent对象来为之注入依赖。

5.多Component情况下Scope的使用限制

Scope和多个Component在具体使用时候有一下几点限制需要注意:
(1). Component和他所依赖的Component不能公用相同的Scope,每个Component都要有自己的Scope,编译时会报错,因为这有可能破坏Scope的范围,可详见https://github.com/google/dagger/issues/107#issuecomment-71073298。这种情况下编译会报错:

Error:(21, 1) 错误:com.qt.daggerTest.AppComponent depends on scoped components in a non-hierarchical scope ordering:
@com.qt.daggerTest.ActivityScope com.qt.daggerTest.AppComponent
@com.qt.daggerTest.ActivityScope com.qt.daggerTest.ActivityComponent

(2). @Singleton的Component不能依赖其他Component。这从意义和规范上也是说的通的,我们希望Singleton的Component应为全局的Component。这种情况下编译时会报错:

Error:(23, 1) 错误: This @Singleton component cannot depend on scoped components:
@Singleton com.qt.daggerTest.AppComponent

(3). 无Scope的Component不能依赖有Scope的Component,因为这也会导致Scope被破坏。这时候编译时会报错:

Error:(20, 2) 错误: com.qt.daggerTest.ActivityComponent (unscoped) cannot depend on scoped components:
@com.qt.daggerTest.ActivityScope com.qt.daggerTest.AppComponent

(4). Module以及通过构造函数注入依赖图的类和其Component不可有不相同的Scope,这种情况下编译时会报:

Error:(6, 1) 错误: com.qt.daggerTest.AppComponent scoped with @com.qt.daggerTest.ActivityScope may not reference bindings with different scopes:
@Singleton class com.qt.daggerTest.InfoRepository

总结

在上一篇Dagger2介绍与使用(http://www.jianshu.com/p/f56d5b7e8b4d)的基础之上,本文围绕着Android中多个Component情况下如何使用的问题展开了分析。首先说明了如何通过Scope和Component管理依赖的生命周期,再介绍了通过Component间依赖和subComponent两种方式完成一个Component将自己的依赖图暴露给其他Component的过程。然后介绍如一般在Android应用中如何划分Component,维护不同生命周期的依赖。
经过两篇文章的介绍,Dagger2的使用基本清晰。Dagger2在处理Android应用的依赖非常得心应手,通过依赖注入的方式实现依赖反转,用容器(Component)来控制了所有依赖,使应用各个组件的依赖更加清晰。Dagger2的各种功能也比较灵活,能够应付Android应用依赖关系的各种复杂场景。

参考:
https://stackoverflow.com/questions/28411352/what-determines-the-lifecycle-of-a-component-object-graph-in-dagger-2
http://frogermcs.github.io/dependency-injection-with-dagger-2-custom-scopes/
https://stackoverflow.com/questions/36447251/dagger-2-constructor-injection-scope
http://www.jianshu.com/p/5ce4dcc41ec7
http://www.jianshu.com/p/fbd62868a07b
https://my.oschina.net/rengwuxian/blog/287892

推荐阅读更多精彩内容