Android Hilt 依赖注入与作用域

摘要：依赖注入把对象创建与业务使用分开，让服务替换、测试和生命周期管理更清楚。本文介绍注入边界、作用域和依赖图的常见问题。

一、从显式依赖开始

业务对象应通过构造参数声明需要的仓库、服务或时钟，而不是在内部自行创建数据库和网络客户端。构造注入能让依赖关系容易阅读，也便于在单元测试中直接传入替代实现。

接口和实现之间的映射应显式声明。第三方类型、需要额外配置的对象可由模块创建；普通业务类通常不需要为了注入而增加复杂工厂。

二、划分模块职责

绑定模块用于说明接口对应的实现，提供模块用于构造外部类型或带配置的对象。按职责拆分可以让对象来源容易追踪。不要将所有绑定堆进一个巨大模块，也不要为每个简单类创建单独模块。

网络客户端、数据库和序列化器等昂贵对象通常需要合理复用。对象的共享边界要与资源实际生命周期相符。

三、理解作用域

作用域决定对象在依赖图中的存活和复用时长。进程级服务通常应避免包含用户会话状态；页面或 ViewModel 状态不应意外延长到整个应用生命周期。

长生命周期对象依赖短生命周期对象时，常意味着边界设计不合理。反过来，短生命周期对象依赖稳定的应用服务通常可行。作用域不仅是性能选择，也会影响敏感状态的保留时间。

四、避免服务定位器

由 Android 或框架创建的组件可以使用框架支持的字段注入。普通业务对象优先通过构造参数接收依赖。不要在业务代码中到处从全局容器取对象，否则依赖关系会变得隐式。

依赖注入容器的职责是组装对象图，不应成为业务层的全局查询工具。

五、测试替换

纯业务类通常可在不启动注入框架的情况下测试。向构造函数传入假仓库、假时钟或内存数据源即可验证逻辑。关键绑定配置可用少量构建测试覆盖，不必让所有单元测试依赖完整应用组件。

测试替代实现应遵守同一接口契约。不要通过反射修改私有字段来注入假对象。

六、排查依赖图问题

缺少绑定时，沿着错误给出的依赖链查找未映射的接口。循环依赖通常表示职责边界不清，可以抽取更小的协调接口，而不是用延迟注入掩盖循环。

逐步迁移旧的手动创建方式，保持每一步都能编译，便于判断问题来自绑定配置还是架构变化。

七、常见问题

1. 避免把带账户状态的对象放到全局作用域。
2. 不要依赖注入来掩盖循环依赖。
3. 只在需要共享时设置作用域。
4. 对需要关闭的资源明确清理责任。
5. 让测试能在不启动整套应用的情况下构造业务对象。

八、总结

依赖注入的价值来自显式依赖、清楚的生命周期和可替换的边界。优先采用构造注入，谨慎设置作用域，并让容器专注于组装对象图。