1. 广播数据解析概述
做嵌入式通信这些年，我接触最多的就是广播数据。说白了，广播就是设备在没人搭理它的时候，自己在那喊话：「我在这儿！我叫啥！我能干啥！」。你想想看，蓝牙耳机、Wi-Fi 热点、智能灯泡，它们刚上电时都在干同一件事——发广播。
但广播数据不是随便扔几个字节就完事的。它有一套严格的协议栈来封装。我刚开始啃 BLE 协议时，看着那堆十六进制字节串，头都大了。后来才明白，广播数据其实就三层东西：物理层怎么发、链路层怎么组包、应用层怎么塞数据。
什么是广播数据
广播数据，是设备在未建立连接前，主动向外发送的信息包。它不需要配对，不需要应答，发完就完事。接收方可以多个同时收，谁抢到算谁的。
举个例子：你手机打开蓝牙扫描，周围所有在广播的蓝牙设备都会出现在列表里。每个设备的名字、信号强度、支持的服务，都是从广播数据里解析出来的。
广播数据的三个核心特征：
- 单向性：发送方只管发，不关心有没有人收
- 无连接：不需要建立连接就能传输
- 周期性：设备按固定间隔重复发送
我在项目中遇到过最典型的场景：一个智能门锁，平时处于广播状态，手机 App 扫描到它后，通过广播数据里的设备 ID 识别出是哪把锁，然后发起连接。整个过程，广播数据就是那个「敲门砖」。
广播协议栈简介
不同无线技术的广播协议栈差别挺大。我挑三个最常见的给你捋一捋。
BLE 广播协议栈
BLE（低功耗蓝牙）的广播协议栈分四层：
| 层级 | 名称 | 职责 |
|---|---|---|
| L4 | 应用层 (GAP/ATT) | 定义广播数据内容，如设备名、服务 UUID |
| L3 | 逻辑链路层 (LL) | 组包、重传、信道选择 |
| L2 | 物理层 (PHY) | 调制解调、射频收发 |
| L1 | 射频层 (RF) | 天线、功率控制 |
BLE 广播包最大 47 字节，实际可用数据只有 31 字节。嗯，你没看错，就 31 个字节。我早期做 BLE 项目时，为了把设备信息塞进这 31 字节里，跟产品经理吵了不下三次架。
经典蓝牙广播协议栈
经典蓝牙（BR/EDR）的广播机制跟 BLE 不太一样。它用的是 Inquiry Scan 和 Page Scan，说白了就是设备主动问：「有人吗？」。广播数据格式更复杂，但好处是带宽大，能传更多信息。
我个人习惯把经典蓝牙的广播理解为「先喊一嗓子，再慢慢聊」。它不像 BLE 那样精打细算，但功耗也高得多。
Wi-Fi 广播协议栈
Wi-Fi 的广播主要靠 Beacon 帧。AP（热点）每隔 100ms 左右发一次 Beacon，里面装着 SSID、支持的速率、加密方式等信息。
Wi-Fi 广播协议栈的层次：
- 物理层：OFDM/CCK 调制，2.4GHz/5GHz 频段
- MAC 层：CSMA/CA 竞争机制，Beacon 帧格式
- 管理帧层：Probe Request/Response，Association
Wi-Fi Beacon 帧最大能到 2300 多字节，比 BLE 阔气多了。但 Wi-Fi 广播的解析难点在于：Beacon 帧里的信息元素（IE）是 TLV 格式，你得一个一个解析。
我的经验：不管哪种协议，广播数据的核心结构都是 TLV（Type-Length-Value）。你只要掌握了 TLV 的解析方法，换什么协议都不怕。
解析的核心挑战
广播数据解析看着简单，实际坑不少。我踩过的坑，给你列几个典型的。
挑战一：数据不完整
广播包在空口传输，受干扰、遮挡、多径效应影响，丢包是常态。你收到的广播数据可能缺头缺尾。我曾经调试一个 BLE 门锁，发现手机偶尔收到乱码的设备名，排查了两天才发现是广播包被 Wi-Fi 信号干扰，中间几个字节全错了。
挑战二：多协议共存
一个房间里可能有 BLE 设备、经典蓝牙设备、Wi-Fi 设备。它们都在发广播。你的解析器得能区分：这个包是 BLE 的，还是经典蓝牙的？是 Beacon 帧，还是 Probe Request？
区分方法其实就一条：看前导码和接入地址。BLE 的接入地址固定是 0x8E89BED6，经典蓝牙的接入地址是设备自己的 BD_ADDR。Wi-Fi 的 Beacon 帧前两个字节是 0x8000。
挑战三：厂商自定义数据
很多设备会在广播数据里塞厂商自定义字段。比如小米的智能家居设备，会在广播里加一段私有数据，用来标识设备类型和状态。这些数据没有公开文档，你得逆向分析。
我遇到过最离谱的一次：某厂商在广播数据里塞了 20 字节的加密数据，说是用来做安全认证。结果解密后发现，里面就存了个设备序列号。你说这何必呢？
避坑指南：解析厂商自定义数据时，一定要做容错处理。我曾经因为没检查数据长度，直接 memcpy 导致缓冲区溢出，整个系统挂了。从那以后，我解析广播数据必做三步：长度校验、类型校验、CRC 校验。
挑战四：时序问题
广播数据是周期性发送的，但周期不固定。BLE 的广播间隔可以在 20ms 到 10.24s 之间调整。Wi-Fi Beacon 间隔通常是 100ms，但实际会有抖动。你的解析器得能处理乱序、重复、超时的情况。
我个人习惯的做法：维护一个设备表，每个设备记录最近一次收到广播的时间戳。超过一定时间没收到，就认为设备离线了。这个超时时间怎么设？BLE 设备我设 3 倍广播间隔，Wi-Fi 设备我设 500ms。
知识体系总览
下面这张图，把本章的核心知识点串起来了。你看一眼，心里就有数了。
这张图把广播数据解析的三大协议栈和四大核心挑战串在了一起。你仔细看，不管哪个协议，最终都要面对那四个挑战。说白了，解析广播数据就是跟不完整、多协议、自定义、乱序这四个家伙斗智斗勇。
嗯，这一章先给你搭个框架。后面每一章，我都会带着你手撕具体的解析代码。你准备好了吗？