4、广播数据包结构：AD Structure、AD Type、完整广播数据示例解析

广播数据包，说白了就是设备在喊：「我在这儿，我叫啥，我能干啥」。你想想看，两个 BLE 设备要建立连接，总得先打个招呼吧？这个打招呼的过程，就是通过广播数据包完成的。

我刚开始做 BLE 开发时，总觉得广播数据就是随便塞几个字节就行。直到有一次，产品在手机端死活搜不到服务——后来一查，是广播包里的 AD Type 配错了。嗯，从那以后我再也不敢小看这个结构了。

4.1 AD Structure：广播数据的最小单元

广播数据包的结构其实很简单。它由若干个 AD Structure 拼接而成。每个 AD Structure 遵循一个固定的格式：

举个例子：0x02 0x01 0x06 就是一个完整的 AD Structure。

• 0x02 表示后面有 2 个字节的数据
• 0x01 是 AD Type，代表「Flags」
• 0x06 是 Flags 的值，表示 LE General Discoverable Mode + BR/EDR Not Supported

我个人习惯把 AD Structure 想象成「积木块」。每个积木块都告诉接收方一条信息。多个积木块拼在一起，就构成了完整的广播数据。

4.2 AD Type：这些类型你必须掌握

AD Type 是广播数据包的灵魂。BLE 协议栈定义了非常多的类型，但实际开发中常用的就那么几个。我整理了一张表，你可以直接拿来参考：

4.3 广播数据包的整体结构

一个完整的 BLE 广播信道 PDU，其实包含两个部分：报头 和 有效载荷。有效载荷里又分为 AdvA（广播设备地址）和 AdvData（广播数据）。

我们关心的广播数据，就放在 AdvData 里。它的最大长度是 31 字节。这 31 个字节要容纳所有的 AD Structure，所以你得精打细算。

我画了一张图，帮你理清整个广播数据包的层级关系：

4.4 完整广播数据示例解析

光讲理论太枯燥。我们直接看一个真实的广播数据包。假设我抓到了一个设备的广播数据，十六进制如下：

02 01 06 03 02 0A 18 05 09 42 4C 45 5F 44 65 76

我们来逐字节拆解：

你看，这个设备只用了 12 个字节就完成了广播。它告诉扫描者：

• 我支持 BLE，不支持经典蓝牙
• 我有一个 Device Information Service
• 我的名字叫 BLE_Dev

4.5 广播数据的填充顺序建议

虽然协议没有强制规定 AD Structure 的顺序，但我个人建议按照以下优先级来填充：

1. Flags（0x01） — 放在最前面，扫描器最先解析
2. UUID 列表 — 让扫描器快速判断是否是自己关心的设备
3. Local Name — 方便用户识别设备
4. Tx Power Level — 用于距离估算
5. Manufacturer Specific Data — 自定义数据，放在最后

你想想看，扫描器收到广播包后，通常是按顺序解析的。把最重要的信息放在前面，能提高解析效率。我在做低功耗优化时，就利用这个顺序，让扫描端在解析到不关心的 UUID 后直接丢弃，省电效果很明显。

4.6 一个完整的广播数据构造示例

假设我们要构造一个广播数据包，包含以下信息：

• Flags: LE General Discoverable, BR/EDR Not Supported
• 完整 16-bit UUID: 0x180F (Battery Service)
• 完整设备名: "MySensor"
• Tx Power Level: -4 dBm

对应的十六进制数据如下：

02 01 06          // Flags: Length=2, Type=0x01, Data=0x06
03 02 0F 18       // UUID: Length=3, Type=0x02, Data=0x180F
09 09 4D 79 53 65 6E 73 6F 72  // Name: Length=9, Type=0x09, Data="MySensor"
02 0A FC          // Tx Power: Length=2, Type=0x0A, Data=0xFC (-4 dBm 的补码表示)

总长度 = 2 + 3 + 9 + 2 = 16 字节，远小于 31 字节的限制。还有空间可以加厂商自定义数据。