八、深入理解Dagger2源碼 · Android熱門三方庫源碼解析

[TOC] 上一篇，筆者詳細地分析了Android中的依賴注入框架ButterKnife，使用它幫助我們解決了重復編寫findViewById和setOnclickListener的繁瑣。眾所周知，當項目越來越大時，類之間的調用層次會越來越深，并且有些類是Activity/Fragment，有些是單例，而且**它們的生命周期也不是一致的**，所以創建這些對象時要處理的各個對象的依賴關系和生命周期時的任務會很繁重，因此，為了解決這個問題Dagger2應運而生。**相比ButterKnife的輕量級使用，Dagger2會顯得更重量級和鋒利一些，它能夠掌控全局，對項目中幾乎所有的依賴進行集成管理**。如果有對Binder架構體系比較了解的朋友應該知道，其中的服務大管家ServiceManager負責所有的服務（引導服務、核心服務、其它服務）的管理，而Dagger2其實就是將項目中的依賴進行了集成管理。下面，筆者來跟大家一起探索Dagger2的內部實現機制，看看它是如何進行依賴管理的。 Dagger2其實同RxJava一樣，是一種多平臺通用的庫。由于Dagger2的通用寫法比較繁瑣，因此，Google推出了適用于Android平臺的Dagger.Android用法。本文，將基于Dagger.Android的源碼對Dagger2內部的實現機制進行探索。 ### 一、預備知識鑒于Dagger有一定的上手成本，這里首先帶大家復習一下本篇源碼分析可能會涉及到的相關基礎知識點，以此降低閱讀難度。 #### 1、@Inject 告訴dagger這個字段或類需要依賴注入，然后在需要依賴的地方使用這個注解，dagger會自動生成這個構造器的實例。 #### 獲取所需依賴： * 全局變量注入 * 方法注入 #### 提供所需實例： * 構造器注入（如果有多個構造函數，只能注解一個，否則編譯報錯） #### 2、@Module 類注解，表示此類的方法是提供依賴的，它告訴dagger在哪可以找到依賴。用于不能用@Inject提供依賴的地方，如第三方庫提供的類，基本數據類型等不能修改源碼的情況。注意：**Dagger2會優先在@Module注解的類上查找依賴，沒有的情況才會去查詢類的@Inject構造方法** #### 3、@Singleton 聲明這是一個單例，**在確保只有一個Component并且不再重新build()之后，對象只會被初始化一次，之后的每次都會被注入相同的對象**，它就是一個內置的作用域。對于@Singleton，大家可能會產生一些誤解，這里詳細闡述下： * Singleton容易給人造成一種誤解就是用Singleton注解后在整個Java代碼中都是單例，但**實際上他和Scope一樣，只是在同一個Component是單例**。也就是說，如果重新調用了component的build（）方法，即使使用了Singleton注解了，但仍然獲取的是不同的對象。 * 它表明了\*\*@Singleton注解只是聲明了這是一個單例，為的只是提高代碼可讀性，其實真正控制對象生命周期的還是Component\*\*。同理，自定義的@ActivityScope 、@ApplicationScope也僅僅是一個聲明的作用，**真正控制對象生命周期的還是Component**。 #### 4、@Providers 只在@Module中使用，用于提供構造好的實例。一般與@Singleton搭配，用單例方法的形式對外提供依賴,是一種替代@Inject注解構造方法的方式。注意： * 使用了@Providers的方法應使用provide作為前綴，使用了@Module的類應使用Module作為后綴。 * **如果@Providers方法或@Inject構造方法有參數，要保證它能夠被dagger獲取到，比如通過其它@Providers方法或者@Inject注解構造器的形式得到**。 #### 5、@Component **@Component作為Dagger2的容器總管，它擁有著@Inject與@Module的所有依賴。同時，它也是一枚注射器，用于獲取所需依賴和提供所需依賴的橋梁**。這里的橋梁即指@Inject和@Module（或@Inject構造方法）之間的橋梁。定義時需要列出響應的Module組成，此外，還可以使用dependencies繼承父Component。 #### Component與Module的區別： Component既是注射器也是一個容器總管，而module則是作為容器總管Component的子容器，實質是一個用于提供依賴的模塊。 #### 6、@Scope 注解作用域，通過自定義注解**限定對象作用范圍，增強可讀性**。 @Scope有兩種常用的使用場景： * **模擬Singleton代表全局單例，與Component生命周期關聯**。 * **模擬局部單例，如登錄到退出登錄期間**。 #### 7、@Qualifier 限定符，利用它**定義注解類以用于區分類的不同實例**。例如：2個方法返回不同的Person對象，比如說小明和小華，為了區分，使用@Qualifier定義的注解類。 #### 8、dependencies 使用它表示ChildComponent依賴于FatherComponent，如下所示： ~~~ @Component(modules = ChildModule.class, dependencies = FatherComponent.class) public interface ChildComponent { ... } ~~~ #### 9、@SubComponent 表示是一個子@Component，它能**將應用的不同部分封裝起來，用來替代@Dependencies**。回顧完Dagger2的基礎知識，下面我們要啟動發動機了。 ### 二、簡單示例（取自[AwesomeWanAndroid](https://github.com/JsonChao/Awesome-WanAndroid)） #### 1、首先，創建一個BaseActivityComponent的Subcomponent： ~~~ @Subcomponent(modules = {AndroidInjectionModule.class}) public interface BaseActivityComponent extends AndroidInjector<BaseActivity> { @Subcomponent.Builder abstract class BaseBuilder extends AndroidInjector.Builder<BaseActivity>{ } } ~~~ 這里必須要注解成@Subcomponent.Builder表示是頂級@Subcomponent的內部類。AndroidInjector.Builder的泛型指定了BaseActivity，即表示每一個繼承于BaseActivity的Activity都繼承于同一個子組件（BaseActivityComponent）。 #### 2、然后，創建一個將會導入Subcomponent的公有Module。 ~~~ // 1 @Module(subcomponents = {BaseActivityComponent.class}) public abstract class AbstractAllActivityModule { @ContributesAndroidInjector(modules = MainActivityModule.class) abstract MainActivity contributesMainActivityInjector(); @ContributesAndroidInjector(modules = SplashActivityModule.class) abstract SplashActivity contributesSplashActivityInjector(); // 一系列的對應Activity的contributesxxxActivityInjector ... } ~~~ 在注釋1處用subcomponents來表示開放全部依賴給AbstractAllActivityModule，使用Subcomponent的重要原因是它將應用的不同部分封裝起來了。**@AppComponent負責維護共享的數據和對象，而不同處則由各自的@Subcomponent維護**。 #### 3、接著，配置項目的Application。 ~~~ public class WanAndroidApp extends Application implements HasActivityInjector { // 3 @Inject DispatchingAndroidInjector<Activity> mAndroidInjector; private static volatile AppComponent appComponent; @Override public void onCreate() { super.onCreate(); ... // 1 appComponent = DaggerAppComponent.builder() .build(); // 2 appComponent.inject(this); ... } ... // 4 @Override public AndroidInjector<Activity> activityInjector() { return mAndroidInjector; } } ~~~ 首先，在注釋1處，使用AppModule模塊和httpModule模塊構建出AppComponent的實現類DaggerAppComponent。這里看一下AppComponent的配置代碼： ~~~ @Singleton @Component(modules = {AndroidInjectionModule.class, AndroidSupportInjectionModule.class, AbstractAllActivityModule.class, AbstractAllFragmentModule.class, AbstractAllDialogFragmentModule.class} ) public interface AppComponent { /** * 注入WanAndroidApp實例 * * @param wanAndroidApp WanAndroidApp */ void inject(WanAndroidApp wanAndroidApp); ... } ~~~ 可以看到，AppComponent依賴了AndroidInjectionModule模塊，它包含了一些基礎配置的綁定設置，如activityInjectorFactories、fragmentInjectorFactories等等，而AndroidSupportInjectionModule模塊顯然就是多了一個supportFragmentInjectorFactories的綁定設置，activityInjectorFactories的內容如所示： ~~~ @Beta @Module public abstract class AndroidInjectionModule { @Multibinds abstract Map<Class<? extends Activity>, AndroidInjector.Factory<? extends Activity>> activityInjectorFactories(); @Multibinds abstract Map<Class<? extends Fragment>, AndroidInjector.Factory<? extends Fragment>> fragmentInjectorFactories(); ... } ~~~ 接著，下面依賴的AbstractAllActivityModule、 AbstractAllFragmentModule、AbstractAllDialogFragmentModule則是為項目的所有Activity、Fragment、DialogFragment提供的統一基類抽象Module，這里看下AbstractAllActivityModule的配置： ~~~ @Module(subcomponents = {BaseActivityComponent.class}) public abstract class AbstractAllActivityModule { @ContributesAndroidInjector(modules = MainActivityModule.class) abstract MainActivity contributesMainActivityInjector(); @ContributesAndroidInjector(modules = SplashActivityModule.class) abstract SplashActivity contributesSplashActivityInjector(); ... } ~~~ 可以看到，項目下的所有xxxActiviity都有對應的contributesxxxActivityInjector()方法提供實例注入。并且，注意到AbstractAllActivityModule這個模塊依賴的 subcomponents為BaseActivityComponent，前面說過了，每一個繼承于BaseActivity的Activity都繼承于BaseActivityComponent這一個subcomponents。同理，AbstractAllFragmentModule與AbstractAllDialogFragmentModule也是類似的實現模式，如下所示： ~~~ // 1 @Module(c = BaseFragmentComponent.class) public abstract class AbstractAllFragmentModule { @ContributesAndroidInjector(modules = CollectFragmentModule.class) abstract CollectFragment contributesCollectFragmentInject(); @ContributesAndroidInjector(modules = KnowledgeFragmentModule.class) abstract KnowledgeHierarchyFragment contributesKnowledgeHierarchyFragmentInject(); ... } // 2 @Module(subcomponents = BaseDialogFragmentComponent.class) public abstract class AbstractAllDialogFragmentModule { @ContributesAndroidInjector(modules = SearchDialogFragmentModule.class) abstract SearchDialogFragment contributesSearchDialogFragmentInject(); @ContributesAndroidInjector(modules = UsageDialogFragmentModule.class) abstract UsageDialogFragment contributesUsageDialogFragmentInject(); } ~~~ 注意到注釋1和注釋2處的代碼，AbstractAllFragmentModule和AbstractAllDialogFragmentModule的subcomponents為BaseFragmentComponent、BaseDialogFragmentComponent，很顯然，同AbstractAllActivityModule的子組件BaseActivityComponent一樣，它們都是作為一個通用的子組件。然后，回到我們配置項目下的Application下面的注釋2處的代碼，在這里使用了第一步Dagger為我們構建的DaggerAppComponent對象將當期的Application實例注入了進去，交給了Dagger這個依賴大管家去管理。最終，**Dagger2內部創建的mAndroidInjector對象會在注釋3處的地方進行實例賦值。在注釋4處，實現HasActivityInjector接口，重寫activityInjector()方法，將我們上面得到的mAndroidInjector對象返回**。這里的mAndroidInjector是一個類型為DispatchingAndroidInjector的對象，可以這樣理解它：它能夠執行Android框架下的核心成員如Activity、Fragment的成員注入，在我們項目下的Application中將DispatchingAndroidInjector的泛型指定為Activity就說明它承擔起了所有Activity成員依賴的注入。那么，如何指定某一個Activity能被納入DispatchingAndroidInjector這個所有Activity的依賴總管的口袋中呢？接著看使用步驟4。 #### 4、最后，將目標Activity納入Activity依賴分配總管DispatchingAndroidInjector的囊中。很簡單，只需在目標Activity的onCreate()方法前的super.onCreate(savedInstanceState)前配置一行代碼 AndroidInjection.inject(this)，如下所示： ~~~ public abstract class BaseActivity<T extends AbstractPresenter> extends AbstractSimpleActivity implements AbstractView { ... @Inject protected T mPresenter; @Override protected void onCreate(@Nullable Bundle savedInstanceState) { AndroidInjection.inject(this); super.onCreate(savedInstanceState); } ... } ~~~ 這里使用了@Inject表明了需要注入mPresenter實例，然后，我們需要在具體的Presenter類的構造方法上使用@Inject提供基于當前構造方法的mPresenter實例，如下所示： ~~~ public class MainPresenter extends BasePresenter<MainContract.View> implements MainContract.Presenter { ... @Inject MainPresenter(DataManager dataManager) { super(dataManager); this.mDataManager = dataManager; } ... } ~~~ 從上面的使用流程中，有三個關鍵的核心實現是我們需要了解的，如下所示： * 1、appComponent = DaggerAppComponent.builder().build()這句代碼如何構建出DaggerAPPComponent的？ * 2、appComponent.inject(this)是如何將mAndroidInjector實例賦值給當前的Application的？ * 3、在目標Activity下的AndroidInjection.inject(this)這句代碼是如何將當前Activity對象納入依賴分配總管DispatchingAndroidInjector囊中的呢？下面，讓我們來逐個一一地來探索其中的奧妙吧~ ### 三、DaggerAppComponent.builder().build()是如何構建出DaggerAPPComponent的？首先，我們看到DaggerAppComponent的builder()方法： ~~~ public static Builder builder() { return new Builder(); } ~~~ 里面直接返回了一個新建的Builder靜態內部類對象，看看它的構造方法中做了什么： ~~~ public static final class Builder { private Builder() {} ... } ~~~ 看來，Builder的默認構造方法什么也沒有做，那么，真正的實現肯定在Builder對象的build()方法中，接著看到build()方法。 ~~~ public static final class Builder { ... public AppComponent build() { return new DaggerAppComponent(this); } ... } ~~~ 在Builder的build()方法中直接返回了新建的DaggerAppComponent對象。下面，看看DaggerAppComponent的構造方法: ~~~ private DaggerAppComponent(Builder builder) { initialize(builder); } ~~~ 在DaggerAppComponent的構造方法中調用了initialize方法，顧名思義，它就是真正初始化項目全局依賴配置的地方了，下面，來看看它內部的實現： ~~~ private void initialize(final Builder builder) { // 1 this.mainActivitySubcomponentBuilderProvider = new Provider< AbstractAllActivityModule_ContributesMainActivityInjector.MainActivitySubcomponent .Builder>() { @Override public AbstractAllActivityModule_ContributesMainActivityInjector.MainActivitySubcomponent .Builder get() { // 2 return new MainActivitySubcomponentBuilder(); } }; // 一系列xxxActivitySubcomponentBuilderProvider的創建賦值代碼塊 ... } ~~~ 在注釋1處，新建了一個mainActivit的子組件構造器實例提供者Provider。在注釋2處，使用匿名內部類的方式重寫了該Provider的get()方法，返回一個新創建好的MainActivitySubcomponentBuilder對象。很顯然，它就是負責創建管理MAinActivity中所需依賴的Subcomponent建造者。接下來我們重點來分析下MainActivitySubcomponentBuilder這個類的作用。 ~~~ // 1 private final class MainActivitySubcomponentBuilder extends AbstractAllActivityModule_ContributesMainActivityInjector.MainActivitySubcomponent .Builder { private MainActivity seedInstance; @Override public AbstractAllActivityModule_ContributesMainActivityInjector.MainActivitySubcomponent build() { if (seedInstance == null) { throw new IllegalStateException(MainActivity.class.getCanonicalName() + " must be set"); } // 2 return new MainActivitySubcomponentImpl(this); } @Override public void seedInstance(MainActivity arg0) { // 3 this.seedInstance = Preconditions.checkNotNull(arg0); } } ~~~ 首先，在注釋1處，MainActivitySubcomponentBuilder繼承了AbstractAllActivityModule\_ContributesMainActivityInjector內部的子組件MainActivitySubcomponent的內部的子組件建造者類Builder，如下所示： ~~~ @Subcomponent(modules = MainActivityModule.class) public interface MainActivitySubcomponent extends AndroidInjector<MainActivity> { @Subcomponent.Builder abstract class Builder extends AndroidInjector.Builder<MainActivity> {} } ~~~ 可以看到，這個子組件建造者Builder又繼承了AndroidInjector的抽象內部類Builder，那么，這個AndroidInjector到底是什么呢？顧名思義，**AndroidInjector**是一個Android注射器，它**為每一個具體的子類型，即核心Android類型Activity和Fragment執行成員注入。** 接下來我們便來分析下AndroidInjector的內部實現，源碼如下所示： ~~~ public interface AndroidInjector<T> { void inject(T instance); // 1 interface Factory<T> { AndroidInjector<T> create(T instance); } // 2 abstract class Builder<T> implements AndroidInjector.Factory<T> { @Override public final AndroidInjector<T> create(T instance) { seedInstance(instance); return build(); } @BindsInstance public abstract void seedInstance(T instance); public abstract AndroidInjector<T> build(); } } ~~~ 在注釋1處，使用了抽象工廠模式，用來創建一個具體的Activity或Fragment類型的AndroidInjector實例。注釋2處，Builder實現了AndroidInjector.Factory，它是一種Subcomponent.Builder的通用實現模式，在重寫的create()方法中，進行了實例保存seedInstance()和具體Android核心類型的構建。接著，我們回到MainActivitySubcomponentBuilder類，可以看到，它實現了AndroidInjector.Builder的seedInstance()和build()方法。在注釋3處首先播種了MainActivity的實例，然后在注釋2處新建了一個MainActivitySubcomponentImpl對象返回。我們看看MainActivitySubcomponentImpl這個類是如何將mPresenter依賴注入的，相關源碼如下： ~~~ private final class MainActivitySubcomponentImpl implements AbstractAllActivityModule_ContributesMainActivityInjector .MainActivitySubcomponent { private MainPresenter getMainPresenter() { // 2 return MainPresenter_Factory.newMainPresenter( DaggerAppComponent.this.provideDataManagerProvider.get()); } @Override public void inject(MainActivity arg0) { // 1 injectMainActivity(arg0); } private MainActivity injectMainActivity(MainActivity instance) { // 3 BaseActivity_MembersInjector .injectMPresenter(instance, getMainPresenter()); return instance; } ~~~ 在注釋1處，MainActivitySubcomponentImpl實現了AndroidInjector接口的inject()方法，**在injectMainActivity()首先調用getMainPresenter()方法從MainPresenter\_Factory工廠類中新建了一個MainPresenter對象**。我們看看MainPresenter的newMainPresenter()方法： ~~~ public static MainPresenter newMainPresenter(DataManager dataManager) { return new MainPresenter(dataManager); } ~~~ 這里直接新建了一個MainPresenter。然后我們回到MainActivitySubcomponentImpl類的注釋3處，繼續調用了**BaseActivity\_MembersInjector的injectMPresenter()方法**，顧名思義，可以猜到，它是BaseActivity的成員注射器，繼續看看injectMPresenter()內部： ~~~ public static <T extends AbstractPresenter> void injectMPresenter( BaseActivity<T> instance, T mPresenter) { instance.mPresenter = mPresenter; } ~~~ 可以看到，這里直接將需要的mPresenter實例賦值給了BaseActivity的mPresenter，當然，這里其實是指的BaseActivity的子類MainActivity，其它的xxxActivity的依賴管理機制都是如此。 ### 四、appComponent.inject(this)是如何將mAndroidInjector實例賦值給當前的Application的？我們繼續查看appComponent的inject()方法： ~~~ @Override public void inject(WanAndroidApp wanAndroidApp) { injectWanAndroidApp(wanAndroidApp); } ~~~ 在inject()方法里調用了injectWanAndroidApp()，繼續查看injectWanAndroidApp()方法： ~~~ private WanAndroidApp injectWanAndroidApp(WanAndroidApp instance) { WanAndroidApp_MembersInjector.injectMAndroidInjector( instance, getDispatchingAndroidInjectorOfActivity()); return instance; } ~~~ 首先，執行getDispatchingAndroidInjectorOfActivity()方法得到了一個Activity類型的DispatchingAndroidInjector對象，繼續查看getDispatchingAndroidInjectorOfActivity()方法： ~~~ private DispatchingAndroidInjector<Activity> getDispatchingAndroidInjectorOfActivity() { return DispatchingAndroidInjector_Factory.newDispatchingAndroidInjector( getMapOfClassOfAndProviderOfFactoryOf()); } ~~~ 在getDispatchingAndroidInjectorOfActivity()方法里面，首先調用了getMapOfClassOfAndProviderOfFactoryOf()方法，我們看到這個方法： ~~~ private Map<Class<? extends Activity>, Provider<AndroidInjector.Factory<? extends Activity>>> getMapOfClassOfAndProviderOfFactoryOf() { return MapBuilder .<Class<? extends Activity>, Provider<AndroidInjector.Factory<? extends Activity>>> newMapBuilder(8) .put(MainActivity.class, (Provider) mainActivitySubcomponentBuilderProvider) .put(SplashActivity.class, (Provider) splashActivitySubcomponentBuilderProvider) .put(ArticleDetailActivity.class, (Provider) articleDetailActivitySubcomponentBuilderProvider) .put(KnowledgeHierarchyDetailActivity.class, (Provider) knowledgeHierarchyDetailActivitySubcomponentBuilderProvider) .put(LoginActivity.class, (Provider) loginActivitySubcomponentBuilderProvider) .put(RegisterActivity.class, (Provider) registerActivitySubcomponentBuilderProvider) .put(AboutUsActivity.class, (Provider) aboutUsActivitySubcomponentBuilderProvider) .put(SearchListActivity.class, (Provider) searchListActivitySubcomponentBuilderProvider) .build(); } ~~~ 可以看到，這里新建了一個建造者模式實現的MapBuilder，并且同時制定了固定容量為8，將項目下使用了AndroidInjection.inject(mActivity)方法的8個Activity對應的xxxActivitySubcomponentBuilderProvider保存起來。我們再回到getDispatchingAndroidInjectorOfActivity()方法，這里將上面得到的Map容器傳入了DispatchingAndroidInjector\_Factory的newDispatchingAndroidInjector()方法中，這里應該就是新建DispatchingAndroidInjector的地方了。我們點進去看看： ~~~ public static <T> DispatchingAndroidInjector<T> newDispatchingAndroidInjector( Map<Class<? extends T>, Provider<AndroidInjector.Factory<? extends T>>> injectorFactories) { return new DispatchingAndroidInjector<T>(injectorFactories); } ~~~ 在這里，果然新建了一個DispatchingAndroidInjector對象。繼續看看DispatchingAndroidInjector的構造方法： ~~~ @Inject DispatchingAndroidInjector( Map<Class<? extends T>, Provider<AndroidInjector.Factory<? extends T>>> injectorFactories) { this.injectorFactories = injectorFactories; } ~~~ 這里僅僅是將傳進來的Map容器保存起來了。我們再回到WanAndroidApp\_MembersInjector的injectMAndroidInjector()方法，將上面得到的DispatchingAndroidInjector實例傳入，繼續查看injectMAndroidInjector()這個方法： ~~~ public static void injectMAndroidInjector( WanAndroidApp instance, DispatchingAndroidInjector<Activity> mAndroidInjector) { instance.mAndroidInjector = mAndroidInjector; } ~~~ 可以看到，最后在WanAndroidApp\_MembersInjector的injectMAndroidInjector()方法中，直接將新建好的DispatchingAndroidInjector實例賦值給了WanAndroidApp的mAndroidInjector。 ### 五、在目標Activity下的AndroidInjection.inject(this)這句代碼是如何將當前Activity對象納入依賴分配總管DispatchingAndroidInjector囊中的呢？首先，我們看到AndroidInjection.inject(this)這個方法： ~~~ public static void inject(Activity activity) { checkNotNull(activity, "activity"); // 1 Application application = activity.getApplication(); if (!(application instanceof HasActivityInjector)) { throw new RuntimeException( String.format( "%s does not implement %s", application.getClass().getCanonicalName(), HasActivityInjector.class.getCanonicalName())); } // 2 AndroidInjector<Activity> activityInjector = ((HasActivityInjector) application).activityInjector(); checkNotNull(activityInjector, "%s.activityInjector() returned null", application.getClass()); // 3 activityInjector.inject(activity); } ~~~ 在注釋1處，會先判斷當前的application是否實現了HasActivityInjector這個接口，如果沒有，則拋出RuntimeException。如果有，會繼續在注釋2處調用application的activityInjector()方法得到DispatchingAndroidInjector實例。最后，在注釋3處，會將當前的activity實例傳入activityInjector的inject()方法中。我們繼續查看inject()方法： ~~~ @Override public void inject(T instance) { boolean wasInjected = maybeInject(instance); if (!wasInjected) { throw new IllegalArgumentException(errorMessageSuggestions(instance)); } } ~~~ **DispatchingAndroidInjector的inject()方法，它的作用就是給傳入的instance實例執行成員注入**。具體在這個案例中，其實就是負責將創建好的Presenter實例賦值給BaseActivity對象的mPresenter全局變量。在inject()方法中，又調用了maybeInject()方法，我們繼續查看它： ~~~ @CanIgnoreReturnValue public boolean maybeInject(T instance) { // 1 Provider<AndroidInjector.Factory<? extends T>> factoryProvider = injectorFactories.get(instance.getClass()); if (factoryProvider == null) { return false; } @SuppressWarnings("unchecked") // 2 AndroidInjector.Factory<T> factory = (AndroidInjector.Factory<T>) factoryProvider.get(); try { // 3 AndroidInjector<T> injector = checkNotNull( factory.create(instance), "%s.create(I) should not return null.", factory.getClass()); // 4 injector.inject(instance); return true; } catch (ClassCastException e) { ... } } ~~~ 在注釋1處，我們從injectorFactories（前面得到的Map容器）中根據當前Activity實例拿到了factoryProvider對象，這里我們具體一點，看到MainActivity對應的factoryProvider，也就是我們研究的第一個問題中的mainActivitySubcomponentBuilderProvider： ~~~ private void initialize(final Builder builder) { this.mainActivitySubcomponentBuilderProvider = new Provider< AbstractAllActivityModule_ContributesMainActivityInjector.MainActivitySubcomponent .Builder>() { @Override public AbstractAllActivityModule_ContributesMainActivityInjector.MainActivitySubcomponent .Builder get() { return new MainActivitySubcomponentBuilder(); } }; ... } ~~~ 在maybeInject()方法的注釋2處，調用了mainActivitySubcomponentBuilderProvider的get()方法得到了一個新建的MainActivitySubcomponentBuilder對象。在注釋3處執行了它的create方法，create()方法的具體實現在AndroidInjector的內部類Builder中： ~~~ abstract class Builder<T> implements AndroidInjector.Factory<T> { @Override public final AndroidInjector<T> create(T instance) { seedInstance(instance); return build(); } ~~~ 看到這里，我相信看過第一個問題的同學已經明白后面是怎么回事了。在create()方法中，我們首先MainActivitySubcomponentBuilder的seedInstance()將MainActivity實例注入，然后再調用它的build()方法新建了一個MainActivitySubcomponentImpl實例返回。最后，在注釋4處，執行了MainActivitySubcomponentImpl的inject()方法： ~~~ private final class MainActivitySubcomponentImpl implements AbstractAllActivityModule_ContributesMainActivityInjector .MainActivitySubcomponent { private MainPresenter getMainPresenter() { // 2 return MainPresenter_Factory.newMainPresenter( DaggerAppComponent.this.provideDataManagerProvider.get()); } @Override public void inject(MainActivity arg0) { // 1 injectMainActivity(arg0); } private MainActivity injectMainActivity(MainActivity instance) { // 3 BaseActivity_MembersInjector .injectMPresenter(instance, getMainPresenter()); return instance; } ~~~ 這里的邏輯已經在問題一的最后部分詳細講解了，最后，會在注釋3處調用BaseActivity\_MembersInjector的injectMPresenter()方法： ~~~ public static <T extends AbstractPresenter> void injectMPresenter( BaseActivity<T> instance, T mPresenter) { instance.mPresenter = mPresenter; } ~~~ 這樣，就將mPresenter對象賦值給了當前Activity對象的mPresenter全局變量中了。至此，Dagger.Android的核心源碼分析就結束了。 ### 六、總結相比于ButterKnife，Dagger是一個**鋒利的全局依賴注入管理框架**，它主要用來**管理對象的依賴關系和生命周期**，當項目越來越大時，類之間的調用層次會越來越深，并且有些類是Activity或Fragment，有些是單例，而且它們的生命周期不一致，所以創建所需對象時需要處理的各個對象的依賴關系和生命周期時的任務會很繁重。因此，使用Dagger會大大減輕這方面的工作量。雖然它的學習成本比較高，而且需要寫一定的模板類，但是，**對于越大的項目來說，Dagger越值得被需要**。下一篇，便是Android主流三方庫源碼分析系列的終結篇了，筆者將會對Android中的事件總線框架EventBus源碼進行深入的分析，敬請期待~ ##### 參考鏈接： * * * 1、Dagger V2.1.5 源碼 2、Android進階之光 3、[告別Dagger2模板代碼：DaggerAndroid原理解析](https://blog.csdn.net/mq2553299/article/details/77725912) 4、[Android Dagger2 從零單排](https://www.jianshu.com/p/7ee1a1100fab) 鏈接：https://juejin.im/post/5e58779f518825493f6ce7eb