嗶哩嗶哩在Hilt組件化的使用技術(shù)探索

更新時間：2022年06月22日 14:42:42 作者：究極逮蝦戶

這篇文章主要為大家介紹了嗶哩嗶哩在Hilt組件化的使用技術(shù)探索，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

前言

DI(Dependency Injection)，即“依賴注入”：組件之間依賴關(guān)系由容器在運行期決定，形象的說，即由容器動態(tài)的將某個依賴關(guān)系注入到組件之中。依賴注入的目的并非為軟件系統(tǒng)帶來更多功能，而是為了提升組件重用的頻率，并為系統(tǒng)搭建一個靈活、可擴展的平臺。通過依賴注入機制，我們只需要通過簡單的配置，而無需任何代碼就可指定目標需要的資源，完成自身的業(yè)務邏輯，而不需要關(guān)心具體的資源來自何處，由誰實現(xiàn)。

最近業(yè)務同學需要接入谷歌推的Hilt框架。因為嗶哩嗶哩的業(yè)務上很容易出現(xiàn)業(yè)務層面的交叉，而因為項目完成了大量的組件化拆分。由于不希望業(yè)務之間產(chǎn)生相互引用，所有在技術(shù)評估完成之后我們決定由我們部門來對Hilt進行接入。

接入Hilt

摘自官方文檔使用 Hilt 實現(xiàn)依賴項注入

首先先聲明下dagger.hilt.android.plugin相關(guān)的plugin。

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

其次由于hilt一大部分相關(guān)的都是基于kapt的代碼生成邏輯，所以我們要在使用到hilt的模塊的build.gradle中都定義如下相關(guān)的。

...
apply plugin: 'kotlin-kapt'
apply plugin: 'dagger.hilt.android.plugin'

android {
    ...
}

dependencies {
    implementation "com.google.dagger:hilt-android:2.35.1"
    kapt "com.google.dagger:hilt-android-compiler:2.35.1"
}

我們需要給我們的Application增加一個注解。

@HiltAndroidApp
class ExampleApplication : Application() {  }

根據(jù)官方接入文檔哦，我們組只要把Application只要打上@HiltAndroidApp的注解，就可以完成這部分接入能力了。

Hilt在組件化

但是但是官方有個聲明是這樣的。

Hilt 代碼生成操作需要訪問使用 Hilt 的所有 Gradle 模塊。編譯 Application 類的 Gradle 模塊需要在其傳遞依賴項中包含所有 Hilt 模塊和通過構(gòu)造函數(shù)注入的類。

從這部分說明上來看，這個注解最好是能放在com.android.application模塊中, 這樣就能保證依賴到所有的子模塊中去了。

但是實際我們在使用過程中，由于com.android.application模塊還是有一些代碼量的，而由于kapt代碼生成機制，需要先將kotlin代碼轉(zhuǎn)化成java代碼，之后才能生成ast語法樹。

根據(jù)ci上的實驗結(jié)果，在com.android.application模塊下kapt耗時在30s左右，而整體編譯時間大概為3分鐘左右。這種耗時我個人覺得還是屬于不能接受的。

所以我們調(diào)整了下這部分代碼。這次建立了一個殼module，這邊只有HiltApplication的注解相關(guān)。然后將這個module依賴了所有業(yè)務倉庫，按照編譯邏輯來說，基于gradle task的depend邏輯，他會在application模塊編譯之前，所有業(yè)務模塊編譯之后，這樣能保證hilt生成的代碼邏輯正常。

同時由于是一個空工程，我們把空工程定義為bundle-kapt，所以整體來說對于編譯速度影響會變到最小。讓各位大佬看下我們后續(xù)的優(yōu)化結(jié)果。

上述是我最后截圖出來的結(jié)果，我們將一個耗時大概30s的任務優(yōu)化到3s，其實效果上來說已經(jīng)非常明顯，達到我們想要的預期了已經(jīng)。

當然如果后續(xù)hilt支持了ksp之后，這部分速度應該可以更快，畢竟我么可以直接拋棄java語法樹了嗎。

出現(xiàn)了點小問題

這兩天業(yè)務方實際在使用過程中，突然反饋說貌似我們接入的Hilt貌似不行啊，進入到頁面直接崩潰了。

有一說一，一臉懵逼。先看看異常吧。初一開始我以為是kapt沒有生成好或者別的什么原因?qū)е碌摹?/p>

com.xxxxxx.xxxxxx}: java.lang.ClassCastException: xxxxx.DaggerHiltApplication_HiltComponents_SingletonC$ActivityRetainedCImpl$ActivityCImpl cannot be cast to xxxxx_GeneratedInjector

只能一步步調(diào)試咯，我打開項目開啟編譯項目，之后進入蠻長的等待過程中。10分鐘過去了終于好了。

由于Hilt使用了kapt，所以很自然的打開了build/generated/source/kapt文件路徑，之后我看了下DaggerHiltApplication_HiltComponents_SingletonC這個類的生成。

ActivityRetainedCImpl從這里我大概猜測出了一小部分Hilt原理,通過收集不同子Module的抽象接口，然后把這部分能力聚合在HiltApplication中，舉個例子Hilt_BangumiDetailActivityV3這個就是一個子業(yè)務內(nèi)的DI注入的一個類的實現(xiàn)。

突然這個時候我想到了一件事哦，也就是說我們的bundle-kapt模塊，其實它的實際編譯產(chǎn)物會根據(jù)接入業(yè)務的不同而產(chǎn)生實際的變更。也就是說雖然這個模塊的代碼沒有發(fā)生變更，但是由于子業(yè)務增加了注解和代碼變更，導致了這個模塊的kapt還是需要重新執(zhí)行，這樣才能保證輸出的產(chǎn)物是變化的。

然而我們的項目之前由于工程結(jié)構(gòu)太龐大了，可能有30-40個Module,所有我們將一部分沒有變更的代碼產(chǎn)物化，也就是基于commit變成了一個個aar或者jar發(fā)布到了遠端。之后根據(jù)commit來重新定向到產(chǎn)物。

而bundle-kapt這個模塊也很不幸，被當做了一個靜態(tài)模塊，變成了一個遠端的產(chǎn)物，之后即時業(yè)務添加了再多的注入相關(guān)的，因為bundle-kapt沒有參與編譯，所以注入的能力就出錯了。