Android Hilt實戰初體驗: Dagger替換成Hilt

午後一小憩發表於2020-07-17

2020_07_16_00_05.png

在元件化AwesomeGithub專案中使用了Dagger來減少手動依賴注入程式碼。雖然它能自動化幫我們管理依賴項,但是寫過之後的應該都會體會到它還是有點繁瑣的。專案中到處充斥著Component,這讓我想起了傳統MVP模式的介面定義。

簡單來說就是費勁,有許多大量的類似定義。可能google也意識到這一點了,所以前不久釋出出了Hilt

Hilt

為了防止沒聽說過的小夥伴們一頭霧水,首先我們來了解下Hilt是什麼?

HiltAndroid的依賴注入庫,可減少在專案中執行手動依賴項注入的樣板程式碼。

Hilt通過為專案中的每個 Android 類提供容器並自動管理其生命週期,提供了一種在應用中使用 DI(依賴項注入)的標準方法。HiltDagger 的基礎上構建而成,因而能夠具有 Dagger 的編譯時正確性、執行時效能、可伸縮性。

那麼有的小夥伴可能會有疑問,既然已經有了Dagger那為什麼還要Hilt的呢?

HiltDagger的主要目標都是一致的:

  1. 簡化 Android 應用的 Dagger 相關基礎架構。
  2. 建立一組標準的元件和作用域,以簡化設定、提高可讀性以及在應用之間共享程式碼。
  3. 提供一種簡單的方法來為各種構建型別(如測試、除錯或釋出)配置不同的繫結。

但是Android中會例項化許多元件類,例如Activity,因此在應用中使用Dagger需要開發者編寫大量的樣板程式碼。Hilt可以減少這些樣板程式碼。

Hilt做的優化包括

  1. 無需編寫大量的Component程式碼
  2. Scope也會與Component自動繫結
  3. 預定義繫結,例如 ApplicationActivity
  4. 預定義的限定符,例如@ApplicationContext@ActivityContext

下面通過AwesomeGithubDagger來對比了解Hilt的具體使用。

依賴

使用之前將Hilt的依賴新增到專案中。

首先,將hilt-android-gradle-plugin外掛新增到專案的根級 build.gradle檔案中:

buildscript {
    ...
    dependencies {
        ...
        classpath 'com.google.dagger:hilt-android-gradle-plugin:2.28-alpha'
    }
}

然後,應用Gradle外掛並在app/build.gradle檔案中新增以下依賴項:

...
apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'
 
android {
    ...
}
 
dependencies {
    implementation "com.google.dagger:hilt-android:2.28-alpha"
    kapt "com.google.dagger:hilt-android-compiler:2.28-alpha"
}

Application類

使用Dagger時,需要一個AppComponent單例元件,專案中的其它SubComponent都將依賴於它,所以在AwesomeGithub中它大概是這個樣子

@Singleton
@Component(
    modules = [
        SubComponentModule::class,
        NetworkModule::class,
        ViewModelBuilderModule::class
    ]
)
interface AppComponent {
 
    @Component.Factory
    interface Factory {
        fun create(@BindsInstance applicationContext: Context): AppComponent
    }
 
    fun welcomeComponent(): WelcomeComponent.Factory
 
    fun mainComponent(): MainComponent.Factory
     
    ...
 
    fun loginComponent(): LoginComponent.Factory
 
}
 
@Module(
    subcomponents = [
        WelcomeComponent::class,
        MainComponent::class,
        ...
        LoginComponent::class
    ]
)
object SubComponentModule

上面的我已經省略了大半,是不是看起來很多,而且最重要的是很多重複的結構基本都是一樣的。所以Hilt基於這一點進行了簡化,將這些重複的編寫轉成構建的時候自動生成。

Hilt要做的很簡單,新增幾個註釋

@HiltAndroidApp
class App : Application() { ... }

所有的Hilt應用都必須包含一個帶@HiltAndroidApp註釋的Application。它將替代Dagger中的AppComponent

Android類

對於Android類,使用Dagger時需要定義SubComponent並將它依賴到Application類中。下面以WelcomeActivity為例。

@Subcomponent(modules = [WelcomeModule::class])
interface WelcomeComponent {
    @Subcomponent.Factory
    interface Factory {
        fun create(): WelcomeComponent
    }

    fun inject(activity: WelcomeActivity)
}
module的部分先不說,後面會提及

下面看Hilt的實現

@AndroidEntryPoint
class MainActivity : BaseHiltActivity<ActivityMainBinding, MainVM>() { ... }

Hilt要做的是新增@AndroidEntryPoint註釋即可。

驚訝,結合上面的,兩個註解就替換了Dagger的實現,現在是否體會到Hilt的簡潔?對新手來說也可以降低很大的學習成本。

目前Hilt支援下面Android

  1. Application (@HiltAndroidApp)
  2. Activity
  3. Fragment
  4. View
  5. Searvice
  6. BroadcastReceiver

有一點需要注意,如果使用@AndroidEntryPoint註釋了某個類,那麼依賴該類的其它類也需要新增。

典型的就是Fragment,所以除了Fragment還需要給依賴它的所有Activity進行註釋。

@AndroidEntryPoint的作用,對照一下Dagger就知道了。它會自動幫我們生成對應Android類的Componennt,並將其新增到Application類中。

@Inject

@Inject的使用基本與Dagger一致,可以用來定義構造方法或者欄位,宣告該構造方法或者欄位需要通過依賴獲取。

class UserRepository @Inject constructor(
    private val service: GithubService
) : BaseRepository() { ... }

@Module

Hilt模組也需要新增@Module註釋,與Dagger不同的是它還必須使用@InstallIn為模組新增註釋。目的是告知模組用在哪個Android類中。

@Binds

@Binds註釋會告知Hilt在需要提供介面的例項時要使用哪種實現。
它的用法與Dagger沒什麼區別

@Module
@InstallIn(ActivityComponent::class)
abstract class WelcomeModule {
 
    @Binds
    @IntoMap
    @ViewModelKey(WelcomeVM::class)
    abstract fun bindViewModel(viewModel: WelcomeVM): ViewModel
}

不同的是需要新增@InstallInActivityComponent::class用來表明該模組作用範圍為Activity

其實上面這塊對ViewModel的注入,使用Hilt時會自動幫我們編寫,這裡只是為了展示與Dagger的不同之處。後續會提到ViewModel的注入。

@Providers

提供一個FragmentManager的例項,首先是Dagger的使用

@Module
class MainProviderModule(private val activity: FragmentActivity) {
 
    @Provides
    fun providersFragmentManager(): FragmentManager = activity.supportFragmentManager
}

對比一下Hilt

@InstallIn(ActivityComponent::class)
@Module
object MainProviderModule {
 
    @Provides
    fun providerFragmentManager(@ActivityContext context: Context) = (context as FragmentActivity).supportFragmentManager
}

區別是在Hilt@Providers必須為static類並且構造方法不能有引數。

@ActivityContextHilt提供的預定限定符,它能提供來自與ActivityContext,對應的還有@ApplicationContext

提供的元件

對於之前提到的@InstallIn會關聯不同的Android類,除了@ActivityComponent還有以下幾種

hilt_1.png

對應的生命週期如下

hilt_2.png

同時還提供了相應的作用域

hilt_3.png

所以Hilt的預設提供將大幅提高開發效率,減少許多重複的定義

ViewModel

最後再來說下ViewModel的注入。如果你使用到了Jetpack相信少不了它的注入。

對於Dagger我們需要自定義一個ViewModelFactory,並且提供注入方式,例如在AwesomeGithubcomponentbridget模組中定義了ViewModelFactory

@Module
abstract class ViewModelBuilderModule {
 
    @Binds
    abstract fun bindViewModelFactory(factory: ViewModelFactory): ViewModelProvider.Factory
  
}
 
class ViewModelFactory @Inject constructor(private val creators: @JvmSuppressWildcards Map<Class<out ViewModel>, Provider<ViewModel>>) : ViewModelProvider.Factory {
 
    override fun <T : ViewModel?> create(modelClass: Class<T>): T {
        var creator = creators[modelClass]
        if (creator == null) {
            for ((key, value) in creators) {
                if (modelClass.isAssignableFrom(key)) {
                    creator = value
                }
            }
        }
 
        if (creator == null) {
            throw IllegalArgumentException("Unknown model class: $modelClass")
        }
 
        try {
            @Suppress("UNCHECKED_CAST")
            return creator.get() as T
        } catch (e: Exception) {
            throw RuntimeException()
        }
    }
 
}

通過@Inject來注入構造例項,但構造方法中需要提供Map型別的creators。這個時候可以使用@IntoMap,為了匹配Map的型別,需要定義一個@MapKey的註釋

@Target(AnnotationTarget.FUNCTION, AnnotationTarget.PROPERTY_GETTER, AnnotationTarget.PROPERTY_SETTER)
@Retention(AnnotationRetention.RUNTIME)
@MapKey
annotation class ViewModelKey(val value: KClass<out ViewModel>)

然後再到對應的元件下使用,例如匹配MainVM

@Module
abstract class MainModule {
 
    @Binds
    @IntoMap
    @ViewModelKey(MainVM::class)
    abstract fun bindViewModel(viewModel: MainVM): ViewModel
 
}

這樣就提供了Map<Class<MainVM>, MainVM>的引數型別,這時我們自定義的ViewModelFactory就能夠被成功注入。

例如basic模組裡面的BaseDaggerActivity

abstract class BaseDaggerActivity<V : ViewDataBinding, M : BaseVM> : AppCompatActivity() {

    protected lateinit var viewDataBinding: V

    @Inject
    lateinit var viewModelFactory: ViewModelProvider.Factory

    protected val viewModel by lazy { ViewModelProvider(this, viewModelFactory)[getViewModelClass()] }
    ...
}

當然,別忘了MainVM也需要使用@Inject來宣告注入

class MainVM @Inject constructor() : BaseVM() { ... }

以上是DaggerViewModel使用的注入方式。

雖然自定義的ViewModelFactory是公用的,但是對於不同的ViewModel還是要手動定義不同的bindViewModel方法。

而對於Hilt卻可以省略這一步,甚至說上面的全部都不需要手動編寫。我們需要做的是隻需在ViewModel的建構函式上新增@ViewModelInject

例如上面的MainVM,使用Hilt的效果如下

class MainVM @ViewModelInject constructor() : BaseVM() { ... }

至於Hilt為什麼會這麼簡單呢?我們不要忘了它的本質,它是在Dagger之上建立的,本質是為了幫助我們減少不必要的樣板模板,方便開發者更好的使用依賴注入。

Hilt中,上面的實現會自動幫我們生成,所以才會使用起來這麼簡單。

如果你去對比看AwesomeGithub上的feat_daggerfeat_hilt兩個分支中的程式碼,就會發現使用Hilt明顯少了許多程式碼。對於簡單的Android類來說就是增加幾個註釋而已。

目前唯一一個比較不理想的是對於@Providers的使用,構造方法中不能有引數,如果在用Dagger使用時已經有引數了,再轉變成Hilt可能不會那麼容易。

慶幸的是,DaggerHilt可以共存。所以你可以選擇性的使用。

但是整體而言Hilt真香,你只要嘗試了絕不會後悔~

AwesomeGithub

AwesomeGithub是基於Github的客戶端,純練習專案,支援元件化開發,支援賬戶密碼與認證登陸。使用Kotlin語言進行開發,專案架構是基於JetPack&DataBinding的MVVM;專案中使用了Arouter、Retrofit、Coroutine、Glide、Dagger與Hilt等流行開源技術。

awesome_github.png

除了Android原生版本,還有基於Flutter的跨平臺版本flutter_github

如果你喜歡我的文章模式,或者對我接下來的文章感興趣,你可以關注我的微信公眾號:【Android補給站】

或者掃描下方二維碼,與我建立有效的溝通,同時能夠更方便的收到相關的技術推送。

Android補給站.jpg

相關文章