Android 架构进化之路：为何在 Retrofit + 协程重构中，我们需要引入 Hilt？-平芜编程栈

它是理性、技术导向且务实的。

文章的策略不是“为了用框架而用框架”，而是从痛点出发（手动写 Factory 的繁琐、SavedStateHandle 的难搞、Compose 的未来），最后通过对比得出结论。

Android 架构进化之路：为何在 Retrofit + 协程重构中，我们需要引入 Hilt？

背景

目前我们的项目正在进行现代化的架构升级：

网络层：从 RxJava 迁移到Kotlin Coroutines+Retrofit。
数据流：使用Flow和密封类 (NetworkResult) 替代回调，实现更安全的单向数据流。
UI层：逐步引入Jetpack Compose，同时兼容现有的 View/XML。

在重构交易模块（Trade Module）时，我发现了一个绕不开的架构痛点：ViewModel 的依赖注入问题。为了解决这个问题，并为未来的 Compose 铺路，我建议在部分新模块中引入Hilt。

本文将通过实际代码对比，解释为什么要这么做，以及它能为团队带来什么实际收益。

痛点：手动管理的“依赖地狱”

在新的架构中，我们遵循 MVVM 原则。一个标准的TradeViewModel通常需要两个依赖：

TradeApiService：用于网络请求（我们需要注入它）。
SavedStateHandle：用于在进程被杀后恢复数据（系统提供，用于获取 Intent 参数）。

❌ 如果不使用 Hilt（现状）

由于SavedStateHandle是系统创建的，而ApiService是我们要传入的，手动把这两个东西组合进 ViewModel 的构造函数非常痛苦。我们必须不得不为每一个 ViewModel 手动写一个Factory类：

1. 繁琐的 ViewModelFactory

// 每一个 ViewModel 都要写这样一个 Factory，全是样板代码classTradeViewModelFactory(privatevalapiService:TradeApiService,owner:SavedStateRegistryOwner,defaultArgs:Bundle?=null):AbstractSavedStateViewModelFactory(owner,defaultArgs){overridefun<T:ViewModel>create(key:String,modelClass:Class<T>,handle:SavedStateHandle):T{// 我们必须手动组装：系统给的 handle + 我们给的 apiServiceif(modelClass.isAssignableFrom(TradeViewModel::class.java)){@Suppress("UNCHECKED_CAST")returnTradeViewModel(handle,apiService)asT}throwIllegalArgumentException("Unknown ViewModel class")}}

2. 在 Activity 中尴尬的调用

// 我们必须手动获取 Retrofit 实例，手动创建 Repository，再手动 new Factoryvalapi=RetrofitClient.getInstance().create(TradeApiService::class.java)valfactory=TradeViewModelFactory(api,this,intent.extras)// 终于拿到了 ViewModelvalviewModel=ViewModelProvider(this,factory)[TradeViewModel::class.java]

问题总结：

代码冗余：每增加一个页面，就得写一个 Factory，维护成本高。
容易出错：如果 ViewModel 加了一个参数（比如UserHelper），需要修改 Factory 和所有调用这个 Factory 的 Activity。
生命周期风险：如果RetrofitClient不是单例，或者我们需要传递一个Activity级别的对象，手动管理生命周期很容易导致内存泄漏。

解决方案：引入 Hilt 后的世界

Hilt 是 Google 官方推荐的依赖注入库，它是专门为 Android 场景优化的（基于 Dagger 但去除了复杂性）。

✅ 使用 Hilt 之后

1. ViewModel 极其清爽
删掉 Factory 类，直接在构造函数上加注解。Hilt 会自动处理SavedStateHandle和ApiService的混合注入。

@HiltViewModelclassTradeViewModel@Injectconstructor(privatevalsavedStateHandle:SavedStateHandle,// Hilt 自动处理系统参数privatevalapiService:TradeApiService// Hilt 自动从容器中注入):ViewModel(){// ... 业务逻辑}

2. Activity 中零样板代码

@AndroidEntryPointclassTradeActivity:AppCompatActivity(){// 就像魔法一样，直接获取，所有依赖自动注入完成privatevalviewModel:TradeViewModelbyviewModels()overridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)// ...}}

收益总结：

消灭样板代码：彻底删除了所有的ViewModelFactory。
关注点分离：Activity 不需要知道 ViewModel 依赖了什么，只需要使用它。
自动生命周期管理：Hilt 自动处理单例（@Singleton）或跟随 Activity 销毁的对象，杜绝内存泄漏。

核心收益分析

1. 解决`SavedStateHandle`的注入难题

这是最直接的收益。在现代 Android 开发中，SavedStateHandle是标准组件。手动混合注入它和其他业务 Service 非常反人类。Hilt 对此有原生支持，能够极大地提升开发体验。

2. 为 Jetpack Compose 铺路

团队规划未来会引入 Compose。在 Compose 中，UI 是一棵函数树。

没有 Hilt：我们需要把 ViewModel 或者 Repository 从最顶层的Screen一层层传到最底层的Button（即 Prop Drilling），代码非常丑陋。
有了 Hilt：我们可以在任何层级的 Composable 函数中，通过hiltViewModel()直接获取 ViewModel，这是 Compose 开发的最佳实践。

3. 渐进式迁移，不影响旧代码

引入 Hilt不需要重构现有的 Java 代码或旧模块。

Hilt 可以和手动注入共存。
我们可以在新的“交易模块”中试用 Hilt。
旧的 Activity 和 Java 逻辑保持原样，互不干扰。

常见顾虑解答

Q: 引入 Hilt 会不会让代码变得很复杂？

A:不会，反而更简单了。以前的 Dagger2 确实复杂，但 Hilt 隐藏了 Component/Module 的组装逻辑。对于业务开发来说，90% 的场景只需要@HiltViewModel、@Inject和@AndroidEntryPoint三个注解。

Q: 会影响编译速度吗？

A:Hilt 使用 KAPT/KSP 处理注解，会有轻微的编译时间增加（通常几秒），但换来的是运行时性能的提升（没有反射）和代码量的显著减少。对于我们的项目规模，这点损耗完全可以接受。

结论

引入 Hilt 不是为了追求新技术，而是为了解决ViewModel 工厂代码冗余和依赖管理混乱的实际问题。

特别是在结合Retrofit + Coroutines + Sealed Classes的新架构下，Hilt 补全了最后一块拼图，让我们能以更少的代码写出更健壮的逻辑。

建议方案：在当前的“交易模块”重构分支中试行 Hilt，验证其对开发效率的提升，若效果良好再逐步推广。

Android 架构进化之路：为何在 Retrofit + 协程重构中，我们需要引入 Hilt？