面向低功耗、稳定可靠 BLE 通信方案，从软件设计目标、方案选型到分层架构与关键流程，配套流程图与实现要点，直达量产质量与研发效率。
背景与目标
- 背景：电机控制、状态采集、故障诊断与 OTA 升级都依赖移动端与设备端的低延迟、低功耗、稳定连接。
- 目标：低功耗、快速连接、高可靠传输、应用层安全、可扩展协议、易维护 SDK。
架构总览
- 分层清晰：UI → SDK → 协议 → BLE 客户端 → 设备固件 → 服务/状态机
- 控制与状态分离：控制通道低延迟，状态通道稳定流式；OTA 独立不阻塞控制
方案选型
- 传输：基于 GATT；命令走写入特征，设备通过通知特征上行响应与事件。
- 编码：采用起止分隔符与转义机制，配合 XOR 校验保证帧边界与数据一致性；帧结构为
7E | cmd(1) | len(2) | payload | xor(1) | 7E。 - 命令集：包含应用版本查询、应用控制设置、仪表信息上报、控制响应等，区分查询型与设置型。
- 解析：先进行包格式与校验验证，再按协议掩码解析为结构化的状态/响应模型。
- MTU：优先协商更大 MTU 值，写入根据协商结果自动选择短写或长写以提升吞吐。
- 服务与特征：定义稳定的服务 UUID 与写/通知特征 UUID；扫描阶段可结合常见服务进行辅助过滤提升发现成功率。
连接生命周期
- 秒级发现、自动检测系统已连/已配对设备；MTU 协商后开启 Notify 再发指令
flowchart TB
A[扫描广播] --> B{过滤设备}
B -->|匹配UUID/厂商数据| C[建立GATT连接]
C --> D[MTU协商]
D --> E[订阅Notify特征]
E --> F[开启通知]
F --> G[正常通信]
H --> I{断链?}
I -->|是| J[退回扫描/优先重连]
I -->|否| H
指令与应答
- 上层采用统一命令模型构建请求，协议层负责组帧与发送；设备通过通知返回响应或状态，协议处理器完成验证与解析，上层按请求-响应模式匹配回调。
sequenceDiagram
participant App
participant SDK
participant Device
App->>SDK: send(Command)
SDK->>SDK: 组帧(7E/转义/XOR)
SDK->>Device: 写入数据包
Device-->>SDK: 通知上行数据包
SDK-->>SDK: 验证/解析为模型
SDK-->>App: 回调(响应/状态)
服务与特征
- 服务与特征保持稳定命名，便于跨端协作与维护；扫描阶段可结合通用服务过滤以提升发现效率。
- 写入策略根据 MTU 协商结果选择短写/长写，兼顾效率与兼容性。
flowchart LR
CtrlSvc[控制服务 0xFFF0] --> cmd_write[cmd_write: Write NR]
CtrlSvc --> cmd_notify[cmd_notify: Notify]
StateSvc[状态服务 0xFFF1] --> state_notify[state_notify: Notify]
OTASvc[OTA服务 0xFFF2] --> ota_write[ota_write: Write]
OTASvc --> ota_notify[ota_notify: Notify]
协议帧设计
- 结构：
7E | cmd(1) | len(2,BE) | payload(N) | xor(1) | 7E。 - 转义：对分隔符与转义字符采用双字节转义，保证帧边界不被误判。
- 校验：使用 XOR 校验覆盖命令、长度与载荷，快速验证数据一致性。
- 验证：先校验起止与最小长度，再重算校验对比，失败立即丢弃并上报错误。
安全策略（可选）
- 基于明文帧 + 校验的基本可靠性方案；如需加强安全，可在载荷层加入签名与时间戳，或在连接建立后协商会话密钥并进行载荷加密与认证。
OTA 升级
- 使用长写支持大数据包传输，结合 MTU 协商提升吞吐；分片与断点续传由上层控制，升级流程与控制通道隔离，保障常规通信不受影响。
flowchart LR
Start[开始升级] --> Prepare[校验包/签名/版本]
Prepare --> Switch[进入DFU模式/暂停控制通道]
Switch --> Chunk[分片发送]
Chunk --> Ack{应答/校验通过?}
Ack -->|否| Retry[重传/断点续传]
Ack -->|是| Commit[提交/应用新固件]
Commit --> Reboot[重启/回到正常模式]
Reboot --> End[升级完成]
低功耗策略
- 广播：普通 300--500ms；待机 800--1200ms；事件触发短时提升
- 连接：
interval=30--50ms、slaveLatency=4--10、timeout=4--6s - MTU：协商至 185，分片随 ATT 与机型差异自适应
- 节流：状态合并与节流（100--200ms）；小包合帧减少唤醒
关键实现要点
- 重传窗口：大小 3--5；超时 300--500ms；指数退避防抖
- 指令模型：区分必答控制与可跳过状态；明确重试与时限
- 线程模型：移动端 BLE 回调线程与业务线程解耦；设备侧事件与控制循环分离
- 指标与日志：连接时延、MTU、吞吐、丢包、重试、握手耗时、失败原因
调试与调优
- 吞吐压测：不同 MTU 下
pps/重试率对比；寻找最佳分片 - 稳定性：高干扰场景（电机 PWM/金属环境）重连成功率与耗时
- 兼容性：iOS/Android 栈差异（如 Android GATT 133）；连接后强制
discoverServices - 低功耗验证：记录电流曲线，量化参数调整影响
- OTA 可靠性：断电/断链恢复、双镜像回滚、进度一致性
常见坑与规避
- iOS 后台：后台模式声明与速率控制；避免系统挂起
- Android 缓存：特征缓存可能写旧；连接后重新
discoverServices - MTU 协商：必须在连接成功后；返回值可能不等于实际可用
- Notify 订阅：先订阅再发指令；避免早期响应丢失
- 多连接：一车一连；设备侧拒绝第二连接请求
实现思路要点
- 命令模型统一、组帧规范化、解析结构化，方便扩展与回归测试。
- 请求-响应严格时序：先订阅响应流，再发送请求，避免早期响应丢失。
- 设备数据流按设备维度隔离，支持多设备并发管理与订阅清理。
- 日志与指标贯穿链路：连接与协商、吞吐与丢包、解析与错误，辅助定位与调优。
结语
- 核心在于稳定、可靠与可维护。围绕 GATT 传输、稳健的帧/转义/校验与清晰的请求-响应模式，既保证 eBike 场景的低功耗与高可靠，又为后续安全与功能扩展留足空间。