Android开发中用Hilt向ViewModel注入ActivityScoped LiveData是否合理？

首先明确：通过Hilt将标注了ActivityScoped的LiveData实例注入到ViewModel中属于不良实践。

该方案的主要缺陷 #

• 违反关注点分离原则：ViewModel的核心职责是持有对应页面的私有状态，直接注入独立的共享LiveData会导致状态来源碎片化，后续排查状态异常时无法快速定位修改方，维护成本远高于统一的状态管理方案。
• 存在生命周期对齐风险：ActivityScoped实例的生命周期与宿主Activity绑定，而ViewModel的生命周期与之高度耦合但不完全一致，后续如果做ViewModel复用、配置变更适配时，极易出现内存泄漏、事件重复分发、状态丢失等问题。
• 破坏单向数据流规范：注入的共享LiveData可被所有持有它的ViewModel随意修改，没有统一的状态修改入口，完全不符合Clean架构中状态变更必须走受控路径的要求。

更优的实现方案 #

你可以根据共享状态的生效范围选择对应方案，完全可以避免Activity ViewModel臃肿的问题：

• 若状态为全局业务通用（比如用户登录状态、基础配置信息）：在Domain层新增业务域状态Store，Store为单例实现，仅持有对应业务的共享状态（LiveData/StateFlow），对外仅暴露不可变的观察接口，所有状态修改必须通过Store提供的受控方法执行。各个ViewModel需要访问共享状态时直接依赖对应Store即可，不需要把逻辑堆到Activity ViewModel中。
• 若状态仅在单个Activity的所有Fragment间共享：保留Activity ViewModel作为该页面组的状态容器，但将所有业务逻辑抽离为独立的UseCase实现，Activity ViewModel仅负责持有共享状态、调用UseCase、分发状态，本身不承载复杂逻辑，不会出现臃肿问题。
• 若状态仅在同一条导航流程的几个Fragment间共享：直接使用Jetpack Navigation提供的导航图作用域ViewModel，该ViewModel的生命周期与对应导航图绑定，比Activity作用域更轻量化，不需要额外通过Hilt注入共享实例，也不会污染全局Activity的作用域。

重构建议 #

你可以先将当前跨ViewModel观察的所有LiveData按生效范围归类，对应匹配上述方案替换即可，彻底消除跨ViewModel直接观察的混乱依赖。

内容的提问来源于stack exchange，提问作者Filip Östermark