• 多種 Hilt 注解協(xié)同工作并生成代碼的方式。
• 當 Hilt 配合 Gradle 使用，Hilt Gradle 插件如何在幕后工作以改善整體體驗。

多種 Hilt 注解協(xié)同工作并生成代碼的方式

Hilt 使用注解處理器生成代碼。對注解的處理發(fā)生在編譯器將源文件轉(zhuǎn)換為 Java 字節(jié)碼期間。顧名思義，注解處理器作用于源文件中的注解。注解處理器通常會檢查注解，并根據(jù)注解類型來執(zhí)行不同的任務(wù)，例如代碼檢查或生成新文件。 在 Hilt 中，三個最重要的注解就是:@AndroidEntryPoint、@InstallIn 以及 @HiltAndroidApp。

• @AndroidEntryPoint
  https://dagger.dev/api/latest/dagger/hilt/android/AndroidEntryPoint.html

• @InstallIn
  https://dagger.dev/api/latest/dagger/hilt/InstallIn.html

• @HiltAndroidApp
  https://dagger.dev/api/latest/dagger/hilt/android/HiltAndroidApp.html

@AndroidEntryPoint

AndroidEntryPoint 在您的 Android 類中啟用字段注入，例如 Activity、Fragment、View 以及 Service。

• AndroidEntryPoint
  https://dagger.dev/api/latest/dagger/hilt/android/AndroidEntryPoint.html

如下示例所示，通過向 PlayActivity 添加 AndroidEntryPoint 注解，即可輕松將 MusicPlayer 注入到我們的 Activity 中。

@AndroidEntryPointclass PlayActivity : AppCompatActivity() {
  @Inject lateinit var player: MusicPlayer
  // ...}

如果您使用 Gradle，您可能熟悉上文所述的簡化語法。但這并不是真實的語法，而是 Hilt Gradle 插件為您提供的語法糖。接下來我們將探討更多關(guān)于 Gradle 插件的內(nèi)容，在此之前，我們先來看看這個例子在沒有語法糖的情況下應(yīng)該是什么樣子的。

@AndroidEntryPoint(AppCompatActivity::class)class PlayActivity : Hilt_PlayActivity() {
  @Inject lateinit var player: MusicPlayer
  // ...}

現(xiàn)在，我們看到原始基類 AppCompatActivity 是 AndroidEntryPoint 注解的真實入?yún)ⅰ?/span>PlayActivity 實際上繼承了生成的類 Hilt_PlayActivity，該類由 Hilt 注解處理器生成，并包含所有執(zhí)行注入操作需要的邏輯。針對上述內(nèi)容生成的基類，其代碼簡化示例如下:

@Generated("dagger.hilt.AndroidEntryPointProcessor")class Hilt_PlayActivity : AppCompatActivity {
  override fun onCreate() {    inject()    super.onCreate()  }
  private fun inject() {    EntryPoints.get(this, PlayActivity_Injector::class).inject(this as PlayActivity);  }}

• AppCompatActivity
  https://developer.android.google.cn/reference/androidx/appcompat/app/AppCompatActivity

在示例中，生成的類繼承自 AppCompatActivity。然而，通常情況下生成的類會繼承傳入 AndroidEntryPoint 注解的類。這使得注入操作可以在任何您需要的基類中執(zhí)行。

生成類的主要目的是處理注入操作。為了避免字段在注入之前被意外訪問，有必要盡可能早地執(zhí)行注入操作。因此，對于 Activity，注入操作在 onCreate 中被執(zhí)行。

在 inject 方法中，我們首先需要一個注入器的實例——PlayActivity_Injector。在 Hilt 中，對于 Activity，注入器是一個入口點，我們可以使用 EntryPoints 工具類獲得一個注入器的實例。

您可能想到了，PlayActivity_Injector 也是由 Hilt 注解處理器生成的。格式如下:

@Generated("dagger.hilt.AndroidEntryPointProcessor")@EntryPoint@InstallIn(ActivityComponent::class)interface PlayActivity_Injector {
  fun inject(activity: PlayActivity)
}

生成的注入器是一個被裝載到 ActivityComponent 的 Hilt 入口點。它僅包含一個讓我們注入 PlayActivity 實例的方法。如果您曾在 Android 應(yīng)用中使用過 Dagger (不通過 Hilt)，您可能會熟悉這些直接在組件上編寫的注入方法。

@InstallIn

InstallIn 用于表明模塊或者入口點應(yīng)該被裝載到哪個組件中。在如下示例中，我們將 MusicDataBaseModule 裝載到 SingletonComponent 中:

@Module@InstallIn(SingletonComponent::class)object MusicDatabaseModule {  // ...}

• InstallIn
  https://dagger.dev/api/latest/dagger/hilt/InstallIn.html

• SingletonComponent
  https://dagger.dev/api/latest/dagger/hilt/components/SingletonComponent.html

通過 InstallIn，應(yīng)用中任何傳遞依賴項內(nèi)都可以提供模塊和入口點。然而，部分情況下我們需要收集所有由InstallIn 注解提供的內(nèi)容以獲取每個組件的完整模塊和入口點。 Hilt 在特定的包下生成了元數(shù)據(jù)注解，以便更輕松地收集和發(fā)現(xiàn)這些由 InstallIn 注解所提供的內(nèi)容。生成的注解格式如下:

package hilt_metadata
@Generated("dagger.hilt.InstallInProcessor")@Metadata(my.database.MusicDatabaseModule::class)classMusicDatabaseModule_Metadata{}

通過將元數(shù)據(jù)放進特定的包下，Hilt 注解處理器可以輕松地在您應(yīng)用中所有的傳遞依賴項中找到生成的元數(shù)據(jù)。至此，我們可以使用元數(shù)據(jù)注解中所包含的信息來找到由 InstallIn 注解所提供內(nèi)容的自身引用。在本示例中指的是 MusicDatabaseModule。

HiltAndroidApp

最后，HiltAndroidApp 注解可以讓您的 Android Application 類啟用注入。此處，您可以將其視為與 AndroidEntryPoint 注解完全相同。第一步，開發(fā)者僅需在 Application 類上添加 @HiltAndroidApp 注解。

@HiltAndroidAppclass MusicApp : Application {
  @Inject lateinit var store: MusicStore
}

• HiltAndroidApp
  https://dagger.dev/api/latest/dagger/hilt/android/HiltAndroidApp.html

然而，HiltAndroidApp 還有另外一個重要的作用——生成 Dagger 組件。

當 Hilt 注解處理器遇到 @HiltAndroidApp 注解時，會在包裝類中生成一些列組件，該包裝類與 Application 類同名，前綴為 HiltComponents_。如果您之前使用過 Dagger，這些組件就是添加了 @Component 和 @Subcomponent 注解的類，而在 Dagger 中通常需要您手動編寫。

為了生成這些組件，Hilt 在上述元數(shù)據(jù)包中查找所有被添加 @InstallIn 注解的類。添加了 @InstallIn 注解的模塊被放置在相應(yīng)組件聲明的模塊列表中。添加了 @InstallIn 注解的入口點被放置在聲明相應(yīng)組件的父類型的位置。

從這里開始，Dagger 處理器接管并根據(jù) @Component 和 @Subcomponent 注解生成組件的具體實現(xiàn)。如果您曾使用過 Dagger (不通過 Hilt)，那么大概率您已經(jīng)直接處理了這些類。但是，Hilt 對開發(fā)者隱藏了這種復雜操作。

這是一篇關(guān)于 Hilt 的文章，我們就不詳細介紹 Dagger 生成的代碼了。如果您有興趣，詳情請查閱:

• Ron Shapiro 和 David Baker 的演講:

  https://www.youtube.com/watch?v=wCvXe2LsN5o

• Dagger codegen 101 的備忘單:

  https://medium.com/androiddevelopers/dagger-code-generation-cheat-sheets-6b4fa2da4e7a

Hilt Gradle 插件

現(xiàn)在您已經(jīng)了解了 Hilt 中代碼生成的工作原理，接下來讓我們看看 Hilt Gradle 插件。Hilt Gradle 插件執(zhí)行很多有用的任務(wù)，包括字節(jié)碼改寫和類路徑聚合。

• Hilt Gradle 插件

  https://dagger.dev/hilt/gradle-setup#hilt-gradle-plugin

字節(jié)碼改寫

顧名思義，字節(jié)碼改寫就是改寫字節(jié)碼的過程。與注解處理只能生成新代碼不同，字節(jié)碼改寫可以修改現(xiàn)有代碼。如果謹慎使用，這將是非常強大的功能。

為了說明我們?yōu)楹卧?Hilt 中使用字節(jié)碼改寫，讓我們回到 @AndroidEntryPoint。

@AndroidEntryPoint(AppCompatActivity::class)class PlayActivity : Hilt_PlayActivity {
  override fun onCreate(…) {    val welcome = findViewById(R.id.welcome)  }
}

雖然繼承 Hilt_PlayActivity 基類在實踐中有效，但它可能會導致 IDE 報錯。由于生成的類在您成功編譯代碼后才存在，因此您經(jīng)常會在 IDE 中看到紅色波浪線。此外，您將無法享有諸如方法重載這種自動補全的能力，并且您將無法訪問基類中的方法。 失去這些功能不僅會降低您的編碼速度，而且這些紅色波浪線也會極大程度地分散您的注意力。 Hilt Android 插件通過在您的類上添加 AndroidEntryPoint 注解來啟動字節(jié)碼改寫。啟用 Hilt Android 插件后，您只需要在類上添加 @AndroidEntryPoint 注解，同時您可以使其繼承普通的基類。

@AndroidEntryPointclass PlayActivity : AppCompatActivity { // <-- 無需引用生成的基類
  override fun onCreate(…) {    val welcome = findViewById(R.id.welcome)  }}

由于此語法無需引用生成的基類，所以不會引起 IDE 報錯。在字節(jié)碼改寫期間，Hilt Gradle 插件會將您的基類替換為 Hilt_PlayActivity。由于此過程直接操作字節(jié)碼，對開發(fā)者是不可見的。

然而，字節(jié)碼改寫仍有一些缺點:

• 該插件必須修改底層字節(jié)碼，而不是源代碼，這容易出錯。

• 因為在改寫操作時字節(jié)碼已經(jīng)被編譯，所以問題通常出現(xiàn)在運行時而不是編譯時。

• 改寫操作使調(diào)試變得復雜，因為當出現(xiàn)問題時，源文件可能并不代表當前正在執(zhí)行的字節(jié)碼。

由于這些原因，Hilt 嘗試盡可能減少依賴字節(jié)碼改寫。

類路徑聚合

最后，讓我們看看 Hilt Gradle 插件的另一個有用功能: 類路徑聚合。要了解什么是類路徑聚合，以及為什么需要它，讓我們看另一個示例。

在本示例中 :app 依賴一個獨立的 Gradle 模塊 :database，:app 和 :database 都提供了被 InstallIn 注解的模塊。

如您所見，Hilt 會在特定的 hilt_metadata 包下生成元數(shù)據(jù)，在生成組件時，會用它們查找所有被添加 @InstallIn 注解的模塊。

不使用類路徑聚合的處理對于單層依賴關(guān)系仍然可以正常工作，現(xiàn)在讓我們看看當添加另一個 Gradle 模塊 :cache 作為 :database 的依賴項時會發(fā)生什么。

當 :cache 被編譯時，雖然它會生成元數(shù)據(jù)，但在編譯 :app 時該元數(shù)據(jù)無法使用，因為它是一個傳遞依賴項。因此，Hilt 無法知曉 CacheModule，它會意外地從生成的組件中排除。 當然，您可以使用 api 而不是 implementation 聲明 :cache 的依賴關(guān)系，從而在技術(shù)層面解決這個問題，但不推薦這樣做。使用 api 不僅會讓增量構(gòu)建變得更糟糕，還把維護工作也變成一場噩夢。 這就是 Hilt Gradle 插件發(fā)揮作用的地方。

即使使用 implementation，Hilt Gradle 插件也可以自動從 :app 的傳遞依賴項中聚合所有的類。

此外，與直接使用 api 相比，Hilt Gradle 插件還具有許多優(yōu)點。

首先，對比在整個應(yīng)用中手動使用 api 依賴關(guān)系，類路徑聚合更不容易出錯并且不需要維護。您可以像往常一樣簡單地使用 implementation，其余的將由 Hilt Gradle 插件處理。

其次，Hilt Gradle 插件僅在應(yīng)用級別聚合類，因此與使用 api 不同，項目中庫的編譯不受影響。

最后，類路徑聚合為您的依賴項提供了更好的封裝，因為不可能在源文件中意外引用這些類，并且它們不會出現(xiàn)在代碼補全提示中。

總結(jié)

本文我們揭示了各種 Hilt 注解協(xié)同工作以生成代碼的方式。 我們還關(guān)注了 Hilt Gradle 插件，并了解它是如何在幕后使用字節(jié)碼改寫和類路徑聚合，讓 Hilt 的使用變得更安全、更輕松。