大家催了好久的 BLE 完整骨架下篇终于来了。上篇我把连接管理器的基本形态搭了出来设备扫描、连接、监听、断开回调都走通了。但如果你真拿那套代码跑到线上环境大概率会遇到两类让你头大的问题——莫名其妙断开、以及多线程竞争导致的 GATT 回调错乱。这次的下篇我重点把“稳定性”这三个字拆开来讲。这篇的核心是让连接管理器具备“自我修复”能力断线自动重连、操作串行化、请求合并去抖、生命周期绑定自动清理以及一套能在低内存手机上跑不崩的调度机制。虽然标题叫下篇但我会把依赖上篇的概念都重新解释一遍哪怕你还没看上篇直接读这篇也能跟上节奏。先说结论BLE 连接的稳定性从来不是靠玄学调参调出来的而是靠状态机约束状态流转、用队列把异步操作变成串行管道、再用退避策略消化掉偶发的不稳定因素。下面挨个展开。1. 稳定性的核心把“玄学”变成可控制的工程参数1.1 连接参数为什么不能随便填很多新手拿到 BLE 芯片的第一件事就是改ConnectionInterval、SupervisionTimeout以为和调路由器信道一样改大改小凭感觉。这个认知是错的。BLE 连接参数属于链路层约束你的 App 只能向上发起参数更新请求最终是否生效由对端设备决定。举个例子假设你设置请求参数为最小连接间隔 30ms、最大连接间隔 50ms、从机延迟 0、监控超时 4000ms。这段参数的实际含义是主机每 30 到 50 毫秒尝试和从机通讯一次如果 4 秒内没有任何有效通信链路就判死。问题在哪里如果对端设备是那种低功耗传感器固件里把最小间隔限制在 100ms你的 30ms 请求直接就被驳回然后你们就在一个不匹配的节奏下通信。我见过最离谱的一个案例是某开发者在连接后强行请求 7.5ms 间隔连发大数据包结果设备直接断开——因为从机的缓冲区只有几十字节连发导致缓冲区溢出底层直接丢弃连接。真正的稳定连接管理参数更新的策略应该是先用一个保守的默认值连接比如 100ms 间隔然后再在业务需要时按通道类型动态调整。上篇我给出过默认参数这里再补充一个我在产线设备上验证过多次的配置模板val defaultRequest BluetoothGattCharacteristic不对这段不完整正确的配置应该是通过BluetoothGatt#requestConnectionPriority以及BluetoothGattParameterUpdate相关 API 来发起。列一个实际能跑的配置类object BleConnectionConfig { const val MIN_INTERVAL_MS 30 // 最小连接间隔毫秒 const val MAX_INTERVAL_MS 60 // 最大连接间隔毫秒 const val SLAVE_LATENCY 0 // 从机延迟0 表示每次间隔都监听 const val SUPERVISION_TIMEOUT_MS 4000 const val MTU_SIZE 247 // MTU 大小Android 上请求 247 是常用值 }注意SUPERVISION_TIMEOUT_MS不是越大越好。确实调大它可以让链路不那么容易“误判死亡”但一旦设备真的走远或者信号被遮挡你需要等待更长时间才能确认断线重连的速度就慢了。我一般控制在 4~6 秒之间。1.2 连接优先级和掉线之间有什么关系Android 原生提供了三个连接优先级CONNECTION_PRIORITY_BALANCED、CONNECTION_PRIORITY_HIGH、CONNECTION_PRIORITY_LOW_POWER。很多人的理解是High 快Balanced 均衡LowPower 省电。但在稳定连接这个语境下优先级本质上是在告诉蓝牙协议栈怎么分配带宽和通讯时隙。我实测过两台不同厂家的手机结论是CONNECTION_PRIORITY_HIGH在部分手机上会显著降低回调丢包率但也导致耗电上升。如果你们的业务是长时间采集传感器数据比如在流水线上每秒钟读一次温湿度那 high 是必然选择如果只是后台推送个通知balanced 就够了。在连接管理器中我通常的做法是给连接器设计一个“优先级切换器”sealed class ConnectionPriority { object Balanced : ConnectionPriority() object High : ConnectionPriority() object LowPower : ConnectionPriority() } fun applyPriority(gatt: BluetoothGatt, priority: ConnectionPriority) { val code when (priority) { ConnectionPriority.Balanced - BluetoothGatt.CONNECTION_PRIORITY_BALANCED ConnectionPriority.High - BluetoothGatt.CONNECTION_PRIORITY_HIGH ConnectionPriority.LowPower - BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER } gatt.requestConnectionPriority(code) }这个类本身不复杂但用它的时机值得讲究。我是在完成服务发现之后才调用避免在连接刚建立的瞬间立刻调整优先级。底层协议栈在连接初期状态不稳定过早切换优先级会影响协商成功率。1.3 超时机制是稳定性最后的防线连接管理器我没用系统自带的默认超时因为 Android 的connectGatt超时行为在不同定制 ROM 上差异极大——有的 10 秒没连上才回调失败有的 3 秒就觉得不行了。这个不确定性必须通过管理器的看门狗来抹平。我自己实现了一个“看门狗”逻辑在发起连接时同时启动一个 8 秒的计时器。如果 8 秒内既没有onConnectionStateChange成功回调也没有onConnection相关回调有的国产手机厂商框架回调顺序混乱直接把这次连接尝试标记为超时并触发状态机的FAILED迁移。fun connectWithTimeout(address: String, timeoutMs: Long 8000) { watchdogJob scope.launch { delay(timeoutMs) if (!connectionConfirmed) { callback.onConnectionTimeout(address) closeGatt() } } gatt device.connectGatt(context, false, gattCallback) }这里有一个容易被忽略的细节closeGatt()调用之后系统会回调一次onConnectionStateChange状态是STATE_DISCONNECTED。如果你的状态机不先置一个TIMEOUT_WATCHDOG_TRIGGERED标志状态机就会误以为是一次正常的断线进而触发重连逻辑——这个 bug 极其隐蔽我踩过一次。后面的clear()顺序必须放在closeGatt()之前先把状态机锁死再让系统回调进来。2. Kotlin 状态机实现让每一次断线都有迹可循2.1 用 sealed class 建模连接生命周期上篇我用的状态机是接口加枚举的形式但说实话枚举在复杂状态迁移面前非常吃力。比如要在CONNECTED状态里区分“刚连上还没发现服务”和“服务发现完成可读写”枚举就得造两个名字。这个区分很关键因为很多国产外设固件在onServicesDiscovered之前不响应任何数据读写你在那个窗口期发数据大概率直接失败。我下篇重构后的状态机用 sealed classsealed class GattConnectionState { object Idle : GattConnectionState() object Connecting : GattConnectionState() object ServiceDiscovering : GattConnectionState() object Ready : GattConnectionState() data class Disconnected(val reason: DisconnectReason, val unexpected: Boolean) : GattConnectionState() object Reconnecting : GattConnectionState() } enum class DisconnectReason { USER_INITIATED, REMOTE_DEVICE_CLOSED, CONNECTION_TIMEOUT, PARAMETER_UPDATE_FAILED, LOCAL_RESOURCE_LIMIT, LINK_LOSS }把Disconnected做成带原因的 data class是这版最大的变化。原因字段可以让你在日志里回答那个经典问题“昨天半夜设备为什么掉了”——答案不能是“不知道”必须能追溯到DisconnectReason。每个状态迁移都要打印transition(old, new, cause)日志我建议把日志输出到本地文件因为蓝牙相关的系统日志在 release 版本里会被裁剪自己埋点才能真正拿到排查线索。2.2 全局状态迁移收敛为一个函数很多人的状态机写成“哪边触发哪边改”的方式比如onConnectionStateChange里将状态置为 ConnectedonCharacteristicWrite里再把状态改回 Ready。这样写早期可用但两个月后你根本想不起某些状态是哪里修改的调试起来想死。我的做法是在管理器里收敛一个transitionTo(target: GattConnectionState, cause: String)所有源码里的state 赋值都改成调用这个函数。刚开始会觉得很啰嗦但你可排查通过日志看到完整链路值private fun transitionTo( target: GattConnectionState, cause: String ) { val previous currentState if (previous target) return logTransition(previous, target, cause) currentState target }配合协程的MutableStateFlowUI 层可以这样订阅val state: StateFlowGattConnectionState _state.asStateFlow() // UI 中 viewModelScope.launch { manager.state.collect { state - // 根据状态决定页面文案 } }这里必须提醒一个坑不要在transitionTo里直接发回调给业务层应该让状态机只负责状态流转再通过一个独立 callback 去触发业务钩子。否则一旦回调里写了重连逻辑而重连又试图改状态状态机就会陷入递归——我一度把手机蓝牙搞崩过就是因为在回调里同步重连。2.3 断线重连和指数退避到底怎么设计上篇我把重连讲得比较粗只说“断了就重连”。但真实场景里无脑重连会引发“重连风暴”设备在电梯里信号差连一次失败触发重连重连又占用 CPU 和射频资源导致其他蓝牙设备也卡顿。我现在用的策略是前 3 次重连间隔固定 1 秒之后每次翻倍上限到 30 秒连续重连成功后会重置回 1 秒。看起来简单但要注意“重连计数清零”的时机——不能一重连成功就清零而应该等待设备稳定运行 30 秒以上再清零。这样能避免“连上又掉、掉完又连”的抖动场景下计数被反复重置导致退避策略失效。private var reconnectAttempt 0 fun scheduleReconnect() { val delay when { reconnectAttempt 3 - 1000L reconnectAttempt 6 - 2000L * (reconnectAttempt - 2) else - 30_000L } reconnectAttempt reconnectJob scope.launch { delay(delay) if (currentState is GattConnectionState.Disconnected) { performConnect(deviceAddress) } } }有一个细节退避时间间隔应该在后台线程delay不要阻塞主线程同时在匿名的重连过程中如果用户主动点击了“断开”要立刻取消reconnectJob。判断条件是用户主动断开后currentState必须是Disconnected(reason USER_INITIATED)且reconnectEnabled标志位置反。3. 指令队列避免多线程并发把 GATT 通道搞乱3.1 为什么系统回调顺序会乱掉Android 的BluetoothGatt回调严格来说都是从同一个 Binder 线程池回来的但多个请求同时发起时回调顺序并不一定能保证是先发先回。比如你连着发了三次writeCharacteristic对端设备的第一条数据返回慢第二条先到了回调顺序就出现了“乱序”。乱序的后果最典型的是数据被串包传感器 A 的读数被当成了传感器 B 的。在上上一篇的项目里我用一个简单 Map 去匹配onCharacteristicChanged的 UUID但当同一特征同时被多处订阅时回调还是偶发错乱。解决思路其实很朴素把 GATT 的所有操作都放进一个串行队列一次只发一个操作第一个操作的回调完成后再发下一个。你可能觉得这样让操作变慢了但实际上 BLE 单连接的本质本来就是一个“半双工串行通道”你并发发出去也不会更快反而会触发底层缓冲区溢出。3.2 队列的优先级设计纯 FIFO 队列在复杂业务里不够用。比如连接刚建立后在 READY 状态前需要做一系列初始化操作MTU 协商、服务发现、特征订阅。这中间如果混入一个业务方的读操作它不该插队但也得有路径等初始化结束后执行。我采用了两级队列高优先级队列用于初始化、订阅、参数更新操作普通队列用于业务读写。每次从高优先级队列取一个操作执行如果高优先级队列为空再从普通队列里取。实现上我就用两个Channelprivate val highPriorityQueue ChannelGattOperation(Channel.UNLIMITED) private val normalPriorityQueue ChannelGattOperation(Channel.UNLIMITED) private fun enqueue(op: GattOperation, highPriority: Boolean) { val target if (highPriority) highPriorityQueue else normalPriorityQueue if (!target.trySend(op).isSuccess) { // 队列满了返回失败并记录日志 op.fail(OperationException.QueueFullException) } }执行端是一个单协程消费者fun processGattQueue() scope.launch(Dispatchers.IO) { while (isActive) { // 先取高优再取普通 val op selectGattOperation { highPriorityQueue.onReceive { it } normalPriorityQueue.onReceive { it } } executeOperation(op) } }select这个写法我调过坑两个通道同时有数据时select是随机选择其中一个并不保证优先高优。如果要在 Kotlin 里严格优先不能这么写必须用两个poll轮询fun processGattQueue() scope.launch(Dispatchers.IO) { while (isActive) { if (flushQueue(highPriorityQueue)) continue if (flushQueue(normalPriorityQueue)) continue delay(5) } } suspend fun flushQueue(queue: ChannelGattOperation): Boolean { var handled false while (isActive) { val op queue.tryReceive().getOrNull() ?: break executeOperation(op) handled true } return handled }别笑这段代码是我在生产项目里真实运行过的版本。它能保证高优先级操作在多个普通操作之间得到先执行的机会又不会因为某个操作永久阻塞而饿死普通队列。3.3 超时任务怎么退出队列队列里有个常见死法一个writeCharacteristic发出去对端设备没任何反应写操作既不回调成功也不回调失败你的队列就一直卡在这里后面的操作全部停摆。必须给每个出队操作配备“超时炸弹”。我实现的方案是给GattOperation加一个内置的timeoutHandlerclass GattOperation( val type: OperationType, val characteristic: BluetoothGattCharacteristic?, val payload: ByteArray?, val timeoutMs: Long 5000 ) { private var isFinished false private lateinit var onFinished: (ResultByteArray) - Unit fun start(callback: (ResultByteArray) - Unit) { onFinished callback // 启动超时检测 // 操作完成时调用 finish超时时调用 fail(TIMEOUT) } }每次执行操作时根据操作类型设置不同的超时时间readCharacteristic我设 3 秒writeCharacteristic设 5 秒requestMtu设 4 秒。超时后直接给业务层返回失败然后队列继续执行下一个操作。但是需要注意一个坑超时之后底层 GATT 如果又返回了一个迟到的回调你可能还会收到一次重复数据。所以要在GattOperation里加一个isFinished判断无论回调先到还是超时先到只处理一次。4. 生命周期与连接存储没有清理机制的重连都是耍流氓4.1 绑定生命周期自动断开连接管理器如果只做“连接”和“断开”那只是工具类要做成“管理器”必须有生命周期感知能力。否则用户在聊天页面连接了一个耳机然后关掉这个页面连接还悬在那里既不销毁也不可见内存和蓝牙资源都被白白占用。我参考 Android 的Lifecycle机制在管理器内部注册了一个DefaultLifecycleObserverclass BleConnectionManager( private val lifecycle: Lifecycle ) : DefaultLifecycleObserver { init { lifecycle.addObserver(this) } override fun onStop(owner: LifecycleOwner) { // 页面不可见时如果连接业务是前台相关可以选择断开 if (config.disconnectOnStop) { disconnect(DisconnectReason.USER_INITIATED) } } override fun onDestroy(owner: LifecycleOwner) { releaseAll() } }这里有两个策略分歧点有些业务希望 App 从前台退到后台时仍然保持连接比如运动手表上传心率有些业务则希望在页面销毁后立刻释放连接比如配置类设备。我建议把策略放在BleConnectionConfig里不要写死在管理器里。默认值给false全由接入方决定。4.2 后台连接必须配合前台服务安卓系统从 8.0 开始对后台 App 获取定位信息做了限制而 BLE 扫描的结果依赖定位权限从 10 开始对后台扫描的分区限制更严格。如果你的 App 需要在后台维持 BLE 连接并持续扫描周边设备唯一的合规做法是启动一个前台服务带上FOREGROUND_SERVICE_CONNECTED_DEVICE类型。代码逻辑是这样的当管理器收到“需要后台运行”的信号时自动拉起服务当所有设备都断开且没有重连需求时关闭服务。这个钩子一定要和状态机联动不能在 Activity 的onDestroy里简单启动服务否则服务和 Activity 生命周期就解耦了。fun startBackgroundServiceIfNeeded() { if (connectedDeviceCount 0 || reconnectEnabled) { context.startForegroundService(Intent(context, BleForegroundService::class.java)) } }提醒一句运行前台服务的同时必须定期向通知栏发一条通知。Android 13 之后你可以不展示通知内容但不能不保留通知通道。连接管理器里被拒的崩溃场景有一大半是因为忘记在onStartCommand里startForeground。5. 常见问题排查实录那些线上才能遇见的离奇 BUG5.1 回调不下发到底谁吃掉了回调我排查过一个印象极深的案例。某厂商的手环在 App 退到后台再回来之后第一次读电量必超时。日志显示连接状态正常、MTU 协商成功但onCharacteristicRead就是不来。后来发现是 Android 系统蓝牙栈在 App 退后台时把BluetoothGatt对应的进程优先级降低了底层调度出现问题导致回调线程一直拿不到 CPU。问题最终的解法既不是改超时也不是改重连而是在onResume里重新调用一次bluetoothGatt.readCharacteristic把底层的回调通道“唤醒”。这类问题在纯代码层面很难直接推理出来经验是凡是涉及“后台回来之后第一次操作异常”优先检查底层回调是否被系统休眠调度干扰必要时用“多读一次”这类补偿手段。5.2 断线重连后之前订阅的特征全部丢失这是连接管理器的经典细节坑。iOS 的 CoreBluetooth 会在重连后自动恢复之前订阅的特征但 Android 不会。你在 onConnectionStateChange 里看见STATE_CONNECTED后必须重新discoverServices()然后逐个setCharacteristicNotification()。很多人的代码只在首次连接时调用订阅重连后设备看起来连上了却怎么都收不到数据白白排查几天。我的建议是把“连接成功后需要的初始化序列”封装成一个InitializationSequence无论是首次连接还是断线重连都走同一个序列。suspend fun initializeGatt(gatt: BluetoothGatt) { gatt.requestMtu(247) gatt.discoverServices() // 等服务发现完成后再依次订阅特征 targetCharacteristics.forEach { gatt.setCharacteristicNotification(it, true) // 部分设备还需要绑定 CCCD 描述符写 0x01 it.getDescriptor(ClientCharacteristicConfigUuid)?.let { desc - desc.value BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE gatt.writeDescriptor(desc) } } }注意上面这段代码在实际执行时每个操作之间必须等异步回调完成不能连续调用否则又触发了我们前面说的并发问题。要结合第三节的队列机制来写。5.3 手机蓝牙被系统回收GATT 实例变成僵死状态长期运行的连接管理器偶尔会出现BluetoothGatt对象引用了但底层已经失效的情况。最明显的现象是isConnected返回 true但任何写操作都不回调。这种状态没有系统回调提示所以必须在管理器里加一个“心跳”机制。我的做法是如果设备支持通过某个特征读取一个无副作用的数据比如固件版本号则以 30 秒为周期做一次轻读取读取失败的次数连续累积到 3 次就把连接标记为异常主动断开并触发重连。这个方案虽然会增加一点电量消耗但比“假死”要好得多。注意选择心跳特征时不要选那个会触发写 Flash 的特征否则你的设备寿命会大打折扣。6. 如何把这份骨架用到你的项目里如果你的项目是从零开始接入这份骨架我建议按三步走先用默认配置把连接管理器裸跑起来只测“连接-断开-重连”的基础循环不接业务特征然后接入指令队列把现有所有读写操作改到队列上最后再接入生命周期和后台服务逻辑。三步之间有明确的验证节点不要一口气全改。我在多个厂前项目里用到的配置大概是这样配置项推荐值原因连接超时8 秒兼顾体验和重连速度请求 MTU247Android 9 以上普遍支持重连退避1s-2s-4s-最大30s避免重连风暴写特征超时5 秒超过说明链路异常心跳间隔30 秒平衡耗电和假死发现服务发现超时6 秒防止设备响应慢导致卡死这个表格不是让你照搬而是一个参考基线。每类设备都要实测尤其是那些小厂芯片的设备它们的响应时间差异极大。你在模拟器上测出来的完美参数拿到真机上可能完全不是那么回事。最后分享一个我从踩坑里总结出来的习惯不论连接管理器写得多完善一定要在应用内为蓝牙操作埋点至少记录下“发起操作时间、成功/失败、耗时、错误码”这四样。所有稳定性优化都依赖数据没有埋点做出的优化都是拍脑袋。如果你也想在你的项目里落地这套骨架可以先在 debug 版本里把状态机日志打开跑三天你会发现很多之前“觉得是偶发”的问题其实都有明确的触发规律。
