上一篇
如何编写高内聚的ViewModel，有哪些最佳实践？
高内聚ViewModel编写的核心在于将界面状态和逻辑封装在单一职责的单元内，通过清晰的数据流与UI层交互，避免业务泄漏和代码膨胀。
高内聚ViewModel编写方法：从职责划分开始
编写高内聚的ViewModel，首先要明确它的边界，ViewModel不是万能工具，它的职责仅限于管理UI所需的数据状态和触发与界面相关的操作，业内专家指出，一个ViewModel应该只对应一个页面或一个功能组件,超过这个范围就该考虑拆分。
ViewModel的核心职责清单
- 持有并暴露UI状态（如加载中、数据内容、错误信息）
- 处理用户交互事件（按钮点击、下拉刷新等）
- 协调数据层与UI层之间的转换（如格式化、过滤）
- 管理生命周期相关的异步操作（协程、RxJava订阅）
ViewModel不该做的事
- 直接操作View（如设置TextView、调用动画）
- 持有Activity或Fragment引用
- 执行数据库或网络请求（应委托给Repository）
- 包含复杂的业务逻辑（如计算折扣、校验表单）
当你把ViewModel限制在这些边界内，它自然变得内聚，如果发现一个ViewModel里既有商品列表获取，又有用户登录逻辑，甚至还有购物车数量计算，那就是高内聚的反面——职责混乱，此时应当拆分出多个ViewModel,每个只负责一个领域。
Android ViewModel最佳实践：让代码更简洁
在Android开发中，ViewModel凭借生命周期感知能力成为MVVM架构的核心，但很多开发者只是把ViewModel当成一个数据容器，没有真正实现高内聚，下面是我在实际项目中积累的写法,能帮你避免臃肿。
使用密封类管理界面状态
高内聚ViewModel要求状态变化可预测，用sealed class或data class描述UI状态，而不是分散为多个LiveData或MutableStateFlow。
ViewModel暴露一个StateFlow<MainUiState>，Activity或Fragment收集这个流，根据状态渲染不同界面，这样所有状态逻辑集中在一处,修改时只影响这一个文件。
用事件驱动代替命令式调用
高内聚ViewModel不直接调用View方法，而是通过一次性事件（如导航、Snackbar）通知UI层，采用Channel或SharedFlow发送事件，UI层使用LiveData或Flow收集。
private val _events = Channel<UiEvent>(Channel.BUFFERED) val events = _events.receiveAsFlow() fun onButtonClick() { // 处理业务 viewModelScope.launch { _events.send(UiEvent.ShowSnackbar("操作成功")) } }
这种做法让ViewModel与View解耦，测试时只需验证事件是否发出,无需模拟View。
依赖载入与单元测试
高内聚的ViewModel必定可测试，通过构造函数载入Repository，不使用AndroidViewModel或Application引用，测试时传入mock数据源,每个方法都是纯数据操作。
class MainViewModel( private val repository: ItemRepository ) : ViewModel() { // ... }
这样，你可以在不启动Activity的情况下验证ViewModel的行为，据统计，遵循这种写法的项目，单元测试覆盖率提升明显,后期维护成本大幅降低。
MVVM架构中ViewModel高内聚实现
在MVVM架构下，ViewModel是连接View和Model的桥梁，高内聚意味着它只做“桥梁”的事,不去涉足两端的复杂细节。
分层配合：数据流单向流动
高内聚ViewModel依赖数据层的清晰输出，Repository返回的数据应该已经是干净的业务对象，ViewModel不需要做大量转换，如果发现ViewModel里有大量的if-else或数据拼装，说明数据层设计不合理,需要调整。
典型单向数据流顺序
- View触发事件（如点击搜索）
- ViewModel接收事件，调用Repository
- Repository返回数据或错误
- ViewModel更新StateFlow，发出新状态
- View收集状态，刷新UI
在这个流程中，ViewModel只做两件事：调用Repository和更新状态，它不关心数据怎么来的,也不关心UI怎么渲染。
避免ViewModel内的“上帝类”
项目规模变大后，很多开发者习惯把所有页面逻辑放在一个ViewModel里，这违背了高内聚原则，一个ViewModel应该只对应一个界面或一个功能模块，如果发现一个ViewModel有超过10个公开方法，或者状态类超过20个字段,就该考虑拆分。
拆分建议
- 按功能模块拆分：用户信息、商品列表、购物车分别用独立ViewModel
- 按生命周期拆分：短生命周期（弹窗）用单独ViewModel，长生命周期（页面）用主ViewModel
- 按数据源拆分：本地数据与网络数据不同时，可区分处理
如何编写高内聚ViewModel（实操步骤）
下面是一个具体的方法,你可以在下次重构时直接使用。
定义清晰的UIModel
不要直接将数据模型暴露给View，创建UIModel类，只包含界面需要显示的字段，用户实体有id、name、age、email，但界面只显示姓名和年龄，那么UIModel就只包含这两个字段，这样ViewModel的输出稳定,不受数据层变化影响。
使用sealed class管理事件
所有UI一次性事件（导航、弹窗、跳转）统一放到一个密封类中，ViewModel内部不直接调用LiveData发送事件，而是通过SharedFlow发射，每个事件都对应一个明确的动作,便于测试和追踪。
协程作用域与任务取消
高内聚的ViewModel必须处理好异步任务的生命周期，使用viewModelScope启动协程，当ViewModel被清除时自动取消，如果需要在页面关闭后继续执行（如日志上传），使用ProcessLifecycleOwner或全局作用域,但这类操作不应放在ViewModel中。
fun loadData() { viewModelScope.launch { // 网络请求，ViewModel销毁时自动取消 val result = repository.fetchData() _uiState.value = result.fold( onSuccess = { MainUiState.Success(it) }, onFailure = { MainUiState.Error(it.message) } ) } }
这样既保证了响应式,又避免了内存泄漏。
高内聚ViewModel常见问题解答
Q: 高内聚ViewModel真的能提高开发效率吗？
A: 能，职责清晰的ViewModel让新人更快上手，改动一个功能只需要修改对应的ViewModel，不影响其他模块，可测试性提升，Bug更容易定位,后期维护成本明显降低。
Q: 我该如何在团队中推广高内聚ViewModel写法？
A: 先制定代码规范，明确ViewModel的职责边界，通过Code Review检查每个ViewModel是否只做一件事，推荐使用lint工具或自定义规则，自动检测ViewModel中的不当依赖（如持有Context），定期分享重构案例,让团队看到实际收益。
Q: ViewModel与LiveData的关系如何在高内聚中体现？
A: LiveData是ViewModel暴露数据的推荐方式之一，但高内聚要求ViewModel不要直接操作LiveData内部数据，使用MutableLiveData作为私有变量，对外暴露不可变的LiveData，或者使用StateFlow，通过stateIn转换为SharedFlow,确保数据源唯一。
