Compose 状态模型核心：remember、mutableStateOf、StateFlow 与 Compose 订阅关系
在 KMP 中，Compose 的响应式更新完全依赖于一个紧凑的状态订阅模型。`remember`、`mutableStateOf` 和 `StateFlow` 是三个最基础的原语，但它们与 Compose 的订阅关系却完全不同。理解这三者的边界、数据流方向以及信任链路，是构建可维护、高性能状态共享架构的第一步。
三个原语：角色与边界
| 原语 | 核心职责 | 生命周期 | 线程模型 |
|---|---|---|---|
remember |
在重组中保持对象引用，不触发重组 | 与调用它的 Composable 作用域绑定 | Compose 主线程 |
mutableStateOf |
声明可观察状态，值变化时自动通知订阅者重组 | 同 remember（通常配合使用） |
Compose 主线程（赋值操作建议同步） |
StateFlow |
对外暴露不可变状态，通过 collectAsState 桥接 Compose | 独立于 Composable 作用域（由 viewModelScope 或协程控制） | 协程安全，可在任意线程更新 |
Compose 订阅关系图
下面的 SVG 展示了三个原语与 Compose 重组引擎之间的连接与隔离边界。
控制流与信任链路
- 数据流：状态从
StateFlow(ViewModel) →collectAsState()→ Compose 重组 → UI 渲染。 - 控制流：用户事件 → Composable →
mutableStateOf修改 → 或通过 ViewModel 函数 →StateFlow更新。 - 信任链路：Compose 仅信任本线程的
mutableStateOf变化；跨线程状态必须通过StateFlow+ 协程边界转换。
选型权衡
| 场景 | 推荐原语 | 原因 |
|---|---|---|
| 仅 Composable 内部局部 UI 状态（如展开/折叠） | remember + mutableStateOf |
最小依赖，无生命周期泄漏风险 |
| 状态需要跨 Composable 层级传递（但仍在同一屏幕） | remember + mutableStateOf + 状态提升 |
避免引入 ViewModel 成本 |
| 状态来自业务层或持久化，需要协程协作 | StateFlow |
线程安全、背压支持、生命周期分离 |
| 跨模块共享状态（如登录状态） | StateFlow + 单例共享 |
避免 Compose 引用泄漏 |
风险点： 在 Compose 中直接对
mutableStateOf 进行异步修改（如从协程中更新）会导致未定义重组行为。必须使用 withContext(Dispatchers.Main) 或通过 StateFlow 桥接。此外，滥用 remember 保存大对象（如数据库连接）会导致内存泄露。
落地步骤
- 识别状态作用域：判断状态是局部 UI、页面级还是跨页面级。
- 局部 UI 状态：直接用
remember { mutableStateOf(初始值) }。 - 页面级业务状态：创建 ViewModel，定义
StateFlow<UiState>，在 Composable 中用collectAsState()订阅。 - 跨页面状态：使用单例或依赖注入容器保存
SharedFlow或StateFlow，注意MemoryScope管理。 - 测试订阅链路：写单元测试验证
StateFlow更新后 Compose 重组次数是否合理。
验收标准
- 每个
mutableStateOf修改都能在 16ms 内触发重组（无明显掉帧）。 - 跨线程状态更新不会导致
java.lang.IllegalStateException: Reading state in a non-Composable context。 - 使用
StateFlow时，Composable 生命周期与协程 scope 解耦，屏幕旋转后不会丢失状态。 - 随意在
remember外部修改mutableStateOf的代码被静态分析工具检测并禁止合并。
实践建议： 初期团队可设定硬性规则——所有业务状态强制使用
StateFlow，UI 辅助状态（如动画进度、滚动偏移）才允许 mutableStateOf。这能避免 90% 的线程和生命周期问题。