依賴注入框架dagger2的@Scope注解初探(根據生成的源碼進行分析)

依賴注入框架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

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容