📚 课程目录第4章调度器选择策略

4. 调度器选择策略：Dispatchers.Main / IO / Default / Unconfined 适用场景

4.1 现象识别：你遇到的卡顿是哪一种？

错误的调度器选择是协程卡顿的常见根源。请对照下表快速匹配你的应用场景：

现象	可能涉及调度器	典型用户感知
主线程长时间阻塞，列表滑动掉帧	`Dispatchers.Main` 中运行了 IO / CPU 任务	界面卡顿、ANR
后台 IO 操作（读/写文件、网络请求）迟迟不完成	`Dispatchers.Default` 被 IO 任务占用，非 IO 协程排队	列表图片加载慢、数据刷新滞后
CPU 密集计算（Bitmap 处理、JSON 解析）导致 IO 线程饥饿	`Dispatchers.IO` 运行 CPU 密集任务，线程池撑爆，触发线程池退避	后台批量操作变慢、高并发时响应延迟
单元测试中协程线程混乱、main 断言失败	`Dispatchers.Unconfined` 未理解其“不切换”语义	测试不稳定、random 线程切换导致竞态

⚠ 常见误区： 很多开发者认为 Dispatchers.IO 是“万能后台调度器”，将大量 CPU 密集任务也扔进去，轻则线程池膨胀，重则触发 BlockingOperations 检测警告。

4.2 数据采集：追查调度器使用轨迹

确认现象后，通过以下手段采集调度器使用数据：

协程调试日志： 在关键协程块中添加 Thread.currentThread().name 输出。
FD / 线程 dump： 通过 adb shell dumpsys thread 或 JStack 查看线程名与数量。
CoroutineContext 快照： 使用 coroutineContext[ContinuationInterceptor] 获取当前调度器实例。
性能监控（Fireside / Matrix）： 标记自定义 Span，对比不同调度器下任务执行时长。

// 采集示例：在协程内记录当前调度器
launch {
    val interceptor = coroutineContext[ContinuationInterceptor]
    Log.d("DispatcherCheck", "当前调度器: $interceptor")
    // 输出: Dispatchers.Default 或 Dispatchers.IO 等
}

4.3 原因定位：调度器选择故障树

使用以下故障树（Fault Tree）辅助定位问题根因。SVG 图展示了从任务类型到最终调度器的决策路径，以及常见的误用分支。

4.4 修复动作：按规则选择正确调度器

根据定位结论，采用以下判断规则表进行修复：

调度器	任务类型	线程池	注意事项
`Dispatchers.Main`	UI 更新、轻量计算（< 16ms）	主线程（1条）	绝不可执行 IO / 重型计算；若需延迟可用 `withTimeout` 防止挂起
`Dispatchers.IO`	读写文件、网络请求、数据库访问	弹性线程池（默认 64 条）	避免 CPU 密集；使用 `limitedParallelism` 控制并发数
`Dispatchers.Default`	图像压缩、JSON 解析、列表排序	CPU 绑定（线程数 = 核数+1）	不要扔 IO 操作，否则可用线程被阻塞导致 CPU 闲置
`Dispatchers.Unconfined`	单元测试、协程启动处无需切换线程	不固定（继承启动线程）	仅为测试或浅层启动设计；生产环境慎用，容易引发线程安全问题

修复代码示例（修复前 → 修复后）：

// ❌ 错误：IO 操作跑在 Default 上
withContext(Dispatchers.Default) {
    val data = URL("https://example.com").readText()
}
// ✅ 修复后：使用 Dispatchers.IO
withContext(Dispatchers.IO) {
    val data = URL("https://example.com").readText()
}

// ❌ 错误：CPU 密集跑在 IO 上
withContext(Dispatchers.IO) {
    compressBitmap(bitmap) // 纯 CPU 计算
}
// ✅ 修复后：使用 Dispatchers.Default
withContext(Dispatchers.Default) {
    compressBitmap(bitmap)
}

💡 最佳实践： 对于混合型任务（先 IO 再 CPU 接着更新 UI），使用 withContext 分层切换，保持调度器纯净。

4.5 复测：验证修复效果

执行以下复测步骤确认卡顿消除：

性能抽样： 使用 Trace.begin/endSection 或者 SimpleProfiler 测量任务段耗时。
线程计数： 观察主线程响应时间（FrameMetrics）、IO 线程池数量（/proc/self/tasks）。
回归测试： 执行之前的卡顿复现场景（如大图加载、列表快速滑动），检查帧率是否回升至 55+ fps。
压力测试： 模拟高并发，确保 Dispatchers.IO 不因 CPU 任务溢出。

// 复测时采集调度器变更后的线程名
val before = Thread.currentThread().name
withContext(Dispatchers.Default) {
    Log.d("Fix", "调度前: $before, 调度后: ${Thread.currentThread().name}")
}
// 输出应显示 DefaultDispatcher-worker-1 / 2 等

4.6 预防：纳入团队规范

编码规范： 禁止在 Dispatchers.Main 中调用任何挂起时间超过 8ms 的函数。
Lint 规则： 使用自定义 CoroutineDispatcherDetector 检测 Dispatchers.Default 中阻塞网络等操作。
代码审查 CheckList：
- □ 每个 withContext 选择是否与任务类型匹配？
- □ Dispatchers.IO 是否仅用于 IO 阻塞？
- □ Dispatchers.Unconfined 是否仅出现在测试模块？
- □ 是否使用了 limitedParallelism 控制 IO 并发上限？
自动测试： 在 CI 中运行 CoroutineDispatcherTestRule 验证所有 launch 的调度器正确。