BLE 是怎么工作的：广播、连接与 GATT

直接回答：BLE 省电的关键在于它绝大部分时间都在睡觉：设备只在很短的时间片里广播或监听，连上之后也是约定好时间点才通信。数据模型则是围绕 GATT 组织的——服务（Service）下面挂特征值（Characteristic），读写和订阅都是对特征值操作。

BLE 和传统蓝牙不是一回事

虽然名字里都有蓝牙，但 BLE（Bluetooth Low Energy）从 4.0 引入之后是另一套协议，目标和取舍完全不同：

现在的手机蓝牙芯片基本都是"双模"，同时支持两套协议。所以"手机蓝牙搜不到设备"有时不是故障，而是设备只广播 BLE 而 App 用了经典蓝牙的扫描接口。

协议分层：从无线电到应用

自下而上大致这几层：

调试时经常看到"抓到 HCI 日志"的提示，就是因为 HCI 往上的协议主机能看到，往下的射频行为只能靠抓包器。

一次完整的连接过程

1. 广播：外设按固定间隔在三个广播信道上发送广播包，包里包含设备地址、名称、服务 UUID 等；
2. 扫描：中心设备周期性打开接收窗口，收到广播后就能发现对方（scan 与 connect 是两种不同的动作）；
3. 发起连接：中心设备发起连接请求，双方约定连接间隔、从机延迟和超时时间；
4. 连接后：按约定的时间点通信，没数据时设备继续睡，这是省电的核心机制；
5. 配对与加密（可选）：走 SMP，交换密钥；
6. 服务发现：主设备读取对端的 GATT 表，知道有哪些服务、特征值和它们支持的操作；
7. 通信：对特征值做读、写、订阅通知。

连接参数的三个值直接决定功耗和延迟：

• 连接间隔：多久通信一次，单位 1.25ms，从 7.5ms 到 4s；
• 从机延迟：允许从机跳过多少次连接事件，跳过越多越省电、响应越慢；
• 超时：多久没收到回应就认为断连。

GATT：连上之后怎么组织数据

GATT 是一棵树：Service → Characteristic → Descriptor。

• Service：一组相关功能的集合，用 UUID 标识。标准服务（电池、心率、设备信息）是 16 位短 UUID，自定义的是 128 位；
• Characteristic：真正的数据点，每个特征值都有值、权限（读 / 写 / 通知）和可选的描述符；
• Descriptor：描述特征值的额外信息，比如单位、上报频率、用户描述。

四种常用交互方式：

MTU 与分包

默认 ATT MTU 是 23 字节，除去头部实际能带 20 字节的有效载荷。所以发一条稍长的数据就必须自己处理分包：

1. 连接后先协商 MTU（Android 上 requestMtu，iOS 会自动协商），通常能到 185~517 字节；
2. 超过 MTU 的数据要在应用层自己拆包，并在协议里带上序号和总长度；
3. 通知模式下连续发多条时，要考虑从设备侧的发包速率，太快会被丢。

这一层没有标准答案，各家私有协议都是自己定义的，对接新设备时第一件事就是问清楚它的分包规则。

常见问题怎么排查

• 搜不到设备：确认是 BLE 广播而不是经典蓝牙；确认广播间隔没设得太长；Android 上扫描需要定位权限（这是系统限制）；
• 能连上但读不到数据：多半是没做服务发现，或者特征值的 UUID 写错了；
• 连接老断：连接间隔设太小、从机延迟不匹配，或者主设备的连接数到了上限；
• 数据不全：MTU 没协商、分包逻辑和对方不一致；
• 工具：Android 上用 nRF Connect，iOS 上用 LightBlue，抓包用 Ellisys 或 Nordic 的嗅探器——先用现成工具确认设备本身没问题，再怀疑自己的代码。

本文整理自我自己早先收集的 BLE 资料（含知乎上的几篇原理分析），按"从广播到 GATT"的主线重新组织并补充了调试经验，文字由 AI 协助改写后经我复核。协议细节以蓝牙 SIG 的官方规范为准。

这篇笔记整理自我自己的实践记录，如果做法有出入，或者你踩过别的坑，欢迎到留言板一起聊聊。