背景：蓝牙通信中常见的内存泄漏与资源泄漏

我记得刚接手公司第一个蓝牙项目时，产品经理天天盯着我测连接稳定性。结果倒好，连接倒是没断，手机先卡死了。一查日志——好家伙，内存泄漏了十几个 Gatt 对象，一个都没释放。

其实蓝牙泄漏是个老生常谈的问题。说白了，就是「开了没关」的经典翻版。你想想看，蓝牙通信涉及多个层次——系统级、应用级、协程级——每一层都可能埋着泄漏的雷。

泄漏的两大类型

这两种泄漏在蓝牙场景下往往如影随形。内存泄漏会拖垮 App，资源泄漏则直接破坏蓝牙通信链路。我自己就踩过一个坑——一个 Flow 数据流挂在 Activity 上没取消，结果协程一直持有 BluetoothGatt 的引用，Activity 销毁后 Gatt 对象还活着，下一轮连接直接报错「GATT already connected」。

蓝牙通信中的经典泄漏场景

来，我列几个实战中最常见的场景。这些都是我在不同项目里亲手修过的 bug。

1. BluetoothGatt 未关闭 —— 每次调用 connectGatt() 都会创建一个 Gatt 对象。如果你忘记调用 close()，系统内部会保留一个蓝牙进程的引用，导致同一个设备再也连不上。
2. 广播接收器未注销 —— 注册了 BluetoothDevice.ACTION_FOUND 或 BluetoothAdapter.ACTION_STATE_CHANGED，但 Activity 或 Service 销毁时没调 unregisterReceiver()。你会收到一个指向已销毁组件的空引用。
3. 协程作用域未取消 —— 用 viewModelScope 或 lifecycleScope 还好，但如果你自己创建了 CoroutineScope 并传入蓝牙回调，Activity 销毁后协程还在跑，持有外部引用。
4. Flow 数据流未取消收集 —— 这个是我们课程的核心。用 callbackFlow 包装蓝牙通知时，没有在 awaitClose 里释放资源，导致协程和 Gatt 互相引用，泄漏。
5. 观察者/回调列表未清空 —— 自定义了一个 BluetoothCallback 列表，在连接时把 Activity 的匿名回调加进去，断开时却忘了 remove。Activity 被强引用持有。

为什么协程和 Flow 会加剧泄漏？

嗯，这里要讲重点了。传统的 Callback 写法虽然烦，但至少是显式注册和注销。协程和 Flow 来的太「自动」了，容易让人忘掉取消。

举个具体例子。你写了一个这样的 Flow 来监听蓝牙通知：

fun observeNotifications(device: BluetoothDevice): Flow<ByteArray> = callbackFlow {
    val gatt = device.connectGatt(context, false, object : BluetoothGattCallback() {
        override fun onCharacteristicChanged(
            gatt: BluetoothGatt, characteristic: BluetoothCharacteristic
        ) {
            trySend(characteristic.value)
        }
    })
    gatt.setCharacteristicNotification(someChar, true)
    // 注意：这里没有 awaitClose
}

这段代码看起来没什么问题，对吧？但实际上 gatt 被匿名内部类 BluetoothGattCallback 强引用持有，而 callbackFlow 建立的协程又持有了 gatt。如果 Flow 的收集在某个生命周期结束后被取消，但协程没走到 cancel() 分支，那 gatt 永远不会 close()。