协程在回调中的应用：为什么在GATT回调中使用协程？优势与风险
说到 GATT 回调，搞过蓝牙开发的朋友应该都熟悉。onCharacteristicChanged、onConnectionStateChange…… 这些回调函数就像一个个通知，告诉你蓝牙对面发生了什么。但问题来了 —— 回调里经常需要做耗时操作，比如写数据库、解析大数据包、或者发起下一个蓝牙请求。
传统做法是在回调里开线程或者丢到 Handler 里。线程管理一乱，代码就变成「回调地狱」。我早期做一个运动手环项目，光一个 onCharacteristicChanged 里面就套了四层回调，调试时自己都看晕了。
后来我们开始用协程。协程这玩意儿说白了就是「轻量级线程」，让异步代码看起来像同步一样。但你想想看，GATT 回调本身是在 Binder 线程池里执行的，你在这个线程里直接调协程，稍不注意就会出问题。我在另一款智能穿戴项目里，就因为这个泄漏搞崩过好几个测试机。
这一节，我跟你聊聊协程在 GATT 回调中的优势，以及背后藏着的风险。
为什么需要在 GATT 回调中使用协程？
先看看传统 GATT 回调的痛点：
- 回调嵌套：一个回调里又发起另一个蓝牙操作，再等回调，层层嵌套。
- 线程切换麻烦：回调在 Binder 线程，UI 更新必须切回主线程，容易忘。
- 异常处理难：回调里 try-catch 只能包一小块，跨回调的异常很难统一处理。
- 生命周期耦合：回调触发时 Activity 可能已经 onDestroy，直接更新 UI 就 Crash。
协程恰好能解决这些问题。用协程你可以把一串异步操作写成一个顺序的 suspend 函数，异常用标准 try-catch 搞定，线程切换用 withContext 清晰指定。而且协程可以绑定到 ViewModel 或 Activity 的 lifecycleScope，自动取消，省心很多。
核心优势对比
| 维度 | 传统回调 | 协程 |
|---|---|---|
| 代码结构 | 嵌套层级深，可读性差 | 顺序编写，如同步代码 |
| 线程切换 | 手动 post 到 Handler | withContext(Dispatchers.Main) 一行搞定 |
| 异常处理 | 每个回调单独 try-catch | 统一 catch，甚至用 CoroutineExceptionHandler |
| 生命周期管理 | 手动检查 isActive 或取消注册 | 绑定 lifecycleScope / viewModelScope 自动取消 |
| 测试难度 | 难模拟异步时序 | 可以用 runBlockingTest 控制协程 |
我个人习惯在 onCharacteristicChanged 里直接启动一个协程，把数据解析、状态更新、甚至是发下一个蓝牙指令全部串起来。写起来很舒服，像在写单线程程序。
具体怎么用？一个代码例子
假设你有一个蓝牙服务，收到心率数据后要更新 UI 并记录日志：
// GATT 回调
override fun onCharacteristicChanged(
gatt: BluetoothGatt,
characteristic: BluetoothGattCharacteristic
) {
// 注意：这个回调在 Binder 线程
val value = characteristic.value
// 启动协程，绑定到 ViewModel 的 scope
viewModelScope.launch {
// 切到 IO 线程解析数据
val heartRate = withContext(Dispatchers.IO) {
parseHeartRate(value) // suspend 函数，可能解析耗时
}
// 自动回到主线程更新 UI
_heartRateLiveData.value = heartRate
// 再异步记录日志
withContext(Dispatchers.IO) {
logToFile(heartRate)
}
}
}看到没？不用再手动切 Handler，不用 try-catch 来回绕。协程帮你把 Binder 线程 -> IO 线程 -> Main 线程的切换全包了。而且 viewModelScope 会在 ViewModel 清除时自动取消，不会泄漏。
但别高兴太早。我刚才用的是 viewModelScope，如果这个 GATT 回调不在 ViewModel 里呢？比如一个全局的 BluetoothManager 单例？那麻烦就来了。
风险：协程泄漏是怎么发生的？
协程泄漏，说白了就是你启动了一个协程，但它的对应 scope 没人管了。协程还在默默跑，持有了一些对象的引用，导致内存无法释放。
GATT 回调里最容易踩的坑有两个：
- 用了 GlobalScope：GlobalScope.launch 启动的协程没有生命周期，永远不取消。你想想看，App 切到后台再回来，蓝牙数据一多，协程数量只增不减，内存天花板迟早被捅破。
- 把 scope 绑定在生命周期不明确的回调对象上：比如你在 BluetoothGattCallback 内部定义了一个 CoroutineScope，但 Activity 已经 finish 了，这个 scope 依然活着，因为 Gatt 回调对象还被系统持有。协程里的回调 lambda 隐式捕获了 Activity 的引用，泄漏就发生了。
我在一个项目中就遇到过这个事。当时为了方便，直接在 BluetoothGattCallback 里写了个 CoroutineScope(Dispatchers.IO + SupervisorJob())。结果用户在页面之间快速切换，蓝牙反复连接断开，协程没取消，每个协程都持有一个旧的 Activity 引用。最后 OOM 了。排查了半天才找到根因。
避坑指南
我曾经以为只要不在 GlobalScope 里启动协程就安全了。错！任何没有绑定到明确生命周期的 CoroutineScope 都有可能泄漏。GATT 回调是长生命周期的，Activity 或 Fragment 是短生命周期的。你必须保证协程 scope 的生命周期 <= 你关心的组件生命周期。
我现在的做法是：不在 GATT 回调里自己维护 scope。要么传入外部传入的 scope（比如 Activity 的 lifecycleScope），要么用 callbackFlow 把回调转为 Flow，再在 UI 层 collect。这样 scope 的归属权很清晰。
优势与风险总结
用一张图来理清思路：
这张图展示了关键的分叉点。你只要把协程 scope 绑定到正确的生命周期源头上，就能享受协程带来的所有好处，同时避免泄漏。我个人强烈建议：不要自己创建 Scope，尽量接收外部传入的 Scope。
实践建议
- 用 callbackFlow 把 GATT 回调转为 Flow：这样可以在 collect 的协程里自动管理取消，代码也更函数式。
- 如果必须自己创建 Scope，一定在 onDestroy 或 onDisconnected 里手动 cancel。比如在 BluetoothGattCallback 内部维护一个 Job，在断开连接时取消它。
- 警惕协程的「隐式捕获」：suspend lambda 会捕获它引用的外部变量。如果你在协程体里用了 Activity 的成员变量，即使 Activity 被销毁，只要协程没取消，Activity 就一直被持有。
一个小技巧
用 Android Studio 的「LeakCanary」可以帮你检测协程泄漏。但更直接的方法是：在 Debug 版本里给每个 scope 添加一个 name，然后在 dump 线程栈时找出那些「本该取消却没取消」的协程。我习惯在 launch 时打日志：log("Co launched from onCharChanged, activity hash=${this.hashCode()}")，方便追踪。
好，总结一下。协程在 GATT 回调里确实能大大简化代码，但风险在于生命周期错配。你只要记住：谁造谁负责，谁的 scope 谁管理。不要偷懒用 GlobalScope，也不要让匿名协程「漂浮」在长生命周期回调里。把这根弦绷紧了，协程就是你蓝牙开发的神兵利器。