不能靠全局onBLECharacteristicValueChange监听多设备数据流，因其仅保留最后一个回调；应使用Map分发机制，为每设备特征值绑定独立处理器，并严格管理notify开关与生命周期。
不能靠全局 onBLECharacteristicValueChange 监听来管理多设备数据流——它只认最后一个注册的回调，前面的会被覆盖。
为什么全局监听在多设备场景下必然失效
UniApp 的蓝牙事件机制是单例设计：uni.onBLECharacteristicValueChange 只允许存在一个监听器。当你连接第二台设备并调用该 API 时，第一台设备的数据回调就被替换了。这不是 bug，而是底层平台（尤其是 iOS）对 BLE 通知通道的限制所导致的封装结果。
常见错误现象包括：
- 只收到最后连接设备的数据，其余设备“静音”
- 页面切换后数据突然中断，因为新组件又注册了一次监听，覆盖了旧的
- 断连重连后数据错乱，因未清理旧监听却重复注册
每个设备必须绑定独立的特征值监听器
正确做法是：为每台已连接设备的每个需要接收数据的 characteristicUUID，单独调用 uni.notifyBLECharacteristicValueChange 开启通知，并用闭包或 Map 存储其专属处理逻辑。
实操要点：
- 用
Map以deviceId + serviceUUID + characteristicUUID为 key，存对应的数据处理函数 - 调用
notifyBLECharacteristicValueChange时传state: true，且必须在uni.getBLEDeviceCharacteristics成功之后 - 务必在设备断开时调用
notifyBLECharacteristicValueChange({state: false, ...})关闭通知，否则 iOS 会卡死后续连接 - 不要在
onBLECharacteristicValueChange回调里做耗时操作（如 JSON 解析、网络请求），建议用postMessage或事件总线转发到 worker 处理
如何避免 onBLECharacteristicValueChange 被意外覆盖
核心原则：只注册一次全局监听，但让它变成“分发器”，而不是“处理器”。
示例结构：
let dataRouter = new Map()
uni.onBLECharacteristicValueChange((res) => {
const key = `${res.deviceId}-${res.serviceId}-${res.characteristicId}`
const handler = dataRouter.get(key)
if (handler && typeof handler === 'function') {
handler(res.value) // ArrayBuffer
}
})
// 连接设备后注册专属 handler
function registerDataHandler(deviceId, serviceId, charId, handler) {
dataRouter.set(`${deviceId}-${serviceId}-${charId}`, handler)
}
// 断开前清理
function unregisterDataHandler(deviceId, serviceId, charId) {
dataRouter.delete(`${deviceId}-${serviceId}-${charId}`)
}
注意：
- iOS 对
notifyBLECharacteristicValueChange的调用非常敏感，必须确保serviceId和characteristicId完全匹配getBLEDeviceCharacteristics返回的原始值（大小写、连字符都不能错） - 安卓部分机型（尤其低端机）在同时开启 >3 个 notify 通道时会出现延迟或丢包，建议加简单重试+心跳校验机制
- 不要把 handler 存在 Vue 实例 data 中——组件销毁时它还在 Map 里挂着，造成内存泄漏
多设备并发连接的实际瓶颈在哪
不是代码逻辑，而是系统资源调度：
- iOS 严格限制同时 active 的 BLE 连接数，通常为 6～8 个，超出后新连接会失败或旧连接被踢出
- 安卓各厂商差异大，华为/小米部分机型在后台时会主动冻结非前台 App 的 BLE 通知，需引导用户锁定应用后台
- 所有平台都不允许在
onHide后继续维持 notify，必须在onHide中统一关闭全部通知通道
真正容易被忽略的是：你写的“连接成功”逻辑，可能根本没等 notifyBLECharacteristicValueChange 返回 success 就开始发数据——这个 API 是异步的，iOS 上失败时不报错，只静默失败。务必加 success/fail 回调判断，失败时记录日志并重试。
