📚 课程目录第2章后台任务概念

第2章 Compose界面刷新原理：重组机制、状态驱动、Snapshot系统、后台线程安全边界

Compose 的界面刷新完全不同于传统的 View 系统。它不再依赖 invalidate() 和 onDraw() 回调，而是基于三种核心机制：重组（Recompose）、状态驱动（State-driven）、快照系统（Snapshot）。理解这三者的协作方式，以及它们对后台线程的约束，是编写稳定、高性能 Compose 测试用例的前提。

2.1 重组机制：函数级重执行

Compose 将 UI 描述为一系列 @Composable 函数。当某个可组合项依赖的状态发生变化时，Compose 并不会重新创建整个视图树，而是只重新执行那些读取了变化状态的函数。这个过程称为“重组”（Recomposition）。

惰性执行：只有被标记为“脏”的组成单元才会被重新执行，其余部分保持不变。
顺序保证：重组总是在主线程上以确定顺序执行，但 Compose 允许跳过无需更新的分支。
跳过优化：如果输入参数未变化，Compose 会跳过对应函数的执行（需要 restartable 支持）。

调试建议：在 CompositionLocal 或 remember 中记录重组次数，可以帮助定位过度重组问题。

2.2 状态驱动：唯一的数据来源

Compose 使用 MutableState 对象作为可观察的数据容器。每次对 .value 的写入都会触发 Compose 底层记录该变更，并自动调度依赖该状态的组件进行重组。

传统 View 刷新	Compose 状态驱动
调用 `textView.text = "..."` 立即更新 UI	改变 `mutableStateOf("...")` 的值，Compose 异步调度重组
手动维护 `Invalidate` 与 `requestLayout`	状态自动追踪，自动触发需要的重组范围
后台线程可以直接修改 View 属性（需 runOnUiThread）	后台线程不允许直接修改 Compose 状态（见 2.4）

状态驱动的核心代码模式：

// 定义状态
val count = remember { mutableIntStateOf(0) }

// 点击事件中更新
Button(onClick = { count.intValue++ }) {
    Text("点击次数：${count.intValue}")
}
// 当 count.intValue 变化时，仅 Text 所在作用域重组

2.3 Snapshot 系统：事务隔离与冲突检测

Snapshot（快照）是 Compose 状态管理的底层实现。每个 MutableState 都关联一个快照对象，读操作记录当前快照版本，写操作创建新版本并标记冲突。

读-写分离：读取总是在某个快照上下文中进行，写入会生成新的快照。
全局版本号：每次写入都会递增全局版本计数器，Compose 通过比较版本号决定是否需要重组。
写时复制（COW）：状态值不可变引用，写入时复制新值并更新版本。

关键调试技能：在高并发场景下，可以通过 Snapshot.observe 观察版本变更，帮助定位状态冲突。

2.4 后台线程安全边界：危险的跨线程写入

Compose 的 Snapshot 系统默认认为所有状态变更都发生在同一个线程（主线程）。如果在后台线程中直接调用 mutableState.value = ...，会触发如下异常：

java.lang.IllegalStateException:
    Cannot call value() on a background thread.
    Use Snapshot.withSnapshot or runBlocking with Dispatchers.Main.

安全边界规则：

不允许在后台线程直接修改 Compose 状态。
必须通过 withContext(Dispatchers.Main) 或 LaunchedEffect 将写入切换到主线程。
允许在后台线程读取快照（只读操作），但不建议，因为读取可能基于过时快照。
使用 Snapshot.advanceGlobalSnapshot 手动推进快照可绕过检查，但仅应于工具/测试中。

下面是一个典型的错误示例及其修正：

// ❌ 错误：后台线程直接写入状态
viewModelScope.launch(Dispatchers.IO) {
    val result = fetchData() // 耗时操作
    _uiState.value = Result.Success(result) // 崩溃！
}

// ✅ 正确：切换到 Main 线程写入
viewModelScope.launch(Dispatchers.IO) {
    val result = fetchData()
    withContext(Dispatchers.Main) {
        _uiState.value = Result.Success(result)
    }
}

2.5 机制协作流程图

下面 SVG 展示了从后台任务完成到 Compose UI 刷新的完整协作路径。深色节点表示关键组件，黄色框标注了线程安全边界。

2.6 章节小结与测试策略

机制	测试关注点	常见陷阱
重组	验证仅受影响的可组合项被重新执行	过度重组导致性能下降，`key()` 缺失
状态驱动	确认状态变更后 UI 按预期更新	忘记使用 `remember` 导致状态重置
Snapshot	检查多线程版本冲突是否被正确报告	忽略 `Snapshot.advanceGlobalSnapshot` 的副作用
后台线程安全	直接写入必须抛出异常，切换主线程后正常	在 `LaunchedEffect` 内忘记 `withContext`

严格测试要求：在单元测试中，runTest 默认使用主线程调度器。若测试后台写入逻辑，必须显式使用 Dispatchers.IO + withContext 模拟真实场景，否则可能隐藏线程违规错误。

理解这套刷新原理，是后续编写后台任务触发刷新测试用例的基石。只有掌握了重组范围、状态生命周期和线程安全边界，才能设计出既准确又高效的测试代码。