Jetpack Compose中为何用Flow合并生成ViewState data class而非MutableState

这个设计本质是官方在推广单向数据流+单一可信数据源的架构规范，除了代码整洁之外，有很多实际的工程价值： #

1. 强保证状态一致性 #

如果把页面依赖的多个状态分散成独立的MutableState或者Flow，很容易出现不同步的问题：比如分类列表加载完成了，但对应的选中分类还没更新，或者反过来，导致UI显示逻辑错乱。
用combine合并生成单一ViewState的话，所有依赖的Flow都至少发射过一次值之后才会生成可用的状态，任意一个依赖的Flow更新时，都会用所有依赖项的最新值重新计算状态，从根源上避免局部状态不同步的问题，页面越复杂，这个优势越明显。

2. 可测试性大幅提升 #

所有状态逻辑都收敛在ViewModel层，和Compose UI完全解耦：你要测试状态变更逻辑、业务触发逻辑的时候，直接收集ViewModel暴露的StateFlow即可，不需要依赖Compose运行环境，普通的单元测试就能覆盖。
如果把状态直接声明在UI层的MutableState里，测试必须依赖Compose测试框架，编写成本和运行速度都会差很多。

3. 状态变更可追溯、易调试 #

单一的StateFlow流可以很方便的插入调试逻辑，比如加onEach打印每次状态变化的前后值，甚至可以实现状态回溯的"时光旅行"调试，快速复现bug。分散的状态根本做不到统一的状态变更监控。

4. 天然适配生命周期，避免配置变更丢失状态 #

放在ViewModel的StateFlow里的状态，天然和ViewModel生命周期绑定，不会因为屏幕旋转、系统语言切换等配置变更导致状态丢失，也不需要额外写rememberSaveable的序列化逻辑来保存复杂类型的状态。 #

为什么把选中分类这类交互状态也放到Flow里？ #

首先明确：如果是完全和业务逻辑无关的临时UI状态（比如一个下拉菜单的展开/收起、输入框的临时输入内容），完全可以直接在UI层用remember { mutableStateOf() }处理，官方也支持这种做法。
官方示例把选中分类这类状态放到ViewModel的Flow里，主要是考虑到这类状态通常会和业务逻辑联动：比如选中分类之后需要拉取对应分类下的内容，这时候直接在ViewModel里监听selectedCategory的变化，用flatMapLatest之类的操作符就能自动触发数据拉取，不需要UI层来回传递事件。
另外这类状态通常需要在配置变更后保留，放在ViewModel里比用rememberSaveable处理复杂类型要省心很多。 #

内容的提问来源于stack exchange，提问作者Nuby Joe