dagger2从入门到放弃-Component的继承体系、局部单例

2024年2月2日 224次阅读 来源: sunhapper

前言

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实例的接口

@Subcomponent
public interface ActivityComponent2 {
    void inject(SubComponentActivity2 activity);
}

@Component
public interface AppComponent {
    //显式声明获取SubComponent的接口
    ActivityComponent2 getActivityComponent2();
}

//使用父Component获取SubComponent
 getAppCompoent().getActivityComponent2().inject(this);

方式2

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

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

@Subcomponent
public interface ActivityComponent3 {
    void inject(SubComponentActivity3 activity);

    //在module中指定subcomponents的Component必须显式地声明 Subcomponent.Builder
    @Subcomponent.Builder
    interface Builder {
        ActivityComponent3 build();
    }
}

//在@Module的subcomponents属性中指定SubComponent
@Module(subcomponents = ActivityComponent3.class)
public class AppModule {
}

获取SubComponent有两种方式

  • 在父Component中显式的声明Subcomponent，Builder(这样其实和方式1差别不大，还多了一步)
@Component(modules = { AppModule.class})
public interface AppComponent {
    ActivityComponent3.Builder getActivityComponent3Builder();
}

//使用父Component获取Subcomponent.Builder
 getAppCompoent().getActivityComponent3Builder().build().inject(this);

先写个比较简单的将Subcomponent.Builder作为依赖的用法

public class RealApplication{
    //直接在Application中注入ActivityComponent3.Builder
    @Inject
    ActivityComponent3.Builder mBuilder;
    
    ...
    public ActivityComponent3.Builder getBuilder() {
        return mBuilder;
    }

}

//从Application中获取Builder完成注入
((RealApplication)getApplication()).getBuilder().build().inject(this);

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

方式3

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

@Component(dependencies = AppComponent.class)
public interface ActivityComponent1 {
    void inject(SubComponentActivity1 activity);
}

public interface AppComponent {

    //如果有component使用dependencies，则需要显式声明可以提供的对象
    Integer versionCode();
}

//将父Component作为参数
DaggerActivityComponent1.builder()
    .appComponent(getAppCompoent())
    .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注解

@Scope
@Documented
@Retention(RUNTIME)
public @interface Singleton {}

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

//一个例子
@Scope
@Documented
@Retention(RUNTIME)
public @interface ActivityScope {
}

@Scope的用法

  • 用在@Inject注解构造器的类上，而不是构造器上
@SimpleScope
public class SimpleActivityBean extends BaseBean {
    Activity mSimpleActivity;

    @Inject
    public SimpleActivityBean(Activity simpleActivity) {
        mSimpleActivity = simpleActivity;
    }
}
  • 用在@Providers注解的方法上
    @Provides
    @SimpleScope
    public SimpleModuleBean provideSimpleModuleBean() {
        return new SimpleModuleBean();
    }

  • 用在@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分支上最新的代码可能会比当前文章的示例代码稍微复杂点，提交记录里包含了每一步的迭代过程,可以顺藤摸瓜

    原文作者：sunhapper
    原文地址: https://www.jianshu.com/p/f610a5606575
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞