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

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

Hilt 使用注解處理器生成代碼。對注解的處理發(fā)生在編譯器將源文件轉(zhuǎn)換為 Java 字節(jié)碼期間。顧名思義，注解處理器作用于源文件中的注解。注解處理器通常會檢查注解，并根據(jù)注解類型來執(zhí)行不同的任務，例如代碼檢查或生成新文件。 在 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 插件為您提供的語法糖。接下來我們將探討更多關于 Gradle 插件的內(nèi)容，在此之前，我們先來看看這個例子在沒有語法糖的情況下應該是什么樣子的。

@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 應用中使用過 Dagger (不通過 Hilt)，您可能會熟悉這些直接在組件上編寫的注入方法。

@InstallIn

InstallIn 用于表明模塊或者入口點應該被裝載到哪個組件中。在如下示例中，我們將 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，應用中任何傳遞依賴項內(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 注解處理器可以輕松地在您應用中所有的傳遞依賴項中找到生成的元數(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 注解的模塊被放置在相應組件聲明的模塊列表中。添加了 @InstallIn 注解的入口點被放置在聲明相應組件的父類型的位置。

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

這是一篇關于 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í)行很多有用的任務，包括字節(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 注解的模塊。

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

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

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

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

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

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

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

總結(jié)

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