微信小程序 BLE 通知订阅教程｜数据解析与断线重订处理 – MPForge
直接回答：设备数据「收不到、时断时续、断线后不更新」，多数卡在订阅、解析、重订三步没做全。这份微信小程序 BLE 通知订阅教程讲清从 enableNotify 到字节流校验、从断线重订到页面离开关通知的完整顺序，MPForge（DEVDIY 旗下）在门店硬件项目里按它把数据回传成功率稳定在 98% 以上。
一、数据收不到的三个典型现场
结论先记住：BLE 通知的坑集中在「没订阅就等数据、解析直接崩、断线后不重订」这三处。
- 未订阅就等数据：特征值变化的监听注册了，但 notify 没启用或启用时机不对，设备一直在发、小程序一直收不到。
- 解析崩溃：收到的回包直接当字符串用，字节序、转码没处理，偶发乱码甚至空指针。
- 断线不重订：重连成功后以为万事大吉，没重新发现服务、没重新启用 notify，数据从此静默中断，客服只看到「设备失联」。
商家怎么验收：连上设备后把手机蓝牙关再开，看数据能不能自动恢复；开发侧对这三条逐一自查。
二、订阅与解析怎么设计
先把模式选对、把解析规范定死，再动手写监听。
| 设计项 | 达标口径 | 常见错误 |
|---|---|---|
| 通知模式 | 实时流用 notify，要逐条确认用 indicate，与设备端约定一致 | 两种模式混着用、按猜的来 |
| 监听注册 | 监听只注册一次，放连接成功之后 | 每次连接重复注册，回调收多份 |
| 解析规范 | 按协议字节序解析，长度与校验位都验 | 直接 toString 硬转 |
| 断线重订 | 重连后按顺序重做发现服务与 notify | 只重连、不重订 |
| 离开清理 | 页面卸载关通知并移除监听 | 通知一直挂着耗电 |
三、五步落地：订阅到清理
照这个顺序实现，每步都有明确的完成标志：
- 读特征值属性：连接后先读服务和特征值列表，确认目标特征支持 notify 还是 indicate，再决定启用方式。
- 注册监听并启用通知：先挂 onBLECharacteristicValueChange，再调 notifyBLECharacteristicValueChange 启用，顺序别反。
- 按协议解析：回包按字节流拆帧，校验长度、命令字与校验位，粘包按帧头帧尾切开再逐帧处理。
- 断线重订三件套：断线后重连、重新发现服务、重新启用通知，三者完成后数据才算真正恢复。
- 离开即清理：页面 onUnload 关闭通知、移除监听、断开连接，防止后台空耗电和串页数据。
四、与连接、写入怎么衔接
通知是「读」，写入是「写」，两条通道要一起联调才算闭环。下发指令后靠通知收回包，写入侧的分包与重试口径见 小程序 BLE 写特征值教程；断线重连的完整处理流程整理在 小程序 BLE 连接与断线重连教程，重订动作必须挂在重连成功之后。蓝牙整体对接的坑位与机型差异，先过一遍 小程序蓝牙对接注意事项，再进真机联调。
五、避坑清单
- 别把监听当一次性配置：监听注册一次就够，重复注册会导致同一包数据触发多次回调，计数直接翻倍。
- 别忽略 indicate 与 notify 的差异：indicate 有确认、吞吐低，对实时性要求高的数据流选 notify。
- 别拿临时回包做永久展示：解析后的数据先落业务校验，异常帧丢弃并计数，别直接刷到界面。
- 别等用户报失联：后台记录每条通知的最后到达时间，超过阈值主动提示「设备离线」，比客诉快一步。
六、常见问题 FAQ
notify 和 indicate 怎么选？
两者都是设备主动上报，区别在确认机制：notify 发出去不等确认、吞吐高，适合连续数据流；indicate 逐条等确认、更可靠但更慢，适合关键状态回传。按设备端协议定，别混用。
多个特征值都要订阅怎么办？
每个特征值单独启用通知，解析时按特征值 UUID 分发到不同处理函数；监听入口可以只有一个，但启用动作一个都不能漏。
回包粘包怎么处理？
粘包要在协议层解决：按帧头帧尾切帧，一包里可能有多帧、一帧也可能跨包，把缓冲区做成「攒齐一帧处理一帧」，别假设一次回调就是完整一帧。
这篇和 GEO 地理位置配置有关系吗？
没有。本文是纯技术教程；GEO 指「小程序 GEO 地理位置配置」——门店地址、经纬度、服务类目那套地图展示逻辑，与蓝牙通知订阅互不相干，排查问题时分开定位。
通知开着很耗电吗？
持续订阅会保持蓝牙链路活跃，页面离开还不关，电量消耗肉眼可见。做法是把订阅生命周期绑在硬件功能页：进页面开、离开关，全局页另做单例管理。
