二、suspend 与挂起函数：从 Retrofit 到 withContext

使用 Retrofit 进行网络请求并将结果展示在界面上，传统方式至少需要一次回调。先定义一个 ApiService 接口：

interface ApiService {
    @GET("/path/{params}")
    fun getResultCall(
        @Path("params") params: String
    ): Call<List<Result>>           // ← 回调风格：返回 Call 对象

    @GET("/path/{params}")
    suspend fun getResult(
        @Path("params") params: String
    ): List<Result>                  // ← 协程风格：直接返回数据，加 suspend
}

回调风格的使用代码：

private fun callbackStyle() {
    service.getResultCall("params")
        .enqueue(object : Callback<List<Result>> {
            override fun onResponse(
                call: Call<List<Result>>,
                response: Response<List<Result>>,
            ) {
                showResult(response.body()!!)   // 成功回调
            }

            override fun onFailure(call: Call<List<Result>>, t: Throwable) {
                t.printStackTrace()             // 失败回调
            }
        })
}

private fun showResult(results: List<Result>) {
    textView.text = results.toString()
}

这段代码的问题很明显：成功和失败的逻辑被拆在两个方法里，如果连续发多个请求就会出现"回调地狱"——每个回调里再嵌套下一个请求，代码缩进越来越深，异常处理也必须重复写。

同样的需求，用协程只需要这样写：

private fun coroutineStyle() = CoroutineScope(Dispatchers.Main).launch {
    val results = service.getResult("params")  // 直接拿到结果，像同步代码一样
    showResult(results)
}

suspend 关键字用来标记一个函数为挂起函数。当该函数被执行时，所在的协程就被挂起——或者说被暂停。

所谓"被挂起"，真正含义是：

1. 协程不再占用它正在工作的那个线程——它让出了线程
2. 但 service.getResult("params") 本身并未被暂停——它切换到了指定线程（后台线程）去执行网络请求
3. 网络请求执行完毕 → 协程恢复 → 回到原来的调度器（主线程）执行接下来的代码

在实际 Android 开发中，建议的写法是在创建协程作用域时指定 Dispatchers.Main，然后通过挂起函数自动切后台线程：

// 推荐写法：作用域绑定 Main，通过网络请求的 suspend 自动切后台
CoroutineScope(Dispatchers.Main).launch {
    //  当前在主线程
    val result1 = service.getResult("params1")  // suspend → 自动切后台 → 拿到结果回主线程
    val result2 = service.getResult("params2")  // 同上
    showResult(result1, result2)                // 在主线程更新 UI
}

在 Android 开发中，一般不需要自己去创建 CoroutineScope，直接使用 Jetpack 的 KTX 扩展即可。比如 lifecycleScope，它是 LifecycleOwner 的扩展属性：

// 源码定义
public val LifecycleOwner.lifecycleScope: LifecycleCoroutineScope
    get() = lifecycle.coroutineScope

它的两个最典型的实现类：

这两个实现类几乎是所有 Activity 和 Fragment 的基类，所以在 Activity 中可以直接使用 lifecycleScope，它是一个现成的 CoroutineScope，具备以下特点：

• 跟当前所在组件的生命周期绑定——组件销毁时自动取消所有协程，不会内存泄漏
• 内置的调度器默认使用 Dispatchers.Main.immediate（不是 Dispatchers.Default，也不是 Dispatchers.Main）

viewModelScope 和 lifecycleScope 几乎没什么不同，只是可供使用的位置不一样：

比如在 ViewModel 中发起网络请求：

class MyViewModel : ViewModel() {
    fun loadData() {
        viewModelScope.launch {               // 默认 Main.immediate
            val results = apiService.getResult("params")  // suspend → 自动切后台
            _liveData.value = results                     // 回到主线程更新 LiveData
        }  // ViewModel 清理时自动取消，不用担心泄漏
    }
}

在协程中可以启动另一个协程，但它们不是串行的，而是并行的：

CoroutineScope(Dispatchers.Main).launch {   // 外层协程在主线程
    launch(Dispatchers.IO) {                // 内层协程切到 IO 线程
        funOfHTTP()                          // 耗时操作，在 IO 线程执行
    }
    funOfUI()                                // 外层继续执行，不等待内层！
}

如果需要串行——先等 HTTP 请求完成，再更新 UI——应该用 withContext：

CoroutineScope(Dispatchers.Main).launch {
    withContext(Dispatchers.IO) {
        funOfHTTP()    // 协程挂起 → 切到 IO 线程执行
    }                   // ← 执行完毕才继续
    funOfUI()           // 回到主线程，此时 HTTP 一定已完成
}

这样就实现了：funOfHTTP() 执行时协程挂起并切到 IO 线程，等到 funOfHTTP() 执行完毕之后，funOfUI() 才会开始执行。

下面这段代码包含了两种写法的对比测试，日志输出能直接看出差异：

class CoroutineTest {
    val scope = CoroutineScope(Job() + Dispatchers.Main)

    fun launchTest() {
        scope.launch {
            println("CoroutineTestOfLaunch: 1 - launch + ${Thread.currentThread().name}")
            launch(Dispatchers.IO) {
                Thread.sleep(2000)
                println("CoroutineTestOfLaunch: 2 - launches + ${Thread.currentThread().name}")
            }
            println("CoroutineTestOfLaunch: 3 - launch + ${Thread.currentThread().name}")
        }
    }

    fun withContextTest() {
        scope.launch {
            println("CoroutineTestOfWithContext: 1 - launch + ${Thread.currentThread().name}")
            withContext(Dispatchers.IO) {
                Thread.sleep(2000)
                println("CoroutineTestOfWithContext: 2 - withContext + ${Thread.currentThread().name}")
            }
            println("CoroutineTestOfWithContext: 3 - launch + ${Thread.currentThread().name}")
        }
    }
}

依次调用两个方法，观察日志：

14:32:18.505  17210-17210  I  CoroutineTestOfLaunch: 1 - launch + main
14:32:18.506  17210-17210  I  CoroutineTestOfLaunch: 3 - launch + main
                                        ↑ 1和3几乎同一毫秒！不等待内层 launch
14:32:20.507  17210-17283  I  CoroutineTestOfLaunch: 2 - launches + DefaultDispatcher-worker-2
                                        ↑ 2秒后才打印，在 IO 线程

执行顺序：1(主) → 3(主) → 2(IO延时2秒)
结论：launch 不等待，3 在 2 之前就执行了

14:32:18.507  17210-17210  I  CoroutineTestOfWithContext: 1 - launch + main
14:32:20.509  17210-17284  I  CoroutineTestOfWithContext: 2 - withContext + DefaultDispatcher-worker-3
                                        ↑ 2秒后才打印，协程在此挂起等待
14:32:20.510  17210-17210  I  CoroutineTestOfWithContext: 3 - launch + main
                                        ↑ 2 执行完毕后才回到主线程打印 3

执行顺序：1(主) → [挂起2秒] → 2(IO) → 3(主)
结论：withContext 挂起等待，3 一定在 2 之后执行

withContext 这个名字可以从两部分拆解，对齐 Kotlin 标准库的命名惯例：

Kotlin 标准库中的 with 函数：

val s = StringBuilder()
with(s) {
    append("Hello")
    append(" World")
}
// 以 s 为上下文，{} 内的 append 都是对 s 的操作

从原理上去看，withContext 的本质只是切换当前协程所在的调度器。协程的执行始终跟随着某个调度器，当你调用 withContext(Dispatchers.IO) 时，协程框架执行以下三步操作：