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

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

• @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

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

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

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

@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)
}

@InstallIn

@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

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

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ù)據包中查找所有被添加 @InstallIn 注解的類。添加了 @InstallIn 注解的模塊被放置在相應組件聲明的模塊列表中。添加了 @InstallIn 注解的入口點被放置在聲明相應組件的父類型的位置。

這是一篇關于 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 插件

• 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)  }
}

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

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

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

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

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

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

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

類路徑聚合

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

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

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

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

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

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

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

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

總結