【從零開始擼一個App】Dagger2

萊布尼茨發表於2020-08-04
APP

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>()
}
  1. 建立ActivityModule，管理所有Activity。注意@ContributesAndroidInjector註解的使用。
@Module(subcomponents = [ActivityComponet::class])
abstract class ActivityModule{
    @ContributesAndroidInjector
    abstract fun mainActivityInjector(): MainActivity
}
  1. 修改之前的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背後的原理後棄用）

相關文章