【從零開始擼一個App】Dagger2

Dagger2是一個IOC框架，通常用於Android平臺，第一次接觸的朋友，必定會被搞得暈頭轉向。它延續了Java平臺Spring框架代碼碎片化，註解滿天飛的傳統。嘗試將各處代碼片斷串聯起來，理清思緒，真不是件容易的事。更不用說還有各版本細微的差異。
與Spring不一樣的是，Spring是經過反射建立對象的，而Dagger2是[經過apt插件]在編譯期間生成代碼，這些生成的代碼負責依賴對象建立。

本文旨在以簡單通俗易懂的方式說明如何使用Dagger2，對其背後設計不作深刻探討。人生苦短，碼農更甚，先知其然等有空時再知其因此然，不失爲擼App的較好實踐。

正式開始前，先給像筆者這樣的小白定義幾個概念，方便下文理解：

• 依賴對象：好比bean，被其它類所需（依賴）的對象，須要以某種方式注入到目標對象中。
• 目標對象：依賴對象的需求方，注入者將依賴對象注入其中。
• 注入者/[依賴對象的]容器：維護依賴對象，將依賴對象注入到目標對象的工具類。

---

入門

首先，添加依賴庫。

implementation "com.google.dagger:dagger:2.27"
    // kapt是服務於Kotlin的Annotation Processing Tool，用於編譯時處理註解
    kapt "com.google.dagger:dagger-compiler:2.27"

通常來講，IOC會根據規則在運行時自動幫咱們生成依賴對象實例。Dagger2提供了兩種聲明依賴對象的方式：

• 構造函數有@Inject修飾。
• @Module修飾的類中所定義的有@Provides修飾的方法提供（可用於依賴對象是第三方庫中的對象）。

// 方式一（注意此處hen也要是依賴對象，不然將爲null或者直接報錯）
class Egg @Inject constructor(private val hen: Hen)

// 方式二
@Module
class HenModule {
    @Singleton
    @Provides
    fun provideHen() = Hen()
}

你們注意@Singleton註解（javax.inject中定義），它表示該依賴對象的做用域或者說生命週期，Dagger2中可經過@Scope定義。@Singleton是Dagger2默認支持的scope，表示依賴對象是單例。須要注意的是，一般咱們將單例保存在一個靜態域中，這樣的單例每每要等到虛擬機關閉時候，所佔用的資源才釋放，可是，Dagger經過Singleton建立出來的單例並不保持在靜態域上，而是保留在一樣標註了@Singleton的Component實例中（依賴對象容器，接下來會講到）。其實對於任意scope，只要依賴對象和Component標註的是相同scope，那麼該依賴對象在相應的Component中就是一個局部單例，僅會調用一次工廠類生成對象實例。通常來講咱們只要使用默認的@Singleton便可，不必自定義，自定義Scope經常使用於業務或邏輯的劃分。
若是不想依賴對象與Component綁定，則可使用@Reusable做用域。

上面說的Component是@Component註解修飾的接口，Dagger2會先尋找它，以此爲入口獲得全部依賴對象。該接口中可定義相似void inject(Target target)的方法。顯然，@Component註解的接口就是注入者，它將依賴對象和目標對象串聯了起來。

@Singleton
@Component(modules = [HenModule::class]) //依賴對象
interface MyAppComponent {
    fun inject(activity: MainActivity); //目標對象
}

最後咱們就能夠在目標對象中愉快地使用依賴對象了。

class MainActivity : AppCompatActivity() {
    @Inject
    lateinit var hen: Hen

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        DaggerMyAppComponent.builder().build().inject(this); // 關鍵
    }
}

---

改進

如上，對於Activity/Fragment來講，它們的實例化是系統完成的，所以咱們只能在它們使用以前的某個環節好比onCreate回調方法內手動將其自身依附到Dagger2中，這產生了至少一個問題：這種方式破壞了依賴注入的核心準則：一個類不該該知道它是如何被注入的。爲了解決這個問題，Dagger 2.10版本引入的dagger-android，它是一個專爲Android設計的除了Dagger主模塊以外的全新模塊。

首先，新增兩個依賴庫。

implementation "com.google.dagger:dagger-android:2.27"
    kapt "com.google.dagger:dagger-android-processor:2.27"

針對每一個目標類編寫對應的子容器代碼：

@Subcomponent(modules = [HenModule::class])
interface MainActivitySubcomponent : AndroidInjector<MainActivity?> {
    @Subcomponent.Builder
    abstract class Builder : AndroidInjector.Factory<MainActivity?>
}

再針對每一個目標類編寫對應的依賴對象代碼：

@Module(subcomponents = MainActivitySubcomponent::class)
abstract class MainActivityModule {
    @Binds
    @IntoMap
    @ActivityKey(MainActivity::class)
    abstract fun bindMainActivityInjectorFactory(builder: MainActivitySubcomponent.Builder?): AndroidInjector.Factory<out Activity?>?
}

修改以前的MyAppComponent代碼：

@Singleton
@Component(modules = [AndroidInjectionModule::class,MainActivityModule::class]) // 關鍵，引入AndroidInjectionModule
interface MyAppComponent {
    fun inject(app: MyApplication); //注入到Application
}

Application須要繼承HasActivityInjector，實現inject方法，返回DispatchingAndroidInjector對象。

class MyApplication : Application(), HasActivityInjector {
    // 由dagger.android自動注入
    @Inject
    lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector<Activity>

    override fun androidInjector() = dispatchingAndroidInjector

    override fun onCreate() {
        super.onCreate()
        DaggerMyAppComponent.builder().build().inject(this)
    }
}

建立一個BaseActivity，在super.onCreate以前調用AndroidInjection.inject(this)，這樣以後的Activity就只須要繼承它，就可使用各自的依賴對象了。

open class BaseActivity: AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        AndroidInjection.inject(this)
        super.onCreate(savedInstanceState)
    }
}

class MainActivity : BaseActivity() {
    @Inject
    lateinit var hen: Hen

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        //DaggerMyAppComponent.builder().build().inject(this); // 不須要了
    }
}

可見，爲了解決前述問題，引入了更多的代碼，複雜度也提升了，這是否有必要，值得商榷。好在Dagger2提供了@ContributesAndroidInjector註解解決了這個問題。

---

再改進

1. 刪除前述的MainActivitySubcomponent和MainActivityModule；
2. 建立基於BaseActivity類型的容器（非必須）：

@Subcomponent
interface ActivityComponet: AndroidInjector<BaseActivity>{
    @Subcomponent.Builder
    abstract class Builder: AndroidInjector.Builder<BaseActivity>()
}

3. 建立ActivityModule，管理全部Activity。注意@ContributesAndroidInjector註解的使用。

@Module(subcomponents = [ActivityComponet::class])
abstract class ActivityModule{
    @ContributesAndroidInjector
    abstract fun mainActivityInjector(): MainActivity
}

4. 修改以前的MyAppComponent代碼：

@Singleton
@Component(modules = [AndroidInjectionModule::class,ActivityModule::class]) // MainActivityModule改成ActivityModule
interface MyAppComponent {
    fun inject(app: MyApplication);
}

大功告成！咱們不再須要重複地建立XXXActivityModule和XXXActivitySubcomponent類了。
參看Dagger & Android

---

後記拾遺

@BindsInstance：編譯後會在Component的Builder類中生成修飾的方法裏面的參數對應的成員變量，so該變量對應的對象可在與該Component相關的Module中經過@Inject注入，可看做是該Component範圍內的全局單例，相似於上述的@Scope的做用。

Dagger 2.22 起引入了 @Component.Factory, 能夠取代@Component.Builder的使用，Factory在許多場景的上的使用相對於Builder會更簡單。

Dagger 2.23新增了一個HasAndroidInjector接口，用於替代HasActivityInjector, HasServiceInjector, HasBroadcastReceiverInjector, HasSupportFragmentInjector四個接口，讓Application中的代碼更簡潔，目前仍是beta版。通常若是咱們只須要HasActivityInjector的話那也無所謂了。參看Reducing Boilerplate with the new HasAndroidInjector in Dagger 2.23

瞭解一下javax.inject，這個是 Java EE 6 規範 JSR 330 -- Dependency Injection for Java 中的東西， Spring、Guice兼容該規範。

Assisted Injection：彷佛是Guice引入的一個概念？——
Sometimes a class gets some of its constructor parameters from the Injector and others from the caller. 對於這種狀況，咱們常封裝一個工廠類，該類內部提供了注入類型的實例化，對外暴露一個生產方法，該方法只接收須要外部傳入的參數。若是以爲手寫這種工廠類太過麻煩或工做量太大，那麼可使用AssistedInject自動生成。參看AssistedInject，Assisted Injection for JSR 330

拋棄dagger-android：雖然最終改進以後，代碼變得清晰不少，但內在邏輯反而更加複雜了。這種[理解門檻較高的]複雜度就像一顆定時炸彈，讓人夜不能寐。當我使用到ViewModel以後發現，也能夠不引入dagger-android，而是將全部依賴注入到ViewModel中，再由ViewModel暴露給系統組件。然而因爲框架所限，其實否則——ViewModel是由Android框架自己維護的，固然框架也給咱們留了一個自定義provider viewmodel的口子，就是ViewModelProvider.Factory——這又是一項頗費腦力的工程，參看How to Inject ViewModel using Dagger 2。這步完成之後，咱們再將ViewModelProvider.Factory實例注入到Application中，變爲一個全局工廠對象，Activity/Fragment直接拿來用便可，不再須要與依賴注入有任何瓜葛，天然也不須要dagger-android了。也有大神跟我想到一塊，參看當Dagger2撞上ViewModel

---

參考資料

Dagger2從入門到放棄再到恍然大悟
Dagger2 @Component 和@SubComponent 區別解惑
學習Dagger2筆記
dagger.android(Dagger2中的AndroidInjector)使用解析
Dagger2 中的 Binds、IntoSet、IntoMap
dagger android 學習（一）：dagger基礎使用
Dagger2在Android平臺上的新魔法（做者瞭解了dagger-android背後的原理後棄用）