tags: [dagger2,架构,android]
categories: dagger2
top: false
toc: true
cover: false
img: /featureImg/dagger.jpg
summary: 了解一下dagger2的局部单例
—-

dagger2有一个比较重要的特性，就是可以指定依赖在某个相同的生命周期内被注入的是同一个对象。这个和一般的单例不太一样，普通的单例的生命周期是到应用被kill为止，而dagger2中的单例的生命周期可以和Application、Activity、Fragment…各种不同对象的生命周期保持一致，所以也叫局部单例，这篇文章就来聊一聊局部单例

Component的继承/依赖体系

dagger2中依赖的生命周期是由DaggerXXXComponent进行管理的，所以先来看看Component的继承/依赖体系

Component继承/依赖体系的作用

  • Component继承体系是为了让每一个层级的Component可以只处理当前层级的依赖，而不用关心下层的依赖，当使用到下层依赖时会从父Component中去找
  • Dagger虽然没有硬性规定要如何构建Component的继承体系，但是按照Application-Activity-Fragment这样的结构来更加自然和方便，同时也可以更好的和Android组件的生命周期匹配
  • 当然如果要为一个Fragment进行依赖注入，你也可以只定义一个Component，将Application，Activity，Fragment作为builder的参数提供给该Component，但是这样不仅代码会较为繁琐，而且失去了dagger的生命周期管理的能力

Component继承的三种方式

方式1

使用@Subcomponent注解，在父Component中显式暴露获取SubComponent实例的接口

  1. @Subcomponent
  2. public interface ActivityComponent2 {
  3.     void inject(SubComponentActivity2 activity);
  4. }
  5. @Component
  6. public interface AppComponent {
  7.     //显式声明获取SubComponent的接口
  8.     ActivityComponent2 getActivityComponent2();
  9. }
  10. //使用父Component获取SubComponent
  11.  getAppCompoent().getActivityComponent2().inject(this);

方式2

使用@Subcomponent注解，在父Component使用的Module中用subcomponents属性指定该Subcomponent

需要在SubComponent中显式声明 Subcomponent.Builder

  1. @Subcomponent
  2. public interface ActivityComponent3 {
  3.     void inject(SubComponentActivity3 activity);
  4.     //在module中指定subcomponents的Component必须显式地声明 Subcomponent.Builder
  5.     @Subcomponent.Builder
  6.     interface Builder {
  7.         ActivityComponent3 build();
  8.     }
  9. }
  10. //在@Module的subcomponents属性中指定SubComponent
  11. @Module(subcomponents = ActivityComponent3.class)
  12. public class AppModule {
  13. }

获取SubComponent有两种方式

  • 在父Component中显式的声明Subcomponent，Builder(这样其实和方式1差别不大，还多了一步)
  1. @Component(modules = { AppModule.class})
  2. public interface AppComponent {
  3.     ActivityComponent3.Builder getActivityComponent3Builder();
  4. }
  5. //使用父Component获取Subcomponent.Builder
  6.  getAppCompoent().getActivityComponent3Builder().build().inject(this);
  • 将Subcomponent.Builder看做是父Component提供的一个依赖来处理 
  1. public class RealApplication{
  2.     //直接在Application中注入ActivityComponent3.Builder
  3.     @Inject
  4.     ActivityComponent3.Builder mBuilder;
  6.     ...
  7.     public ActivityComponent3.Builder getBuilder() {
  8.         return mBuilder;
  9.     }
  10. }
  11. //从Application中获取Builder完成注入
  12. ((RealApplication)getApplication()).getBuilder().build().inject(this);

官方的例子写的更好一些：（subcomponents-for-encapsulation）

方式3

子Component使用@Component标记并通过dependencies属性指定父Component,在父Component显示声明子Component中需要的依赖的接口

  1. @Component(dependencies = AppComponent.class)
  2. public interface ActivityComponent1 {
  3.     void inject(SubComponentActivity1 activity);
  4. }
  5. public interface AppComponent {
  6.     //如果有component使用dependencies，则需要显式声明可以提供的对象
  7.     Integer versionCode();
  8. }
  9. //将父Component作为参数
  10. DaggerActivityComponent1.builder()
  11.     .appComponent(getAppCompoent())
  12.     .build().inject(this);

这种方式比较不推荐使用，应为底层Component提供的依赖需要手动暴露出来上层才能用，这样比较麻烦
有个值得的注意的点是显式暴露的依赖不能多层传递，即Component1依赖Component2依赖Component3，都使用dependencies指定父Component；Component3显式声明了获取依赖假设是Application application();，如果Component1需要用到Application，则需要在Component2中也显式声明获取Application的方法
不过这是三种方式中唯一一种从上至下定义依赖关系的方式（在子Component中指定父Component），其他的都是从下至上的（父Component或者父Component的Module中指定子Component），在多个模块的项目中，这是上层模块中Component依赖下层模块中Componnet唯一方式，而需要手动暴露提供依赖的接口也是出于权限控制的考虑
这种方式有个额外的好处是上层的Componnet可以依赖多个底层Component

@Scope

@Scope是一个标记注解的注解，用来定义生命周期相关的注解
@Scope需要Component和依赖提供者配合才能起作用，对于@Scope注解的依赖，Component会持有第一次创建的依赖，后面注入时都会复用这个依赖的实例，实质上@Scope的目的就是为了让生成的依赖实例的生命周期与 Component 绑定
如果Component重建了，持有的@Scope的依赖也会重建，所以为了维护局部单例需要自己维护Component的生命周期
dagger2默认提供了Singleton注解

  1. @Scope
  2. @Documented
  3. @Retention(RUNTIME)
  4. public @interface Singleton {}

参照着写了ActivityScope,AppScope,FragmentScope,当然可以自己加什么ViewScope，ViewModelScope等等，只是改个名字而已

  1. //一个例子
  2. @Scope
  3. @Documented
  4. @Retention(RUNTIME)
  5. public @interface ActivityScope {
  6. }

@Scope的用法

  • 用在@Inject注解构造器的类上，而不是构造器上
  1. @SimpleScope
  2. public class SimpleActivityBean extends BaseBean {
  3.     Activity mSimpleActivity;
  4.     @Inject
  5.     public SimpleActivityBean(Activity simpleActivity) {
  6.         mSimpleActivity = simpleActivity;
  7.     }
  8. }
  • 用在@Providers注解的方法上
  1. @Provides
  2.     @SimpleScope
  3.     public SimpleModuleBean provideSimpleModuleBean() {
  4.         return new SimpleModuleBean();
  5.     }
  • 用在@ContributesAndroidInjector注解的方法上（dagger.android相关，后面章节会提到）
  • 用在Component上，与要实现局部单例的依赖进行绑定

局部单例的其他用法

不与Componnet绑定的依赖的复用

上面说的局部单例都是绑定到Componnet中实现复用的，如果只是单纯的想减少依赖创建的次数而不关心和哪个
Component绑定，可以使用@Reusable注解
reusable-scope

可释放的局部单例

使用@Scope注解时，Component 会间接持有依赖实例的引用，使得依赖和Componnet具有相同的生命周期，在android中需要尽可能的减少内存占用，这种情况下可以使用@CanReleaseReferences标记@Scope注解。
releasable-references

总结

如果理解了Component的继承/依赖体系，其实@Scope比较好理解

  • 一个Componnet只能维护一个生命周期，即该Componnet提供的依赖想要具备局部单例的能力，必须标记和Component相同的@Scope注解
  • 具有继承/依赖关系的不同Component需要使用不同的@Scope注解
  • Scope 作用域的本质：Component 间接持有依赖实例的引用，把实例的作用域与 Component 绑定，它们不是同年同月同日生，但是同年同月同日死。
  • 实现局部单例需要在对应的生命周期里只创建一个Component，例如在Application中AppComponent只创建一次，其他的子Component的创建都基于这一个AppComponent实例完成

相关文章

dagger2从入门到放弃-概念
dagger2从入门到放弃-最基础的用法介绍
dagger2从入门到放弃-Component的继承体系、局部单例
dagger2从入门到放弃-ActivityMultibindings
dagger2从入门到放弃-dagger.android
dagger2从入门到放弃-其他用法
dagger2从入门到放弃-多模块项目下dagger的使用
dagger2从入门到放弃-为何放弃

示例代码

DaggerInAction 欢迎star master分支上最新的代码可能会比当前文章的示例代码稍微复杂点，提交记录里包含了每一步的迭代过程,可以顺藤摸瓜