前言
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看做是父Component提供的一个依赖来处理
- 主要用来实现Activity-Multibinding，后面章节会有介绍，参考文章（在Dagger 2中Activities和Subcomponents的多绑定）
先写个比较简单的将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注解
可释放的局部单例
使用@Scope注解时，Component 会间接持有依赖实例的引用，使得依赖和Componnet具有相同的生命周期，在android中需要尽可能的减少内存占用，这种情况下可以使用@CanReleaseReferences标记@Scope注解。
总结
如果理解了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分支上最新的代码可能会比当前文章的示例代码稍微复杂点，提交记录里包含了每一步的迭代过程,可以顺藤摸瓜
网友评论