依赖注入框架dagger2的@Scope注解初探(根据生成的源码进行分析)
- 为了使讨论的问题更加清晰,我将尽可能减少无关代码,但是本文贴出的代码够初步探究@Scope作用域控制原理了
- 分析结论在文章最后
废话少说,下边开始先交代原始代码场景逻辑
原始场景代码
首先自定义一个@Scpoe注解,用来注解之后提供的依赖
@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface ActivityScope {}
顺便贴一下,@Singleton注解如下
@Scope
@Documented
@Retention(RUNTIME)
public @interface Singleton {}
然后定义Component
//此处一定要与DemoModule中的依赖提供者用同一种注解
@ActivityScope
@Component(modules = DemoModule.class)
public interface DemoComponent {
DemoActivity inject(DemoActivity activity);
}
其所依赖的module如下
@Module
public class DemoModule {
private DemoActivity mActivity;
@Inject
public DemoModule(DemoActivity activity){
mActivity = activity;
}
@ActivityScope
@Provides
DemoActivity provideDemoActivity() {
return mActivity;
}
}
DemoActivity如下
public class DemoActivity {
private DemoComponent mComponent;
//代码省略
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setupComponent();
}
private void setupComponent() {
//DaggerDemoComponent是dagger自动生成的类 下边分析的入口就是它
mComponent=DaggerDemoComponent.builder().demoModule(new DemoModule(this)).build();
mComponent.inject(this);
}
//代码省略
}
生成代码分析
/*在DaggerDemoComponent.builder().demoModule(new DemoModule(this)).build()时会调用initialize初始化*/
private void initialize(final Builder builder) {
private Provider<DemoActivity> provideDemoActivityProvider;
//注意这是component和对应的module-provide加了@ActivityScope的结果
//在我理解DoubleCheck就是一个包装作用,实现单例的功能
this.provideDemoActivityProvider = DoubleCheck.provider(DemoModule_ProvideDemoActivityFactory.create(builder.demoModule));
//代码省略
}
接下来看看DoubleCheck#provider里发生了什么
public static <T> Provider<T> provider(Provider<T> delegate) {
checkNotNull(delegate);
if (delegate instanceof DoubleCheck) {
//如果delegate是DoubleCheck类型就直接返回
//第一次不是DoubleCheck类型(是Factory<T>,最终继承自Provider<T>)
//所以会在第一次build时新建一个DoubleCheck<T>实例,而之后会直接返回该实例
return delegate;
}
return new DoubleCheck<T>(delegate);
}
也就是说此时provideDemoActivityProvider是DoubleCheck<DemoActivity>类型的对象
那么DoubleCheck.provider的参数貌似在有@Scope注解时没有起作用,其实这是故意避免的,因为通过其提供的get方法得到的是DemoModule#provideDemoActivity(),也就不能保证单例性,看一下其源码:
public final class DemoModule_ProvideDemoActivityFactory implements Factory<DemoActivity>{
private final DemoModule module;
public DemoModule_ProvideDemoActivityFactory(DemoModule module) {
assert module != null;
this.module = module;
}
@Override
public DemoActivity get() {
return Preconditions.checkNotNull(
//当没有@Scope注解时提供依赖的方法会走这
module.provideDemoActivity(), "Cannot return null from a non-@Nullable @Provides method");
}
public static Factory<DemoActivity> create(DemoModule module) {
return new DemoModule_ProvideDemoActivityFactory(module);
}
}
到这就很清楚了,之所以@Scope类型注解能让其保持单例,是因为DoubleCheck#get方法实现了单例:
@Override
public T get() {
Object result = instance;
if (result == UNINITIALIZED) {
synchronized (this) {
result = instance;
if (result == UNINITIALIZED) {
//
instance = result = provider.get();
provider = null;
}
}
}
return (T) result;
}
梳理一下
- Component注入依赖时会在build方法中执行initialize
- 而在initialize中dagger会根据是否有对应的@Scope注解生成不同的代码
- 若有@Scope注解,Provider是DoubleCheck类型,否之是对应的工厂类
- DoubleCheck构造次数(即Component#build次数)决定了@Scope所注解的只是”假单例”,当然,若Provider所提供的本身就是单例那么不受影响,其仍然是单例的
- 由此推断,@Scope只能在Component所注入的作用域内保持“单例”
- 在Application中注入的是全局单例
可能有不准确的地方,欢迎指正
迁移自CSDN
2016年04月29日 20:55:43
http://blog.csdn.net/u013262051/article/details/51283456
网友评论