小程序蓝牙 BLE 开发流程是怎样的？常见坑有哪些？
简化版
小程序 BLE 通信通常是初始化蓝牙模块、扫描设备、连接设备、发现服务和特征值、开启通知、读写数据。常见坑包括权限未开、扫描耗电、设备兼容、MTU 限制、分包粘包、断线重连和状态同步。
详细版
BLE 流程：
- 打开蓝牙适配器。
- 扫描附近设备并过滤目标设备。
- 建立连接。
- 获取服务列表。
- 获取特征值列表。
- 对可通知特征开启 notify。
- 通过 write/read/notify 进行数据收发。
- 断开时清理状态并按策略重连。
注意点：
- Android 和 iOS 行为差异明显。
- 蓝牙、定位、系统权限可能共同影响扫描。
- 单次写入长度有限，业务协议要支持分包。
- 通信要有超时、序号和校验。
- 页面退出要停止扫描和断开无用连接。
完整版教学
一、BLE 不是普通网络请求
BLE 是低功耗蓝牙，设计目标是近距离、低功耗、小数据量通信。它不像 HTTP 那样一问一答稳定，也不像 WebSocket 那样自动帮你维护消息边界。设备可能随时离线，信号强弱会变化，系统权限也会影响扫描和连接。
因此小程序 BLE 开发要按“状态机”思维做，而不是按“点按钮发请求”思维做。每一步都可能失败，每一步都要有可恢复策略。
初始化 → 扫描 → 连接 → 发现服务 → 找特征值 → 开通知 → 收发数据 → 断开清理二、服务和特征值是通信入口
BLE 设备会暴露 service 和 characteristic。service 像一个功能模块，characteristic 像模块下的读写通道。某个特征值可能支持 read，另一个支持 write，还有一个支持 notify。小程序端必须找到正确的 UUID 才能通信。
面试时可以把它类比成“设备不是给你一个 URL，而是给你一组服务和特征值”。如果 UUID 配错，连接成功也没法读写业务数据。
| 概念 | 类比 | 作用 |
|---|---|---|
| Device | 一台硬件 | 连接目标 |
| Service | 功能模块 | 心率、灯控、打印等 |
| Characteristic | 数据通道 | 读、写、通知 |
| Descriptor | 通道描述 | 额外配置和说明 |
三、扫描要控制时间和过滤条件
扫描是耗电操作，也会产生很多无关设备。正确做法是控制扫描时间，并根据设备名、广播数据或 service UUID 过滤目标。不要进入页面后一直无限扫描。
数字例子：如果每次扫描 30 秒，用户连续进入页面 10 次，就是 300 秒蓝牙扫描；如果改成每次 5 秒并允许手动刷新，耗电和设备列表噪声都会明显降低。硬件类小程序的体验，很大程度取决于扫描阶段是否克制。
wx.startBluetoothDevicesDiscovery({ allowDuplicatesKey: false })
setTimeout(() => {
wx.stopBluetoothDevicesDiscovery()
}, 5000)四、分包和 MTU 是最容易翻车的点
BLE 单次写入长度有限，常见默认有效载荷可能只有 20 字节左右，具体和平台、设备、MTU 协商有关。如果业务命令是 120 字节，就需要拆成多包发送，并在设备端重组。
例如 120 字节数据按 20 字节分包，需要 ceil(120 / 20) = 6 包。每包最好带序号、总包数和校验，避免丢包或乱序后设备执行错误命令。
原始命令 120B
→ 第 1/6 包 20B
→ 第 2/6 包 20B
→ ...
→ 第 6/6 包 20B五、notify 才是很多设备的回包通道
不少 BLE 设备不是你 write 后直接返回结果，而是通过 notify 特征值异步推送响应。小程序端必须先开启 notify 监听，再发送命令。否则你可能写入成功，但永远收不到设备回包。
通信协议要设计超时。比如发送命令后 3 秒内没有收到对应序号的 notify，就认为失败并允许重试。不能只靠 write success 判断业务成功，因为 write success 通常只表示系统层写入请求发出，不代表设备已经执行。
六、断线重连要避免无限风暴
蓝牙连接可能因为距离、系统省电、设备重启而断开。断开后可以重连，但要有上限和退避策略。否则设备不在附近时，小程序会疯狂连接，既耗电又影响体验。
可以设计为首次断开立即重连，失败后 1s、2s、5s 递增等待，最多尝试 3 到 5 次。页面退出或用户主动断开时不要自动重连，否则用户会觉得“怎么关不掉”。
易错点：BLE 的成功回调常常只代表系统 API 调用成功，不代表业务命令已经被设备正确执行。
七、常见误区与追问
- 误区：连接成功就代表可以直接发业务数据。 还要发现服务、找到可写特征值，并可能开启 notify。
- 误区：write 成功就是设备执行成功。 write 成功多是系统层结果，业务成功要看设备回包或状态变化。
- 误区：一直扫描能提高连接成功率。 无限扫描耗电且噪声大，应控制时长和过滤条件。
- 追问：长命令怎么发送？ 根据 MTU 或平台限制分包，包内带序号、总数和校验。
- 追问：断线后如何处理？ 区分主动断开和异常断开，异常断开按有限次数和退避策略重连。
- 追问：为什么 Android 扫描不到设备？ 可能是蓝牙、定位权限、系统定位开关、设备广播或机型兼容问题。
八、加强记忆
BLE 用“扫、连、找、听、写、验、重连”来记。先扫描过滤设备，再连接并找到服务和特征值，先开启 notify 再写命令，长数据要分包，业务成功看回包，断线重连要有限退避。把它当状态机而不是普通请求，就能避开大多数坑。