📚 课程目录第3章 Compose中的协程基础

Compose中的协程基础：Dispatchers、withContext、suspend函数

做Compose开发，绕不开协程。说白了，Compose的UI运行在单线程上，任何耗时操作都可能导致界面卡顿。而协程，就是Android官方给我们准备的最佳方案。这节课我会从Dispatchers、withContext和suspend函数这三个核心点讲起，把协程在Compose里的正确用法说明白。

为什么先要搞懂协程的三个组件？

在Compose里跑协程，你总会遇到这样一个场景：从网络或者本地读数据，然后更新UI。如果你直接在主线程做IO操作，那就等着ANR吧。

我个人习惯，把协程分成三层来看：

调度器（Dispatchers） —— 决定代码在哪个线程跑
上下文切换（withContext） —— 在线程之间灵活跳转
挂起函数（suspend function） —— 非阻塞的延迟执行

这三者配合好了，你的Compose UI才能真正做到流畅无卡顿。

下面老规矩，先看一张整体的流程示意图，了解它们怎么协作。

核心要点：只要涉及到加密、文件读写、网络请求，都必须通过 withContext 切到对应调度器。UI 线程只做一件事：更新界面。

Dispatchers —— 谁在背后帮你跑代码？

Dispatchers是Kotlin协程内置的调度器。它定义了任务要用的线程池。常用的就这么几个：

调度器	用途	场景举例
Dispatchers.Main	UI线程，只能做轻量操作	更新Compose状态、渲染
Dispatchers.IO	IO密集型任务	文件读写、数据库、网络请求、加解密
Dispatchers.Default	CPU密集型计算	复杂运算、数据转换、压缩
Dispatchers.Unconfined	不限制线程	极少使用，仅用于测试

我的一点经验：很多人上来就把所有耗时操作扔到 Dispatchers.IO，其实不对。比如大量数学运算、加密哈希计算，用 Dispatchers.Default 效率更高。不过，你用 Dispatchers.IO 也不会崩溃，只是资源利用率差一点。

在Compose里，跟生命周期绑定的协程通常用 rememberCoroutineScope() 启动，它默认的调度器就是 Dispatchers.Main。

@Composable
fun MyScreen() {
    val scope = rememberCoroutineScope()
    var text by remember { mutableStateOf("") }

    Button(onClick = {
        scope.launch(Dispatchers.IO) {
            // 在 IO 线程做加密
            val encrypted = encryptSensitiveData("Hello")
            // 切回 Main 更新 UI
            withContext(Dispatchers.Main) {
                text = encrypted
            }
        }
    }) {
        Text("加密并展示")
    }
}

注意看，我把 launch 直接指定了 Dispatchers.IO。这样做有个好处，启动即切换到后台。不过我个人更偏好另一种写法，往下看。

withContext —— 线程之间自由跳转

withContext 是我用得最多的工具了。它不会启动新协程，而是在当前协程内部切换调度器，等任务完成后自动回到原始上下文。

我曾经在项目里遇到过这样一个场景：用户点击“加密”，然后显示加载状态，加密完成后更新界面。如果直接用 launch(Dispatchers.IO)，然后又在内部用 runBlocking，那 App 必卡。正确做法是：

@Composable
fun EncryptButton(data: String) {
    val scope = rememberCoroutineScope()
    var result by remember { mutableStateOf("") }

    Button(onClick = {
        scope.launch {
            // 当前在 Main 线程
            result = "加密中..."
            // 切换到 IO 做加密
            val encrypted = withContext(Dispatchers.IO) {
                performAESEncryption(data)
            }
            // 回到 Main 线程更新
            result = encrypted
        }
    }) {
        Text(result.ifEmpty { "开始加密" })
    }
}

suspend fun performAESEncryption(input: String): String {
    // 模拟加密耗时
    delay(300)
    return input.reversed()
}

警告：千万不要在 withContext 内部直接更新 Composable 状态！withContext 返回结果后，外部代码在 Main 线程才能更新 UI。如果非要半路更新，可以用 withContext(Dispatchers.Main) 嵌套处理。

withContext 还有一个实用特性：它支持多个调度器组合。比如你先在 IO 读文件，然后在 Default 做计算：

val data = withContext(Dispatchers.IO) {
    readFileFromDisk("secret.key")
}
val processed = withContext(Dispatchers.Default) {
    complexHashComputation(data)
}
// 回到 Main
text = processed

你看，代码还是顺序写的，但线程已经切换两次了。这就是协程的魅力。

suspend 函数 —— 协程的最小单元

suspend 函数是关键。它表示这个函数可以被挂起而不阻塞线程。你不需要在调用处加任何线程切换代码，直接调用就行。

但有一点值得注意：suspend 函数可以运行在任何调度器上，具体取决于它怎么写的。如果函数内部没有切换调度器，那它就运行在调用者的上下文中。

我在项目中遇到过这样的事：有人写了个 suspend 函数，内部直接做了大量IO操作，但没有用 withContext。结果调用它的协程在 Main 线程，直接导致卡顿。看下面这个错误例子：

// ❌ 错误的 suspend 函数 —— 没有切线程
suspend fun readEncryptedData(): ByteArray {
    // 这行代码运行在调用者的线程，如果是 Main 就完了
    val file = File("data.enc")
    return file.readBytes() // IO 操作在主线程
}

// ✅ 正确的写法
suspend fun readEncryptedData(): ByteArray = withContext(Dispatchers.IO) {
    val file = File("data.enc")
    file.readBytes()
}

结论：只要是可能耗时的 suspend 函数，开发者自己就要在内部通过 withContext 指定调度器。不要依赖调用者去切换。

再给一个关于加密的实战例子。假设你要在 Compose 里对一段文本做 AES 加密：

// 安全的加密 suspend 函数
suspend fun encryptSensitiveData(plainText: String, key: SecretKey): String = 
    withContext(Dispatchers.Default) {
        val cipher = Cipher.getInstance("AES/GCM/NoPadding")
        cipher.init(Cipher.ENCRYPT_MODE, key)
        val encrypted = cipher.doFinal(plainText.toByteArray())
        Base64.encodeToString(encrypted, Base64.NO_WRAP)
    }

// Compose 中使用
@Composable
fun EncryptScreen() {
    val scope = rememberCoroutineScope()
    var encryptedText by remember { mutableStateOf("") }

    Button(onClick = {
        scope.launch {
            encryptedText = encryptSensitiveData("Hello World", getKey())
        }
    }) {
        Text("执行加密")
    }
}

为什么这里用 Dispatchers.Default 而不是 IO？因为加密属于 CPU 密集型计算，Default 有线程池优化，与 CPU 核心数相关。你硬要用 IO 也能跑，但效率会低一些。

在Compose中如何组合调度器与加密操作？

我把经验总结成三条规则：

所有加密逻辑必须封装在 suspend 函数里，并且内部做好线程切换。
Compose 侧只管调用，通过 scope.launch 启动，结果通过状态返回。
切忌在 Composition 内部直接调用阻塞代码，哪怕你外面包了 runBlocking 也不行。

一个小技巧：你可以给项目写一个统一的加密协程工具类，所有加解密方法都声明为 suspend，内部默认使用 Dispatchers.Default 或 IO。这样团队成员使用时就不会踩坑了。

最后回顾一下这节课的内容。我们搞清楚了三件事：Dispatchers 决定了代码跑在哪条线程；withContext 让线程切换变得丝滑；suspend 函数配合内部调度器保证不会阻塞 UI。后面讲具体 ANR 案例时，这些知识会直接帮你写出更健壮的代码。