【從零開始擼一個App】Dagger2
阿新 • • 發佈:2020-08-04
Dagger2是一個IOC框架,一般用於Android平臺,第一次接觸的朋友,一定會被搞得暈頭轉向。它延續了Java平臺Spring框架程式碼碎片化,註解滿天飛的傳統。嘗試將各處程式碼片段串聯起來,理清思緒,真不是件容易的事。更不用說還有各版本細微的差別。
*與Spring不同的是,Spring是通過反射建立物件的,而Dagger2是\[通過apt外掛\]在**編譯**期間生成程式碼,這些生成的程式碼負責依賴物件建立。*
本文旨在以簡單通俗易懂的方式說明如何使用Dagger2,對其背後設計不做深入探討。人生苦短,碼農更甚,先知其然等有空時再知其所以然,不失為擼App的較好實踐。
正式開始前,先給像筆者這樣的小白定義幾個概念,方便下文理解:
+ 依賴物件:比如bean,被其它類所需(依賴)的物件,需要以某種方式注入到目標物件中。
+ 目標物件:依賴物件的需求方,注入者將依賴物件注入其中。
+ 注入者/\[依賴物件的\]容器:維護依賴物件,將依賴物件注入到目標物件的工具類。
---
##入門
首先,新增依賴庫。
```gradle
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`修飾的方法提供(可用於依賴物件是第三方庫中的物件)。
```kotlin
// 方式一(注意此處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註解的介面就是注入者,它將依賴物件和目標物件串聯了起來。
```kotlin
@Singleton
@Component(modules = [HenModule::class]) //依賴物件
interface MyAppComponent {
fun inject(activity: MainActivity); //目標物件
}
```
最後我們就可以在目標物件中愉快地使用依賴物件了。
```kotlin
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主模組之外的全新模組。
首先,新增兩個依賴庫。
```gradle
implementation "com.google.dagger:dagger-android:2.27"
kapt "com.google.dagger:dagger-android-processor:2.27"
```
針對每個目標類編寫對應的子容器程式碼:
```kotlin
@Subcomponent(modules = [HenModule::class])
interface MainActivitySubcomponent : AndroidInjector {
@Subcomponent.Builder
abstract class Builder : AndroidInjector.Factory
}
```
再針對每個目標類編寫對應的依賴物件程式碼:
```kotlin
@Module(subcomponents = MainActivitySubcomponent::class)
abstract class MainActivityModule {
@Binds
@IntoMap
@ActivityKey(MainActivity::class)
abstract fun bindMainActivityInjectorFactory(builder: MainActivitySubcomponent.Builder?): AndroidInjector.Factory?
}
```
修改之前的MyAppComponent程式碼:
```kotlin
@Singleton
@Component(modules = [AndroidInjectionModule::class,MainActivityModule::class]) // 關鍵,引入AndroidInjectionModule
interface MyAppComponent {
fun inject(app: MyApplication); //注入到Application
}
```
`Application`需要繼承`HasActivityInjector`,實現inject方法,返回`DispatchingAndroidInjector`物件。
```kotlin
class MyApplication : Application(), HasActivityInjector {
// 由dagger.android自動注入
@Inject
lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector
override fun androidInjector() = dispatchingAndroidInjector
override fun onCreate() {
super.onCreate()
DaggerMyAppComponent.builder().build().inject(this)
}
}
```
建立一個BaseActivity,在super.onCreate之前呼叫`AndroidInjection.inject(this)`,這樣之後的Activity就只需要繼承它,就可以使用各自的依賴物件了。
```kotlin
open class BaseActivity: AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
AndroidInjection.inject(this)
super.onCreate(savedInstanceState)
}
}
```
```kotlin
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型別的容器(非必須):
```kotlin
@Subcomponent
interface ActivityComponet: AndroidInjector{
@Subcomponent.Builder
abstract class Builder: AndroidInjector.Builder()
}
```
3. 建立ActivityModule,管理所有Activity。注意@ContributesAndroidInjector註解的使用。
```kotlin
@Module(subcomponents = [ActivityComponet::class])
abstract class ActivityModule{
@ContributesAndroidInjector
abstract fun mainActivityInjector(): MainActivity
}
```
4. 修改之前的MyAppComponent程式碼:
```kotlin
@Singleton
@Component(modules = [AndroidInjectionModule::class,ActivityModule::class]) // MainActivityModule改為ActivityModule
interface MyAppComponent {
fun inject(app: MyApplication);
}
```
大功告成!我們再也不需要重複地建立XXXActivityModule和XXXActivitySubcomponent類了。
參看[Dagger & Android](https://dagger.dev/dev-guide/android.html)
---
##後記拾遺
`@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](https://medium.com/@runningcode/upgrading-to-the-new-hasandroidinjector-in-dagger-2-23-318f8ca35b2b)
*瞭解一下`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](https://github.com/google/guice/wiki/AssistedInject),[Assisted Injection for JSR 330](https://github.com/square/AssistedInject)
`拋棄dagger-android`:雖然最終改進之後,程式碼變得清晰很多,但內在邏輯反而更加複雜了。這種[理解門檻較高的]複雜度就像一顆定時炸彈,讓人夜不能寐。當我使用到`ViewModel`之後發現,也可以不引入dagger-android,而是將所有依賴注入到ViewModel中,再由ViewModel暴露給系統元件。然而由於框架所限,其實不然——ViewModel是由Android框架本身維護的,當然框架也給我們留了一個自定義provider viewmodel的口子,就是`ViewModelProvider.Factory`——這又是一項頗費腦力的工程,參看[How to Inject ViewModel using Dagger 2](https://www.techyourchance.com/dependency-injection-viewmodel-with-dagger-2/)。這步完成以後,我們再將ViewModelProvider.Factory例項注入到Application中,變為一個全域性工廠物件,Activity/Fragment直接拿來用即可,再也不需要與依賴注入有任何瓜葛,自然也不需要dagger-android了。也有大神跟我想到一塊,參看[當Dagger2撞上ViewModel](https://www.jianshu.com/p/d3c43b9dd6c6)
---
##參考資料
[Dagger2從入門到放棄再到恍然大悟](https://blog.csdn.net/hsk256/article/details/51530667)
[Dagger2 @Component 和@SubComponent 區別解惑](https://blog.csdn.net/soslinken/article/details/70231089)
[學習Dagger2筆記](https://blog.csdn.net/u012273376/article/details/90296512)
[dagger.android(Dagger2中的AndroidInjector)使用解析](https://www.jianshu.com/p/975a2648d077)
[Dagger2 中的 Binds、IntoSet、IntoMap](https://blog.csdn.net/lk_123456/article/details/90700535)
[dagger android 學習(一):dagger基礎使用](https://juejin.im/post/5cc71fb7e51d456e6479b4fe)
[Dagger2在Android平臺上的新魔法](https://www.jianshu.com/p/c01fdda42434)(作者瞭解了dagger-android背後的原理後