4. StateFlow的collect与collectLatest：收集模式、背压、取消协程

StateFlow 作为 Kotlin 协程中热数据流的代表，其消费端的行为完全由 collect 和 collectLatest 两种终端操作符定义。理解这两种收集模式的核心差异，是正确管理离线状态、避免 UI 闪烁或数据丢失的前提。

概念解释：两种收集模式的本质

collect 是挂起函数，它会按值发射的顺序依次处理每一个事件，使用 for 循环风格的顺序消费。当处理逻辑是耗时操作时，后续发射的值会在协程调度器中排队等待，形成 背压队列。

collectLatest 同样是挂起函数，但它的行为带有“抢占”语义：每当新的值到达，如果上一个值的处理协程尚未完成，系统会自动 取消 旧协程，并立即启动新协程处理最新值。旧的协程会在第一个挂起点（如 delay、网络请求）被取消，释放资源。

背压在两种模式中的表现

取消协程的底层机制

collectLatest 的取消行为依赖协程的 协作式取消 机制。当新值到达时，框架会调用旧协程的 Job.cancel()，旧协程只有在执行到挂起函数（如 delay、withContext、网络 I/O）时才会真正终止。如果旧协程中没有挂起点，它会一直运行到完成，collectLatest 会退化为普通的 collect。

// collect 模式：所有值顺序处理
stateFlow.collect { value ->
    delay(100)   // 每个值都会等待100ms
    updateUI(value)
}

// collectLatest 模式：新值到达时取消旧协程
stateFlow.collectLatest { value ->
    delay(100)   // 如果新值在此挂起点到达，旧协程被取消
    updateUI(value)
}

原理图解：两种收集模式的执行路径

类比说明：食堂打饭 vs 实时点餐

• collect 像食堂打饭：每个人（值）必须排队，轮到谁就为谁服务，即使后面来了更着急的人（新值），也必须等待前面的人打完饭。适合需要记录每个人吃了什么的场景。
• collectLatest 像实时点餐大厨：每次接到新订单（新值），如果正在做的菜不是最新订单，立刻停掉当前菜品，开始做新订单。保证出餐口始终是最新需求，但中间被取消的订单（中间值）就浪费了。

常见误区

1. 认为 collectLatest 一定比 collect “快”
   两者的发射端速度相同，collectLatest 只是通过取消旧协程减少了“无效处理”，在并发高的场景下响应更快，但并不意味着单次处理速度提升。
2. 混淆 collectLatest 与 conflate 操作符
   conflate 是在发射端合并值（只保留最新），而 collectLatest 是在消费端取消旧协程。两者机制不同，但效果相似。
3. 在 collectLatest 中执行无挂起点的计算密集型任务
   如果处理逻辑中没有挂起点（如纯 CPU 计算），collectLatest 无法真正取消旧协程，此时退化为普通 collect，失去抢占优势。
4. 在 collect 中忽略背压导致 OOM
   当发射速度持续快于处理速度时，collect 的待处理队列会无限增长，可能耗尽内存。应当在 collect 内部使用 buffer 或 conflate 等操作符主动管理背压。

练习题

题目： 你正在开发一个实时股票行情页面，StateFlow 每秒发射一次最新股价。UI 更新需要 200ms 的动画渲染（使用 delay(200) 模拟）。当网络延迟导致股价在短时间内连续更新 5 次时，以下哪种描述是正确的？

1. 使用 collect 时，5 次更新都会按顺序渲染，总耗时约 1000ms。
2. 使用 collectLatest 时，5 次更新都会渲染，但中间值可能被跳过。
3. 使用 collectLatest 时，只有第 1 次和第 5 次渲染，中间更新被取消。
4. 使用 collect 时，只有最新值会被渲染，旧值被丢弃。

答案：A —— collect 会排队处理所有发射的值，5 次更新依次延迟 200ms 后执行，总共约 1000ms。collectLatest 则会取消旧协程，只有最后一次更新能完整执行动画，中间三次被取消。

应用边界