协程上下文与调度器：Dispatchers详解

协程上下文，说白了就是协程运行时的“环境配置包”。它决定了协程在哪个线程上执行、携带哪些附加信息。而调度器，就是上下文里最核心的那个角色——它负责把协程派发到合适的线程池。

我记得刚接触协程那会儿，总觉得调度器不就是指定线程嘛，有啥好研究的？直到我在一个图片处理项目里，因为用错了调度器，导致UI卡顿被测试同学追着打……嗯，从那以后我再也不敢小看Dispatchers了。

四大调度器详解

Kotlin提供了四个内置调度器，每个都有明确的适用场景。我一个个说。

Dispatchers.Main

主线程调度器，专门处理UI操作。在Android中，它绑定到主Looper。所有界面更新、与View的交互，都必须跑在Main上。

// 正确用法：只在Main上做UI更新
lifecycleScope.launch(Dispatchers.Main) {
    val result = withContext(Dispatchers.IO) { fetchData() }
    textView.text = result  // 切回Main更新UI
}

Dispatchers.IO

专为IO密集型任务设计。它背后是一个动态线程池，会根据负载自动扩容。默认最大线程数跟CPU核心数有关，但可以配置。

我个人习惯把以下操作都扔到IO调度器上：

• 网络请求（Retrofit、OkHttp）
• 文件读写（SharedPreferences、DataStore、File操作）
• 数据库操作（Room、SQLDelight）
• Bitmap的编解码

// 典型用法：IO调度器处理网络+数据库
suspend fun loadUserProfile(userId: String): UserProfile {
    return withContext(Dispatchers.IO) {
        val user = apiService.getUser(userId)  // 网络请求
        val posts = database.postDao().getPostsByUser(userId)  // 数据库查询
        UserProfile(user, posts)
    }
}

Dispatchers.Default

CPU密集型任务的默认选择。它使用与IO调度器相同的线程池，但最大线程数等于CPU核心数（至少为2）。

你想想看，如果你的手机是8核处理器，Default调度器最多同时跑8个任务。再多也没用，因为CPU资源就那么多，线程切换反而浪费性能。

// 适合Default的场景：大量计算
suspend fun processImage(image: Bitmap): Bitmap {
    return withContext(Dispatchers.Default) {
        // 图像滤镜处理，纯CPU计算
        applyFilter(image, Filter.SEPIA)
    }
}

Dispatchers.Unconfined

这个调度器比较特殊。它不限制协程在哪个线程执行。协程启动时，它会在当前线程执行；当遇到挂起点恢复后，它会在恢复它的那个线程上继续执行。

我在项目中几乎不用Unconfined。为什么？因为它不可预测。你没法保证协程的后续代码跑在哪个线程上。这在Android里是致命的——万一UI操作跑到了子线程，直接崩溃。

// Unconfined的典型表现
runBlocking {
    launch(Dispatchers.Unconfined) {
        println("开始：${Thread.currentThread().name}")  // main
        delay(100)
        println("恢复：${Thread.currentThread().name}")  // kotlinx.coroutines.DefaultExecutor
    }
}

上下文继承与覆盖

协程上下文有一个重要特性：继承。子协程会默认继承父协程的上下文，但可以覆盖其中的元素。

为什么会这样设计？你想想看，如果你在父协程里设置了CoroutineName，子协程自动带上这个名字，调试起来多方便。

// 上下文继承示例
runBlocking(Dispatchers.Default + CoroutineName("Parent")) {
    launch {
        // 这里继承了Dispatchers.Default和CoroutineName("Parent")
        println("子协程：${coroutineContext[CoroutineName]}")  // Parent
    }
    
    launch(Dispatchers.IO + CoroutineName("Child")) {
        // 覆盖了调度器和名称
        println("子协程：${coroutineContext[CoroutineName]}")  // Child
    }
}

withContext切换线程

withContext是协程中切换线程的核心工具。它不会创建新的协程，而是在当前协程的上下文中临时切换调度器，执行完指定代码块后自动切回来。

我个人习惯把withContext看作“线程切换的桥梁”。它比launch更轻量，因为不涉及协程的创建和销毁。

// withContext的标准用法
lifecycleScope.launch(Dispatchers.Main) {
    // 当前在Main线程
    
    val data = withContext(Dispatchers.IO) {
        // 切换到IO线程执行
        fetchDataFromNetwork()
    }
    
    // 自动切回Main线程
    textView.text = data
}

知识体系总览

下面这张图总结了本章的核心知识点。你可以把它当作速查表。

实战建议

说了这么多理论，最后给几条我在项目中沉淀下来的经验：

1. 默认用Main：在ViewModel或Activity里启动协程时，默认用Dispatchers.Main。需要切换时用withContext。
2. IO和Default别混用：虽然它们共享线程池，但语义不同。IO操作放IO，计算放Default，代码可读性更好。
3. 避免全局硬编码：不要把Dispatchers.Main硬编码在Repository层。通过构造函数注入调度器，方便单元测试时替换。
4. 慎用newSingleThreadContext：自定义单线程调度器看起来很美好，但容易造成线程泄漏。除非你有非常特殊的需求，否则用内置调度器就够了。

---

公众号:蓝海资料掘金营，微信deep3321