第3章 后台任务与异步刷新基本概念：协程、Dispatcher、Main/IO/Default 调度器在测试中的表现差异

3.1 原理与背景

在 Compose UI 中，后台任务通常通过 Kotlin 协程实现，例如在 LaunchedEffect、rememberCoroutineScope 或 ViewModel 的 viewModelScope 中发起异步加载。协程的调度由 CoroutineDispatcher 决定——它控制协程在哪个线程池上执行。Android 开发中最常用的三个内置调度器为：

• Dispatchers.Main：绑定主线程（UI 线程），适合界面更新和轻量操作。
• Dispatchers.IO：专为 I/O 密集型任务（网络、文件读写）设计的弹性线程池。
• Dispatchers.Default：面向 CPU 密集型任务（排序、解析），线程数等于 CPU 核心数。

在 Compose UI 测试 环境中，调度器的行为与生产环境存在显著差异：Dispatchers.Main 由测试框架接管为同步执行，而 Dispatchers.IO 和 Dispatchers.Default 默认仍使用后台线程。这种差异会直接导致测试时序不可控、断言过早执行或测试超时。理解三者在测试中的表现，是编写稳定异步刷新测试的基础。

3.2 三种调度器在测试中的行为差异

3.3 完整实现步骤与代码片段

以下案例展示一个典型的后台刷新场景：新闻列表 在 LaunchedEffect 中模拟网络请求，并使用不同调度器加载数据。通过两组测试验证调度器差异对断言时序的影响。

步骤 1：定义 ViewModel 与 Composable（生产代码）

// 生产 ViewModel，调度器通过构造器注入，便于测试替换
class NewsViewModel(
    private val ioDispatcher: CoroutineDispatcher = Dispatchers.IO,
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) : ViewModel() {

    private val _items = MutableStateFlow<List<String>>(emptyList())
    val items: StateFlow<List<String>> = _items.asStateFlow()

    private val _isLoading = MutableStateFlow(false)
    val isLoading: StateFlow<Boolean> = _isLoading.asStateFlow()

    fun refresh() {
        viewModelScope.launch(ioDispatcher) {
            _isLoading.value = true
            // 模拟网络 I/O 延迟
            delay(800)
            // 模拟 CPU 密集型解析
            val parsed = withContext(defaultDispatcher) {
                (1..3).map { "新闻标题 #$it" }
            }
            _items.value = parsed
            _isLoading.value = false
        }
    }
}

// Composable 界面
@Composable
fun NewsFeed(viewModel: NewsViewModel = viewModel()) {
    val items by viewModel.items.collectAsState()
    val isLoading by viewModel.isLoading.collectAsState()

    if (isLoading) {
        Text("加载中...")
    } else if (items.isEmpty()) {
        Text("暂无新闻")
    } else {
        LazyColumn {
            items(items) { title ->
                Text(text = title, modifier = Modifier.padding(8.dp))
            }
        }
    }
}

步骤 2：测试场景 A —— 使用 Dispatchers.Main（同步执行）

@OptIn(ExperimentalCoroutinesApi::class)
@Test
fun testRefreshWithMainDispatcher() = runTest {
    // 将 IO 和 Default 都替换为 Main，所有协程在主线程同步执行
    val viewModel = NewsViewModel(
        ioDispatcher = Dispatchers.Main,
        defaultDispatcher = Dispatchers.Main
    )

    composeTestRule.setContent {
        NewsFeed(viewModel)
    }

    // 触发刷新
    viewModel.refresh()

    // 由于全部在 Main 同步执行，刷新完成后立刻可以断言
    composeTestRule.onNodeWithText("新闻标题 #1").assertIsDisplayed()
    composeTestRule.onNodeWithText("加载中...").assertDoesNotExist()
}

步骤 3：测试场景 B —— 使用 Dispatchers.IO + Default（真实异步）

@OptIn(ExperimentalCoroutinesApi::class)
@Test
fun testRefreshWithIOAndDefaultDispatcher() = runTest {
    // 保留真实的 IO 和 Default 调度器（生产默认值）
    val viewModel = NewsViewModel()

    composeTestRule.setContent {
        NewsFeed(viewModel)
    }

    viewModel.refresh()

    // 此时后台任务仍在 IO/Default 线程中执行，需要显式等待
    composeTestRule.waitUntil(timeoutMillis = 3000) {
        composeTestRule.onNodeWithText("新闻标题 #1").isDisplayed()
    }

    // 验证加载中状态已消失
    composeTestRule.onNodeWithText("加载中...").assertDoesNotExist()
}

3.4 关键 API 与参数

下表列出了测试异步刷新时必须掌握的 API 及其作用：

runTest(StandardTestDispatcher()) { ... }

runTest(UnconfinedTestDispatcher()) { ... }

advanceUntilIdle() // 在 runTest 块内调用

Dispatchers.setMain(StandardTestDispatcher())

waitUntil(3000) { condition }

3.5 常见问题与调试技巧

• 问题 1：测试超时（TimeoutException）
  原因：Dispatchers.IO 或 Dispatchers.Default 未被替换，后台任务在真实线程池中执行，runTest 无法推进其虚拟时间。
  调试技巧：在 runTest 块内打印线程名，确认协程运行在哪个调度器上。

  println("当前线程: ${Thread.currentThread().name}")

• 问题 2：断言过早执行导致假阴性
  现象：测试有时通过有时失败，尤其在 CI 环境中。
  解决方案：避免依赖隐式时序，始终对异步结果使用 waitUntil 或 advanceUntilIdle。

  // 错误：假定异步操作已经完成
  composeTestRule.onNodeWithText("新闻标题 #1").assertIsDisplayed()
  
  // 正确：等待异步结果
  composeTestRule.waitUntil(3000) {
      composeTestRule.onNodeWithText("新闻标题 #1").isDisplayed()
  }

• 问题 3：UnconfinedTestDispatcher 导致协程顺序混乱
  原因：UnconfinedTestDispatcher 会立即执行协程到第一个挂起点，如果后续还有 delay 或 withContext，可能产生非预期的交错执行。
  建议：复杂异步场景优先使用 StandardTestDispatcher 配合 advanceUntilIdle。
• 调试技巧：启用协程调试日志

  // 在 build.gradle.kts 中添加
  debugImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-debug:1.8.1")
  
  // 测试中捕获协程堆栈
  with(DebugProbes) {
      install()
      // 执行异步操作
      viewModel.refresh()
      dumpCoroutines() // 打印所有活跃协程
      uninstall()
  }

3.6 可验证的测试结果与日志

运行上述两组测试（Main vs IO+Default），控制台输出与断言结果对比如下：

测试 A（Dispatcher.Main 同步执行）日志：

2025-03-20 14:30:01.123 [Test worker @coroutine#1] 开始刷新
2025-03-20 14:30:01.124 [Test worker @coroutine#1] 设置 isLoading = true
2025-03-20 14:30:01.125 [Test worker @coroutine#1] delay(800) 被虚拟时间跳过
2025-03-20 14:30:01.126 [Test worker @coroutine#1] 解析完成，设置 items
2025-03-20 14:30:01.127 [Test worker @coroutine#1] 设置 isLoading = false
2025-03-20 14:30:01.128 [Test worker] 断言: 新闻标题 #1 可见
测试结果: ✅ 通过 (耗时 12ms)

测试 B（Dispatchers.IO + Default 真实异步）日志：

2025-03-20 14:30:05.456 [Test worker @coroutine#2] 开始刷新
2025-03-20 14:30:05.457 [DefaultDispatcher-worker-1 @coroutine#2] 设置 isLoading = true
2025-03-20 14:30:05.458 [DefaultDispatcher-worker-1 @coroutine#2] delay(800) 在真实线程挂起
2025-03-20 14:30:06.259 [DefaultDispatcher-worker-1 @coroutine#2] 解析完成，设置 items
2025-03-20 14:30:06.260 [DefaultDispatcher-worker-1 @coroutine#2] 设置 isLoading = false
2025-03-20 14:30:06.261 [Test worker] waitUntil 轮询开始...
2025-03-20 14:30:06.362 [Test worker] waitUntil 条件满足: 新闻标题 #1 可见
测试结果: ✅ 通过 (耗时 912ms)