Kotlin 中将回调方法转换为协程

1. 概述

异步编程在构建响应迅速且高效的现代应用中至关重要。长期以来，Java 开发者依赖回调（Callback）来处理异步操作。

然而，在 Kotlin 的生态中，协程（Coroutines）已成为首选方案。相比回调，协程能以更简洁、直观的方式组织异步逻辑，显著提升代码可读性与维护性。本文将深入讲解如何将传统的回调方法迁移为协程实现，帮助你在项目中更好地发挥协程的优势，写出更清晰、更易维护的代码。

✅ 踩坑提示：回调地狱（Callback Hell）是真实存在的痛点，尤其是在嵌套多个异步任务或复杂错误处理时，代码会迅速变得难以追踪和调试。

2. 回调 vs 协程

在进入转换实践前，我们先简要回顾两者的本质差异。

2.1. 回调机制

回调本质上是作为参数传递的函数，用于在异步任务完成时接收结果或错误。当操作结束，系统会触发对应的回调函数，并传入数据或异常。

典型的回调风格代码如下：

interface Callback {
    fun onSuccess(result: String)
    fun onFailure(error: Throwable)
}

fun fetchData(callback: Callback) {
    // 模拟异步操作
    Thread {
        try {
            // 执行耗时任务
            val processedData = processData()
            callback.onSuccess(processedData)
        } catch (e: Exception) {
            callback.onFailure(e)
        }
    }.start()
}

fun processData(): String {
    Thread.sleep(1000)
    return "processed-data"
}

✅ 上述示例中：

定义了 Callback 接口，包含成功与失败两个回调方法。
fetchData() 启动子线程执行任务，完成后通过回调通知调用方。

⚠️ 问题在于：随着异步链路增长，回调嵌套会导致“回调金字塔”，逻辑分散，异常处理混乱，极易出错。

2.2. 协程机制

Kotlin 协程提供了一种更现代化的异步编程模型。它允许你以近乎同步的写法处理异步任务，代码结构更线性、更直观。

以下是等效功能的协程实现：

suspend fun fetchData(): String {
    // 模拟异步操作
    return processData()
}

suspend fun processData(): String = withContext(Dispatchers.IO) {
    // 模拟耗时操作
    delay(1000)
    return@withContext "processed-data"
}

✅ 特点：

使用 suspend 关键字标记挂起函数。
delay() 是非阻塞式等待，不会锁死线程。
无需手动管理线程切换，借助 withContext 可轻松指定执行上下文。

3. 将回调转换为协程

接下来是核心部分——如何一步步将现有回调 API 改造成协程友好型接口。

3.1. 识别目标回调函数

第一步是定位需要改造的回调函数。重点关注以下几点：

函数是否发起异步操作？
是否接受一个包含 onSuccess / onFailure 的回调对象？
返回类型是否为 Unit（即无直接返回值）？

一旦确认，就可以着手封装成 suspend 函数。

3.2. 使用 suspendCoroutine 封装为挂起函数

**关键工具是 suspendCoroutine 或 suspendCancellableCoroutine**，它们可以桥接回调与协程之间的鸿沟。

原理很简单：
在 suspendCoroutine 块内调用原始的回调函数，并通过 continuation.resume() 或 resumeWithException() 来恢复协程执行。

来看具体实现：

suspend fun fetchDataWithCoroutine(): String = suspendCoroutine { continuation ->
    val callback = createCallbackWithContinuation(
        onSuccess = continuation::resume,
        onFailure = continuation::resumeWithException
    )
    
    fetchDataWithCallback(callback)
}

fun createCallbackWithContinuation(
    onSuccess: (String) -> Unit,
    onFailure: (Throwable) -> Unit
) = object : Callback {
    override fun onSuccess(result: String) = onSuccess(result)
    override fun onFailure(error: Throwable) = onFailure(error)
}

✅ 核心要点：

suspendCoroutine 接收一个 lambda，其参数 continuation 表示当前协程的“续体”。
当回调被触发时，通过 resume 把结果送回协程；出错则用 resumeWithException 抛出异常。
调用方不再需要实现接口，而是像调用普通函数一样获取返回值。

⚠️ 若需支持协程取消（Cancellation），应优先使用 suspendCancellableCoroutine。它会在协程被取消时自动触发回调清理，避免资源泄漏。

3.3. 更新调用端代码

函数升级为 suspend 后，调用方式也需相应调整。必须在协程作用域内调用挂起函数。

对比来看更直观：

❌ 旧式回调调用

fun main() {
    val callback = object : Callback {
        override fun onSuccess(result: String) {
            println("Success: $result")
        }

        override fun onFailure(error: Throwable) {
            println("Error: ${error.message}")
        }
    }

    fetchData(callback)
}

✅ 新式协程调用

fun main() {
    val exceptionHandler = CoroutineExceptionHandler { _, throwable ->
        println("Caught exception: ${throwable.message}")
    }

    GlobalScope.launch(exceptionHandler) {
        try {
            val result = fetchDataWithCoroutine()
            println("Success: $result")
        } catch (e: Throwable) {
            // 可选：这里也可以捕获，取决于异常处理器设置
        }
    }

    // 阻塞主线程以便观察输出（仅用于演示）
    Thread.sleep(2000)
}

✅ 显著优势：

业务逻辑集中，无需拆分到多个回调方法。
异常可通过 try/catch 统一处理，符合直觉。
多个异步调用可顺序书写，避免嵌套。

💡 实际项目建议避免使用 GlobalScope，推荐结合 ViewModel、Lifecycle 或自定义 CoroutineScope 使用，防止内存泄漏。

4. 总结

本文系统介绍了如何将 Kotlin 中的回调模式迁移至协程模型。我们分析了回调的局限性，展示了协程带来的代码简洁性与可维护性提升，并通过 suspendCoroutine 成功实现了平滑过渡。

关键收获：

✅ 使用 suspendCoroutine 可无缝桥接旧回调 API。
✅ 挂起函数让异步代码看起来像同步，大幅提升可读性。
✅ 调用侧统一使用 try/catch 处理异常，逻辑更清晰。

📦 示例代码已托管至 GitHub：https://github.com/baeldung/kotlin-tutorials/tree/master/core-kotlin-modules/core-kotlin-advanced-2
建议集合，遇到类似改造需求时可直接参考。

Persistence

REST

Security