1. 项目概述：为什么我们需要Hilt？

如果你是一名Android开发者，最近几年肯定没少听“依赖注入”这个词。从早期的Dagger 2，到后来Koin、Kodein等Kotlin-first的框架，再到如今Jetpack组件库力推的Hilt，依赖注入似乎成了现代Android架构的标配。但说实话，我第一次接触Dagger 2时，感觉就像在看天书，那一堆@Component、@Module、@Subcomponent注解，加上编译时生成的代码，调试起来简直让人头大。很多团队引入Dagger后，代码复杂度不降反升，新人上手成本极高。

这正是Hilt诞生的背景。你可以把它理解为Google官方为Dagger 2套上的一层“人性化外壳”。它基于久经考验的Dagger 2，但通过提供一套标准化的组件和生命周期管理，以及大量预定义的绑定和限定符，极大地简化了在Android应用中使用依赖注入的流程。Hilt的核心目标就一个：让依赖注入变得简单、可维护，并且与Android的生命周期无缝集成，从而让开发者能把精力集中在业务逻辑上，而不是繁琐的依赖配置上。

那么，Hilt具体解决了哪些痛点呢？首先，它消除了手动编写大量样板代码的需要，比如创建和维护Dagger Component。其次，它提供了对Android特定类（如Application、Activity、Fragment、View、Service、BroadcastReceiver）的开箱即用支持，这些类的依赖注入在纯Dagger中需要开发者自己处理复杂的生命周期绑定。最后，Hilt与Jetpack库（如ViewModel、WorkManager）深度集成，使得在这些架构组件中使用依赖注入变得异常简单。

无论你是正在为老项目引入依赖注入而头疼，还是在新项目中想采用更现代的架构，Hilt都是一个值得投入时间学习的工具。它降低了依赖注入的门槛，使得即使是中小型项目，也能享受到依赖注入带来的模块化、可测试性和代码清晰度的好处。接下来，我们就从零开始，拆解Hilt的核心概念、上手步骤以及那些官方文档可能不会明说的实战技巧。

2. Hilt核心概念与设计思路拆解

在动手写代码之前，我们必须先理解Hilt的几个核心设计思想。这能帮助我们在遇到问题时，知道该去哪里找答案，而不是盲目地复制粘贴配置。

2.1 基于Dagger 2的“标准化”封装

Hilt不是一个新的依赖注入框架，它的底层引擎依然是Dagger 2。这意味着所有Dagger的核心概念，如@Inject、@Module、@Provides、@Component在Hilt中依然有效，并且最终会由Dagger的注解处理器生成代码。Hilt的创新在于，它预先为我们定义好了一套标准的、针对Android的Dagger组件层次结构。

在纯Dagger项目中，我们需要自己定义ApplicationComponent、ActivityComponent等，并手动管理它们的生命周期和依赖关系图。而在Hilt中，这些标准组件已经内置好了，我们只需要通过特定的注解（如@HiltAndroidApp、@AndroidEntryPoint）来启用它们即可。这相当于Google提供了一套“最佳实践”的Dagger配置模板，我们在这个模板的基础上进行填充和扩展。

2.2 层次化的组件生命周期

这是Hilt设计的精髓。它定义了一个清晰的组件层次结构，子组件可以访问父组件中提供的依赖项，但父组件不能访问子组件的。这个层次结构与Android的生命周期天然对应：

1. SingletonComponent (Application级): 绑定到Application生命周期。这是最顶层的组件，通常用于提供全局单例，如Retrofit实例、Room Database、SharedPreferences等。用@Singleton注解标记。
2. ActivityRetainedComponent (ViewModel级): 绑定到Activity的onDestroy到onCreate之间（即配置更改时存活）。这是为ViewModel设计的。
3. ActivityComponent: 绑定到Activity生命周期。用于提供Activity级别的依赖。
4. FragmentComponent: 绑定到Fragment生命周期。用于提供Fragment级别的依赖。
5. ViewComponent: 绑定到View生命周期。
6. ViewWithFragmentComponent: 绑定到View生命周期，但可以访问Fragment的依赖。
7. ServiceComponent: 绑定到Service生命周期。

这个层次结构决定了依赖的作用域和存活时间。一个在SingletonComponent中提供的Repository，可以被所有下级组件（Activity、Fragment、View）注入。而一个在ActivityComponent中提供的、依赖于特定Activity实例的类，则无法在Application中被注入。

2.3 入口点（Entry Point）的概念

“入口点”是Hilt中一个关键概念。简单说，它就是Hilt管理的一个Android框架类（如Application、Activity、Fragment）与Dagger依赖图之间的桥梁。我们需要在这些类的声明处添加@AndroidEntryPoint注解，Hilt才会为它们生成相应的组件，并允许在其中进行字段注入。

例如，一个普通的Activity类，Hilt不会处理它。但当你给它加上@AndroidEntryPoint注解后，Hilt就会：

1. 为该Activity生成一个对应的ActivityComponent。
2. 在Activity的onCreate方法执行前，自动进行成员变量的依赖注入。

这大大简化了操作，我们不再需要手动在onCreate里调用诸如DaggerApplicationComponent.create().inject(this)这样的代码。

3. 环境配置与基础集成实操

理论讲得再多，不如动手搭一遍。我们从一个全新的Android项目开始，一步步集成Hilt。

3.1 项目级与模块级Gradle配置

首先，确保项目使用的是较新版本的Android Gradle Plugin（AGP）和Kotlin。在项目的根目录build.gradle.kts（或build.gradle）中，添加Hilt的插件依赖：

// 根目录 build.gradle.kts plugins { // ... 其他插件 id("com.google.dagger.hilt.android") version "2.48" apply false }

这里apply false意味着插件不会被立即应用到所有模块，我们可以在需要的模块中单独启用它。版本号2.48请替换为当前最新的稳定版，你可以从 官方GitHub仓库 查看。

接下来，在App模块的build.gradle.kts文件中，我们需要应用插件并添加依赖。

// app/build.gradle.kts plugins { id("com.android.application") id("org.jetbrains.kotlin.android") // 应用Hilt插件 id("com.google.dagger.hilt.android") } android { // ... 你的Android配置 // 必须启用Java 8或更高版本 compileOptions { sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } kotlinOptions { jvmTarget = "1.8" } } dependencies { // Hilt核心库 implementation("com.google.dagger:hilt-android:2.48") // Hilt编译器，用于处理注解 kapt("com.google.dagger:hilt-android-compiler:2.48") // 如果你使用了Hilt对Jetpack集成的扩展（如ViewModel），还需要添加： implementation("androidx.hilt:hilt-navigation-compose:1.0.0") // 用于Compose // 或者对于Fragment/Activity implementation("androidx.hilt:hilt-navigation-fragment:1.0.0") // Hilt对WorkManager的支持 implementation("androidx.hilt:hilt-work:1.0.0") kapt("androidx.hilt:hilt-compiler:1.0.0") }

注意：kapt（Kotlin注解处理工具）的配置至关重要。如果忘记添加，Hilt注解处理器将不会运行，导致编译时找不到生成的Dagger组件类，报Hilt_AppApplication或DaggerApplicationComponent等类找不到的错误。这是新手最常见的坑之一。

3.2 初始化Hilt Application

Hilt需要一个自定义的Application类作为依赖注入的起点。这个类必须用@HiltAndroidApp注解标记。

1. 创建一个继承自Application的类（例如MyApplication）。

// MyApplication.kt import android.app.Application import dagger.hilt.android.HiltAndroidApp @HiltAndroidApp class MyApplication : Application() { // 你可以在这里进行一些全局初始化，但注意， // 此时Hilt的组件还未完全就绪，不要尝试注入依赖。 override fun onCreate() { super.onCreate() // 例如初始化Timber日志库 // Timber.plant(Timber.DebugTree()) } }

@HiltAndroidApp注解会触发Hilt代码的生成，包括顶层的SingletonComponent。这个生成的组件会附加到你的Application生命周期。

2. 在AndroidManifest.xml中声明这个自定义的Application类。

<manifest ...> <application android:name=".MyApplication" ... > ... </application> </manifest>

完成这一步后，同步项目并尝试编译。如果配置正确，项目应该能成功构建。你可以在app/build/generated/source/kapt/目录下找到Hilt生成的大量代码，这证明注解处理器正在工作。

3.3 第一个依赖注入：在Activity中注入一个简单对象

现在我们来创建一个简单的依赖，并把它注入到MainActivity中。

1. 创建被依赖的类：假设我们有一个AnalyticsService，用于处理应用内的数据统计。

// AnalyticsService.kt // 这是一个普通的类，我们想在别处使用它。 class AnalyticsService { fun logEvent(eventName: String) { println("Event logged: $eventName") // 实际项目中这里可能是发送到Firebase Analytics或自建服务器 } }

2. 告知Hilt如何提供这个依赖：Hilt需要知道当某个地方请求AnalyticsService时，应该提供哪个实例。我们需要创建一个“模块”（Module）。模块是一个用@Module注解的类，它内部的方法用@Provides注解来告诉Hilt如何提供特定类型的实例。

由于AnalyticsService我们希望在全局范围内只有一个实例（单例），我们创建一个位于SingletonComponent作用域内的模块。

// AppModule.kt import dagger.Module import dagger.Provides import dagger.hilt.InstallIn import dagger.hilt.components.SingletonComponent import javax.inject.Singleton @Module // @InstallIn 告诉Hilt这个模块属于哪个组件（生命周期）。 // SingletonComponent 表示这个模块安装在整个应用生命周期内。 @InstallIn(SingletonComponent::class) object AppModule { // @Provides 注解的方法，其返回值类型就是Hilt可以提供的依赖类型。 // @Singleton 注解确保在整个应用生命周期内，只创建一次AnalyticsService实例。 @Singleton @Provides fun provideAnalyticsService(): AnalyticsService { return AnalyticsService() } }

3. 在Activity中请求注入：
   • 首先，使用@AndroidEntryPoint标记MainActivity，使其成为Hilt的入口点。
   • 然后，使用@Inject注解来标记需要注入的字段。

// MainActivity.kt import android.os.Bundle import androidx.appcompat.app.AppCompatActivity import dagger.hilt.android.AndroidEntryPoint import javax.inject.Inject // 关键注解：标记这个Activity为Hilt入口点 @AndroidEntryPoint class MainActivity : AppCompatActivity() { // @Inject 告诉Hilt：“请为我提供一个AnalyticsService的实例” // 字段不能是private，因为Hilt需要直接访问它进行注入。 @Inject lateinit var analyticsService: AnalyticsService override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // 此时，analyticsService已经被Hilt自动注入并初始化好了。 analyticsService.logEvent("MainActivity Created") } }

运行应用，你应该能在Logcat中看到输出：Event logged: MainActivity Created。恭喜，你完成了第一次Hilt依赖注入！

实操心得：@AndroidEntryPoint只能用于Android框架类，如Application、Activity、Fragment、View、Service、BroadcastReceiver。你不能把它用在普通的Kotlin/Java类上。对于普通类，依赖应该通过构造函数注入（后面会讲）。

4. 依赖注入的多种方式与作用域管理

仅仅注入一个单例是不够的。实际项目中，依赖关系更复杂，对象的生命周期也各不相同。Hilt提供了多种注入方式和作用域管理。

4.1 构造函数注入：最推荐的方式

对于你自己编写的类，优先使用构造函数注入。这是最直接、最可测试的方式。你只需要在类的构造函数参数前添加@Inject注解，Hilt就会在需要这个类实例时，自动调用这个构造函数。

// UserRepository.kt import javax.inject.Inject // 假设这个Repository依赖于一个网络服务和一个本地数据库 class UserRepository @Inject constructor( private val apiService: ApiService, private val userDao: UserDao ) { fun getUser(id: String): User { // 业务逻辑 } }

现在，当其他类（比如一个ViewModel）声明需要UserRepository时，Hilt会自动发现它的构造函数，并递归地为其提供ApiService和UserDao的实例。前提是ApiService和UserDao的提供方式也已经被Hilt知晓（通过@Inject构造函数或@Provides方法）。

4.2 字段注入：用于Android框架类

正如我们在Activity中做的，对于无法通过构造函数注入的类（如Activity、Fragment、View等Android系统创建的类），我们使用字段注入。在类中声明@Inject lateinit var字段，并在类上添加@AndroidEntryPoint。

4.3 方法注入：较少使用

你还可以在方法上使用@Inject，Hilt会在依赖注入完成后立即调用该方法。这通常用于执行一些需要依赖已就绪的初始化逻辑。

@AndroidEntryPoint class MainActivity : AppCompatActivity() { @Inject lateinit var someDependency: SomeDependency @Inject fun setupAfterInjection() { // 这个方法会在字段注入完成后被Hilt自动调用 // 此时 someDependency 已经可用 } }

4.4 作用域注解：控制实例生命周期

作用域注解决定了依赖实例的生命周期和重用次数。它与Hilt的组件层次结构紧密绑定。

• @Singleton: 在SingletonComponent中提供，整个应用生命周期内只有一个实例。
• @ActivityRetainedScoped: 在ActivityRetainedComponent中提供，在Activity因配置更改（如旋转屏幕）重建时存活。
• @ActivityScoped: 在ActivityComponent中提供，与Activity生命周期绑定。
• @FragmentScoped: 在FragmentComponent中提供，与Fragment生命周期绑定。
• @ViewScoped: 在ViewComponent中提供。
• @ViewModelScoped: 与特定的ViewModel实例绑定。

如何使用：作用域注解必须用在@Provides方法上，或者与@Inject一起用在可注入类的类声明上。

// 示例1：在Module中提供作用域依赖 @Module @InstallIn(ActivityComponent::class) object MainActivityModule { // 这个DataManager实例会在同一个Activity的生命周期内复用 @ActivityScoped @Provides fun provideDataManager(): DataManager { return DataManager() } } // 示例2：在可注入类上使用作用域 // 假设我们有一个类，希望它在Activity级别是单例 @ActivityScoped class ActivityScopedHelper @Inject constructor() { // ... }

一个重要规则：依赖的作用域不能大于其宿主组件的作用域。例如，一个@ActivityScoped的依赖不能注入到@Singleton的依赖中，因为Activity可能比Application先销毁。但反过来，@Singleton的依赖可以注入到@ActivityScoped的类中。

4.5 限定符（Qualifier）：区分同一类型的不同实例

有时候，你需要同一个接口或类的不同实现。例如，你可能有两个OkHttpClient，一个用于访问主API，一个用于访问图片服务器。这时就需要@Qualifier。

1. 定义限定符注解：

// Qualifiers.kt import javax.inject.Qualifier @Qualifier @Retention(AnnotationRetention.BINARY) annotation class MainApiClient @Qualifier @Retention(AnnotationRetention.BINARY) annotation class ImageApiClient

2. 在Module中使用限定符：

@Module @InstallIn(SingletonComponent::class) object NetworkModule { @Singleton @MainApiClient // 标记这个提供方法是为主API服务的 @Provides fun provideMainOkHttpClient(): OkHttpClient { return OkHttpClient.Builder() .addInterceptor(LoggingInterceptor()) .build() } @Singleton @ImageApiClient // 标记这个提供方法是为图片API服务的 @Provides fun provideImageOkHttpClient(): OkHttpClient { return OkHttpClient.Builder() .connectTimeout(30, TimeUnit.SECONDS) // 更长的超时 .build() } @Singleton @MainApiClient @Provides fun provideMainRetrofit(@MainApiClient client: OkHttpClient): Retrofit { return Retrofit.Builder() .baseUrl("https://api.main.com/") .client(client) .build() } }

3. 在注入时指定限定符：

class MainRepository @Inject constructor( @MainApiClient private val retrofit: Retrofit, // 注入主API的Retrofit @ImageApiClient private val okHttpClient: OkHttpClient // 注入图片API的OkHttpClient ) { // ... }

5. 与Jetpack架构组件深度集成

Hilt与Android Jetpack组件的集成是其一大亮点，尤其是与ViewModel和WorkManager的配合，几乎做到了无缝衔接。

5.1 使用Hilt注入ViewModel

在MVVM架构中，ViewModel是业务逻辑的核心。使用Hilt注入ViewModel的依赖非常优雅。

1. 添加依赖：确保你已经添加了Hilt对ViewModel的扩展库（对于非Compose项目）。

// 在app/build.gradle.kts中 dependencies { // Hilt for ViewModel implementation("androidx.hilt:hilt-lifecycle-viewmodel:1.0.0-alpha03") // 上面这个已经被整合到 androidx.hilt:hilt-navigation-fragment 或 compose中 // 如果你使用 navigation-fragment，通常用下面这个就够了 implementation("androidx.hilt:hilt-navigation-fragment:1.0.0") kapt("androidx.hilt:hilt-compiler:1.0.0") }

2. 在ViewModel中使用构造函数注入：

// MainViewModel.kt import androidx.lifecycle.ViewModel import dagger.hilt.android.lifecycle.HiltViewModel import javax.inject.Inject // 关键注解：标记这个ViewModel由Hilt管理 @HiltViewModel class MainViewModel @Inject constructor( private val userRepository: UserRepository, // 依赖通过构造函数注入 private val analyticsService: AnalyticsService ) : ViewModel() { fun loadUser() { // 使用userRepository analyticsService.logEvent("LoadUserCalled") } }

注意，ViewModel的构造函数注入不需要@AndroidEntryPoint，只需要@HiltViewModel注解。

3. 在Activity或Fragment中获取ViewModel：获取方式与使用普通ViewModelProvider完全一样，Hilt在背后处理了工厂模式的创建。

@AndroidEntryPoint // Activity必须是入口点 class MainActivity : AppCompatActivity() { // 使用 by viewModels() 委托属性（需要添加 lifecycle-viewmodel-ktx 依赖） private val viewModel: MainViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // viewModel 已经被Hilt正确实例化，其依赖也已注入 viewModel.loadUser() } }

踩坑记录：曾经遇到一个错误：java.lang.RuntimeException: Cannot create an instance of class MainViewModel。排查后发现，是因为UserRepository的某个深层依赖（一个第三方库的类）没有提供Hilt可识别的注入方式（既无@Inject构造，也未在Module中@Provides）。Hilt无法构造ViewModel，导致崩溃。解决方法是为那个第三方类创建一个@Module提供其实例，或者使用@Binds绑定到接口。

5.2 为WorkManager提供依赖

后台任务Worker也可以使用Hilt注入依赖。

1. 添加依赖：

implementation("androidx.hilt:hilt-work:1.0.0") kapt("androidx.hilt:hilt-compiler:1.0.0")

2. 创建由Hilt管理的Worker：

// UploadWorker.kt import android.content.Context import androidx.hilt.work.HiltWorker import androidx.work.CoroutineWorker import androidx.work.WorkerParameters import dagger.assisted.Assisted import dagger.assisted.AssistedInject // 关键注解 @HiltWorker class UploadWorker @AssistedInject constructor( @Assisted private val appContext: Context, // Worker必须的Context和Params需要用@Assisted标记 @Assisted private val params: WorkerParameters, private val uploadRepository: UploadRepository // 你的业务依赖 ) : CoroutineWorker(appContext, params) { override suspend fun doWork(): Result { // 使用注入的uploadRepository执行上传任务 return try { uploadRepository.uploadData() Result.success() } catch (e: Exception) { Result.failure() } } }

注意这里使用了Dagger的@AssistedInject来处理Worker必须由系统传递的参数（Context和WorkerParameters）。HiltWorker注解会帮你生成必要的工厂代码。

3. 使用Hilt配置WorkManager：在自定义的Application类中配置。

@HiltAndroidApp class MyApplication : Application(), Configuration.Provider { @Inject lateinit var workerFactory: HiltWorkerFactory override fun getWorkManagerConfiguration(): Configuration { return Configuration.Builder() .setWorkerFactory(workerFactory) // 设置Hilt提供的WorkerFactory .build() } }

4. 安排工作：之后你就可以像平常一样使用WorkManager来安排UploadWorker了，Hilt会自动处理依赖注入。

5.3 在Compose中使用Hilt

如果你使用Jetpack Compose，集成同样顺畅。

1. 添加导航组合的Hilt支持：

implementation("androidx.hilt:hilt-navigation-compose:1.0.0")

2. 在Composable中获取ViewModel：

import androidx.hilt.navigation.compose.hiltViewModel @Composable fun MainScreen( viewModel: MainViewModel = hiltViewModel() // 使用hiltViewModel()获取 ) { // 使用viewModel }

hiltViewModel()函数会从当前的导航后台栈中获取正确作用域的ViewModel实例。

6. 高级技巧与实战避坑指南

掌握了基础用法后，一些高级技巧和常见陷阱能让你用得更顺手。

6.1 动态依赖与组件依赖

有时依赖需要在运行时才能确定。例如，一个Service的BaseUrl可能根据用户选择的环境（测试/生产）而变化。Hilt提供了@BindsInstance和组件构建器模式，但在Hilt的简化模型中，我们通常通过自定义Qualifier或提供带参数的@Provides方法结合其他机制（如SavedStateHandle）来实现。

一种常见模式是使用SavedStateHandle在ViewModel中获取动态参数，再传递给其他依赖。

@HiltViewModel class DetailViewModel @Inject constructor( savedStateHandle: SavedStateHandle, private val repo: DetailRepository ) : ViewModel() { private val itemId: String = savedStateHandle["itemId"] ?: throw IllegalStateException("No itemId provided!") init { loadDetail(itemId) } }

6.2 多模块项目中的Hilt配置

在大型多模块项目中，Hilt的配置需要一些规划。

• App模块：包含@HiltAndroidApp的Application类，以及安装于SingletonComponent的全局模块（如NetworkModule、DatabaseModule）。
• 功能模块：每个功能模块可以包含自己的Hilt模块，使用@InstallIn指定其作用的组件（如ActivityComponent、FragmentComponent）。这些模块需要被App模块依赖，Hilt才能收集到它们。
• 注意：Hilt的注解处理器（kapt或ksp）需要在每个使用Hilt的模块中单独配置。同时，确保所有模块使用相同版本的Hilt库。

6.3 测试中的Hilt

Hilt为测试提供了强大的支持。你可以为测试环境创建不同的模块，来替换生产环境的依赖（例如，用MockWebServer替换真实的网络接口）。

1. 为测试创建自定义TestApplication：

// src/androidTest/java/.../TestMyApplication.kt @HiltAndroidTest class TestMyApplication : Application()

2. 创建测试模块：

// src/androidTest/java/.../TestAppModule.kt @Module @InstallIn(SingletonComponent::class) object TestAppModule { @Provides @Singleton fun provideAnalyticsService(): AnalyticsService { return FakeAnalyticsService() // 返回一个模拟实现 } }

3. 在测试类中使用：

@HiltAndroidTest class MainActivityTest { @get:Rule var hiltRule = HiltAndroidRule(this) @Inject lateinit var fakeAnalytics: AnalyticsService // 会注入TestAppModule提供的Fake实例 @Before fun init() { hiltRule.inject() // 手动触发注入 } @Test fun testSomething() { // 使用fakeAnalytics进行测试验证 } }

6.4 常见编译错误与排查

• error: [Hilt] Missing required property: android： 检查是否在App模块的build.gradle中正确应用了id("com.google.dagger.hilt.android")插件。
• error: [Dagger/MissingBinding] SomeType cannot be provided without an @Provides-annotated method.： 这是最常见的错误，表示Hilt不知道如何提供SomeType的实例。检查：
  1. 该类型是否有@Inject注解的构造函数。
  2. 是否在某个已安装的@Module中，有@Provides方法返回该类型。
  3. 该@Module是否通过@InstallIn安装到了正确的组件中，并且该组件能被需要注入的地方访问到（作用域规则）。
  4. 如果是接口，是否有@Binds方法将其绑定到具体实现。
• java.lang.IllegalStateException: Hilt Activity must be attached to an @HiltAndroidApp Application.： 检查你的Application类是否确实添加了@HiltAndroidApp，并且在AndroidManifest.xml中正确声明。
• kotlin.UninitializedPropertyAccessException: lateinit property xxx has not been initialized： 通常发生在字段注入的类中，在注入完成前就访问了该字段。确保你是在onCreate（对于Activity）或onViewCreated（对于Fragment）之后才访问这些字段。对于Fragment，特别注意不要在onAttach或onCreate中访问注入字段，因为此时注入可能尚未发生。

6.5 性能与调试建议

• 编译时间：Hilt（底层是Dagger）会增加项目的编译时间，尤其是在clean build时。为了缓解：
  • 考虑使用Dagger的 增量注解处理 （通过Gradle配置）。
  • 使用KSP（Kotlin Symbol Processing）替代KAPT，通常能获得更快的编译速度（Hilt已支持KSP）。
• 调试生成的代码：遇到奇怪的依赖解析问题时，可以查看Hilt/Dagger生成的代码。路径在app/build/generated/source/kapt/或ksp/下。查看*Module_ProvideXFactory或*Impl类，可以帮助理解依赖是如何被提供的。
• 使用Dagger的Component Tree：在复杂的依赖图中，可以使用Dagger的 组件层次结构调试功能 。虽然Hilt隐藏了组件定义，但理解底层组件的层次对于调试作用域相关问题很有帮助。

Hilt通过其“约定大于配置”的理念，极大地改善了Android开发中依赖注入的体验。它可能无法解决所有复杂场景，但对于90%的日常需求，它提供了清晰、简洁且强大的解决方案。从配置繁琐的Dagger 2迁移到Hilt，初期可能会觉得有些“魔法”，但一旦熟悉了其组件层次和作用域规则，你会发现它让构建可测试、可维护的Android应用变得更加容易。开始尝试在下一个项目，或者当前项目的某个新功能中引入Hilt吧，亲自体会它带来的整洁与高效。