Hilt 相比 Dagger2 在 Android 中的优势是什么？
解读
国内面试中，90% 的初中级岗位把“会不会用 Hilt”当成“会不会依赖注入”的硬指标；高级岗位则进一步追问“为什么不用 Koin”“Hilt 编译期到底省了什么”。回答时既要让面试官听到“少写代码、编译安全”，也要体现“对 Dagger2 痛点有体感，对 Android 官方路线有跟进”。一句话：用“痛点对比 + 实现原理 + 实战收益”三件套，证明你既踩过坑也上过岸。
知识点
-
Dagger2 在 Android 的三大槽点：
- 模板多：Module、Component、Builder、Factory 手写量大，层级深。
- 生命周期绑定难：Activity/Fragment/Service 需要手动桥接 AndroidX 生命周期，内存泄漏风险高。
- 作用域混乱：自定义 Scope 与 Android 组件生命周期对不齐，新人极易错用 @Singleton。
-
Hilt 的顶层设计：
- 官方预置 @AndroidEntryPoint、@HiltViewModel、@InstallIn 等注解，把“Android 组件”映射到“Dagger Component 树”，自动生成入口点。
- 内置 7 个生命周期作用域（@Singleton、@ActivityRetainedScoped、@ViewModelScoped、@ActivityScoped、@FragmentScoped、@ViewScoped、@ServiceScoped），与 AAC 生命周期一一对应，编译期即检查越界。
- 通过 Gradle Plugin 在 Transform 阶段生成 EntryPoint、Modules、Components，全部走 Dagger2 的 APT，不损失性能，却省去手写。
-
国内项目迁移收益：
- 模块数 > 20 的巨型 App，Hilt 可减少 30% ～ 40% 的 DI 模板代码，合并代码评审意见量下降 50%。
- 与 Jetpack MVVM 深度整合：@HiltViewModel 直接支持 SavedStateHandle，无需额外 Factory。
- 对国内多渠道包友好：Hilt 的符号仅留在 compileOnly，最终 R8 裁剪后体积增量 < 50 KB，远小于 Koin 的 200 KB+。
-
面试加分细节：
- 提到 @EntryPoint 用于非 Hilt 依赖的桥接，说明你对存量代码迁移有方案。
- 指出 Hilt 仍用 Dagger2 的 SPI，因此 graph 错误在编译期暴露，与 Koin 的运行时反射失败形成对比。
- 补充 Hilt 与 TDD 结合：@UninstallModules 支持单元测试替换实现，国内大厂灰度模块常用。
答案
Hilt 并不是“另一个 DI 框架”，而是 Google 在 Dagger2 之上为 Android 做的官方脚手架，核心优势可归纳为三点：
- 零模板：通过 @AndroidEntryPoint 等注解，把 Activity、Fragment、ViewModel 直接声明为注入入口，编译期自动生成 Dagger Component 树，省去手写 Module、Component、Builder 的 70% 代码。
- 生命周期安全：预置与 AAC 对齐的 7 级作用域，编译期即可拦截 @Singleton 误用到 Fragment 的代码，线上内存泄漏率下降一个数量级。
- 可测试性：@UninstallModules、@BindValue 让单元测试与 UI 测试无需再建 Dagger TestComponent，国内实际项目接入后，DI 相关单测编写时间缩短一半。
一句话总结：Hilt 用“官方脚手架”把 Dagger2 的灵活性保留，把 Android 特有的样板与生命周期坑全部填平，让国内团队在“编译安全”与“开发效率”之间不再二选一。
拓展思考
- 如果现有项目已用 Dagger2 + AndroidInjector，评估迁移成本时，可先用 @EntryPoint 把存量 Component 桥接到 Hilt，逐步替换；面试时可展示迁移脚本与 CI 增量编译数据。
- 对于需要动态下发模块的国内插件化方案（如 RePlugin、Shadow），Hilt 的静态编译特性会与运行时加载冲突，可提前准备“接口下沉 + @EntryPoint 手动获取”的兼容策略，体现你对极端场景的预判。
- 未来 KSP 全面替代 APT 后，Hilt 的编译速度仍有提升空间，可关注 Google 在 AOSP 的 hilt-compiler-ksp 分支，面试尾声抛出此话题，可让面试官感知你对技术演进的持续跟踪。