一个让我在客户现场熬到凌晨三点的坑前年做一个低功耗传感器节点项目设备需要在广播包里塞入传感器类型标识、电量等级、以及一个动态变化的状态标志位。扫描响应包里放设备名称和自定义的厂商自定义数据。功能在实验室跑得好好的。到了现场客户用他们的手机App一扫发现设备名称时有时无状态标志位偶尔跳变异常。更诡异的是同一台设备用不同品牌的手机扫描表现还不一样——有的手机能稳定拿到名称有的手机十次有八次拿不到。当时第一反应是射频参数没调好拿频谱仪看了半天广播间隔、发射功率、天线匹配都没问题。又怀疑是协议栈版本兼容性换了两版固件现象依旧。真正让我找到根因的是抓了一包完整的广播交互日志。发现一个被我忽略很久的事实扫描响应数据不是主动推送的它只在扫描者发出扫描请求之后才会回复。而有些手机在扫描时如果广播包里已经包含了它想要的信息它压根不会发扫描请求。更麻烦的是当广播包和扫描响应包里的内容存在逻辑关联时两者被不同时机、不同频率地获取就产生了数据不一致的窗口。那天凌晨三点改完代码我把这个坑记在了笔记本上。今天把它展开讲透。广播包和扫描响应包的本质区别很多人知道有这两个东西但说不清楚它们在链路层的行为差异。广播包是设备主动、周期性地发出去的。它不需要任何人在听自己按自己的节奏发。广播包的长度上限是31字节这31字节要装标志位、服务UUID、本地名称可选、厂商自定义数据、发射功率等等。每一样都占地方。扫描响应包是被动回复。扫描者收到广播包后如果它决定发一个扫描请求设备才会在下一个广播事件里回复扫描响应包。扫描响应包同样有31字节的上限。关键点在于扫描者是否发扫描请求取决于扫描者的策略。有的扫描者只要广播包里没有它要的信息就发扫描请求有的扫描者不管广播包里有什么都发扫描请求还有的扫描者只在特定条件下才发。这就意味着设备端不能假设扫描响应包一定会被读取。更不能假设广播包和扫描响应包会在同一时间被同一个扫描者获取。分工不明确的典型症状我后来复盘发现这类问题在现场有几种非常典型的异常表现症状一设备名称间歇性丢失。你把名称放在扫描响应包里广播包里只放了一个简短的标识。某些手机会缓存广播包里的信息但从不发扫描请求于是它永远拿不到名称。而另一些手机发了扫描请求拿到了名称。用户看到的就是“有的手机能搜到名字有的搜不到”。症状二状态标志位跳变。你在广播包里放了一个状态位同时在扫描响应包里放了一个更详细的状态描述。两者在设备端是分别组包的如果组包时没有保证原子性扫描者可能在广播包里看到状态A在扫描响应包里看到状态B。如果这两个状态在逻辑上矛盾上层应用就会做出错误判断。症状三厂商自定义数据被截断或覆盖。广播包和扫描响应包各自31字节很多人把厂商自定义数据拆成两半一半放广播包一半放扫描响应包。但扫描者可能只拿到了其中一半解析时直接报错或丢弃整包。症状四配对信息不一致。有些设备把配对所需的标识信息分散在两个包里结果扫描者拿到的广播包和扫描响应包来自不同广播事件中间设备状态已经变了配对流程直接失败。现场排查的判断思路遇到这类问题不要先怀疑射频也不要先怀疑协议栈。按下面这个顺序走第一步确认扫描者行为。用两个以上不同品牌的手机分别抓包。看广播包里有什么扫描响应包里有什么扫描者发了多少次扫描请求拿到了什么。这一步能直接区分是设备端问题还是扫描者差异问题。第二步检查广播包和扫描响应包的组包时序。在设备端代码里找到广播数据更新和扫描响应数据更新的位置。看它们是不是在同一个临界区里完成的。如果广播包先更新扫描响应包后更新中间有一个广播事件发出去那这个广播事件里的两个包就是不一致的。第三步确认扫描响应包是否真的被发出。有些协议栈在广播包和扫描响应包总长度超限时会静默丢弃扫描响应包。你以为你设置了实际上根本没发出去。抓包确认。第四步检查是否有缓存机制。某些扫描者会缓存广播包里的信息如果广播包里的某个字段没有变化它不会重新读取扫描响应包。这时候你更新了扫描响应包里的内容扫描者拿到的还是旧值。正确的分工原则经过那次教训我后来定了几条硬规矩原则一扫描响应包只放“锦上添花”的信息。设备名称、厂商自定义数据、可选的服务信息这些放在扫描响应包里。即使扫描者永远不读扫描响应包设备的核心功能也不受影响。原则二广播包放“必须被看到”的信息。设备类型标识、核心状态标志、必要的服务UUID这些必须在广播包里。广播包是唯一保证会被周期性发送的内容。原则三两个包之间不要有逻辑依赖。广播包里的信息应该能独立解析扫描响应包里的信息也应该能独立解析。不要设计成“广播包里的某个字段是扫描响应包里某个字段的索引”这种结构。原则四组包更新要原子化。如果广播包和扫描响应包需要同时更新先把新数据准备好然后在同一个临界区内一次性写入协议栈的广播数据缓冲区和扫描响应数据缓冲区。不要让协议栈在中间发出一个广播事件。原则五扫描响应包的内容要能容忍丢失。扫描者可能只读一次也可能读多次还可能读到旧值。你的上层逻辑要能处理“扫描响应包缺失”的情况而不是直接崩溃或报错。一个典型的错误代码结构下面这种写法我在很多项目里都见过问题很大// 错误示例广播包和扫描响应包分别更新中间没有原子性保证voidupdate_adv_data(void){uint8_tadv_buf[31];uint8_tscan_rsp_buf[31];// 先组广播包build_adv_packet(adv_buf,sensor_半导体厂商ate);set_adv_data(adv_buf,sizeof(adv_buf));// 这里如果发生广播事件扫描者会拿到旧的扫描响应包// 或者拿到新的广播包和旧的扫描响应包两者不一致// 再组扫描响应包build_scan_rsp_packet(scan_rsp_buf,sensor_半导体厂商ate);set_scan_rsp_data(scan_rsp_buf,sizeof(scan_rsp_buf));}正确的做法是先把两个缓冲都填好再一次性提交// 正确示例先准备好两个缓冲再原子化提交voidupdate_adv_data_atomic(void){uint8_tadv_buf[31];uint8_tscan_rsp_buf[31];// 两个缓冲都基于同一份状态数据构建build_adv_packet(adv_buf,sensor_半导体厂商ate);build_scan_rsp_packet(scan_rsp_buf,sensor_半导体厂商ate);// 在同一个临界区内提交避免中间发出广播事件enter_cri国外半导体厂商cal_sec国外半导体厂商on();set_adv_data(adv_buf,sizeof(adv_buf));set_scan_rsp_data(scan_rsp_buf,sizeof(scan_rsp_buf));exit_cri国外半导体厂商cal_sec国外半导体厂商on();}但即使这样也不能保证扫描者一定同时拿到两个包。因为扫描者可能在广播事件A拿到广播包在广播事件B才发扫描请求拿到扫描响应包。如果广播事件A和B之间设备状态变了扫描者拿到的两个包仍然可能不一致。所以最根本的解决办法是不要让两个包之间存在必须一致才能解析的逻辑关系。每个包都能独立表达完整的信息或者至少能独立表达不会产生歧义的信息。怎么判断一个字段该放广播包还是扫描响应包我后来总结了一个简单的判断标准问自己一个问题如果扫描者永远不读扫描响应包这个字段丢失了会不会导致设备无法被正确识别或无法正常工作如果答案是“会”放广播包。如果答案是“不会只是少了一些附加信息”放扫描响应包。还有一个补充标准这个字段是不是动态变化的如果是动态变化的放广播包因为广播包发送频率更高更新更及时。如果是静态的、不常变的放扫描响应包节省广播包的空间。举个例子。设备名称通常是静态的放扫描响应包。电池电量是动态的放广播包。服务UUID是核心标识放广播包。厂商自定义的扩展信息如果扫描者不读也不影响基本功能放扫描响应包。扫描者视角的差异不同扫描者的行为差异是这个问题的放大器。有的扫描者只做被动扫描从不发扫描请求。有的扫描者做主动扫描每次都发扫描请求。有的扫描者在广播包里找到了它要的服务UUID就不发扫描请求了找不到才发。你在设备端无法控制扫描者的行为。你唯一能控制的是让广播包自身尽可能完整地表达设备的身份和核心状态。扫描响应包只是补充不是依赖。我后来在项目里加了一条自检逻辑设备启动时先只发广播包不发扫描响应包。让测试人员用各种手机去扫确认所有手机都能正确识别设备类型和核心状态。然后再开启扫描响应包确认附加信息能被正确读取。这样就把两个包的责任彻底分开了。一个容易被忽略的细节广播包长度和扫描响应包长度的分配广播包和扫描响应包各31字节但广播包里有强制字段。标志位占3字节如果放本地名称名称的每个字符占1字节还要加2字节的头。服务UUID有16位、32位、128位之分128位UUID占16字节。厂商自定义数据有2字节的公司标识符加自定义内容。实际算下来广播包里能自由支配的空间往往只有十几字节。扫描响应包虽然也有31字节但它没有强制字段可以全部用来放自定义数据。所以合理的分配是广播包放最小必要集扫描响应包放扩展集。不要把广播包塞满留一点余量给未来可能增加的核心字段。现场调试的实用技巧如果你在现场遇到疑似分工不明确导致的问题按下面这个流程走用抓包工具分别记录广播包和扫描响应包的原始内容至少记录10个广播事件。对比每个广播事件里两个包的内容看是否存在逻辑矛盾。用不同品牌的手机分别测试记录每个手机拿到的广播包和扫描响应包的内容。在设备端加日志记录每次更新广播数据和扫描响应数据的时间戳和内容。如果发现不一致先检查组包时序再检查扫描者是否发了扫描请求最后检查协议栈是否真的把扫描响应包发出去了。这个流程走下来基本能定位到根因。最后的忠告广播数据与扫描响应数据的分工本质上是一个信息可靠性分级的问题。广播包是可靠通道扫描响应包是尽力而为通道。把核心信息放在可靠通道上把附加信息放在尽力而为通道上。不要让核心功能依赖尽力而为通道。这个原则不仅适用于低功耗蓝牙广播也适用于任何“主动通告加被动补充”的通信模型。想清楚哪些信息必须被看到哪些信息看到了更好、看不到也能活分工问题就解决了一大半。