做过BLE开发的同学应该都有这种经历第一次调广播抓包器上看到一堆看不懂的报文手机扫描列表里一会儿出现一会儿消失或者明明广播开了却一直搜不到。我当年接手第一个低功耗蓝牙项目时最头疼的不是GATT服务怎么写反而是最基础的广播参数——广播间隔设多少为什么有时候设备秒被发现有时候要等十几秒为什么说广播耗电但其实又没那么耗电这些问题归根结底都是对“广播”这个机制的理解不够透。BLE广播是低功耗蓝牙设备对外发声的唯一通道是设备被扫描、被发现、被连接的前提同时也是信标这类无连接业务的数据承载方式。把广播基础打扎实后面做连接、做多连接、做低功耗调优都会顺很多。这篇文章我会从广播的定位、空中报文结构、广播参数的功耗权衡、广播模式与连接交互再到实际开发中的常见坑一层层拆开讲。1. 广播到底在“广”什么先理解BLE里为什么会有广播1.1 广播不是聊天是“喊话”BLE的通信模型和经典蓝牙差别很大。经典蓝牙要连上之后才能传数据而BLE从一开始就设计了一种“不需要连接就能传递信息”的机制这就是广播。你可以把广播想象成一个人在广场上举着牌子喊话牌子上写着“我是谁、我能干什么、我在这”路过的人扫描者不需要和这个人建立任何关系只需要看一眼牌子就知道了。BLE广播做的就是这件事。那为什么需要这个机制核心原因有三个发现设备一个BLE设备刚上电谁也不知道它存在。它必须主动发广播手机或者其他中心设备才能知道“这里有设备”。这是广播最原始也最重要的用途。传递少量信息广播本身就能携带最多31字节的应用数据扫码枪、电子价签、室内定位信标这类场景根本不需要建立连接直接靠广播把数据发出去就行。建立连接的前置步骤如果一个设备想被连接它必须通过广播把自己“可连接”的状态喊出来等待连接请求。1.2 广播是状态通告不是数据传输通道很多初学者有个误区把广播当成“像UDP一样随便发数据”的通道频繁修改广播内容、一有数据就发广播。真实项目里不是这么用的。广播的特点是数据量小、单向严格说有扫描请求和广播响应能实现一问一答但信息量依然有限、没有重传确认、实时性没有保障。它适合传递“设备状态”、“设备标识”、“简单指令”这类信息不适合传递大块业务数据更不适合做可靠数据通道。另外要明白一个概念广播报文不是持续在发而是按周期重复发。设备到了广播时间点在三个广播信道上各发一次发完就进入睡眠等下个周期再醒来发。所以“广播”这个词在BLE里指的不是一直占用信道喊而是周期性、短促地“喊一嗓子”。理解这一点之后后面所有关于功耗和参数调优的原理就都好懂了。2. 广播的空中协议细节三个专用信道与一帧广播报文的结构2.1 为什么偏偏是37、38、39这三个信道BLE在2.4GHz频段划分了40个物理信道编号0到39每信道带宽2MHz从2402MHz到2480MHz。其中37、38、39三个信道被划为广播信道其余37个是数据信道。广播信道不是随便选的。2.4GHz频段还有WiFi在跑WiFi常用的非重叠信道是1、6、11中心频率分别为2412MHz、2437MHz、2462MHz带宽22MHz。BLE把广播信道放在这三个WiFi信道的“缝隙”里广播信道中心频率与WiFi信道位置关系372402 MHzWiFi信道1左侧边缘之外382426 MHzWiFi信道1与信道6之间392480 MHzWiFi信道11右侧边缘之外这样设计是为了让广播报文尽量避开WiFi的强信号区提高广播被扫描到的概率。注意广播信道的编号和频率关系是37对应2402、38对应2426、39对应2480不是从低到高顺序排的抓包时别弄混。实际开发中这个选择影响很大。如果在办公楼这种WiFi密集环境里做广播调试37和39可能被相邻WiFi信道压得比较厉害38通常表现好一些。我在一次展会现场做demo时就遇到过这种情况广播间隔明明设的100ms但现场很多人手机同时扫描设备就是偶尔掉线后来把发射功率调高、广播间隔调短才稳住。2.2 拆开一帧广播报文前导码、访问地址、PDU和CRC一帧完整的广播报文在空中的结构是这样的前导码Preamble1字节用于接收端做频率同步和比特对齐。访问地址Access Address4字节。广播报文固定使用0x8E89BED6这个特殊访问地址数据报文则是连接建立时随机生成的。用同一个访问地址扫描器才能认出“这是广播包不是普通数据包”。PDUProtocol Data Unit2到39字节是广播报文的“正文”。CRC3字节校验用。广播PDU是整个报文的核心。它由两部分组成PDU头2字节和载荷。PDU头里值得关心的是这几位PDU Type4bit决定广播类型后面第4节会细说。TxAdd1bit发送者地址类型是公共地址还是随机地址。RxAdd1bit接收者地址类型定向广播和连接请求里会用到。长度6bit载荷长度。在ADV_IND这类通用广播的PDU里载荷的开头必须是6字节的广播者设备地址剩下的才是真正的广播数据区。广播数据区最大31字节这就是为什么市面上所有BLE开发资料都在说“广播数据最多31字节”。2.3 广播数据区的AD结构所有广播数据都是“标签-长度-值”广播数据区虽然最多31字节但内部有严格的格式要求一帧广播数据由若干个AD Structure组成每个AD Structure是“长度 类型 数据”。02 01 06 03 02 F0 FF 05 09 48 65 6C 6C 6F从左往右拆02是第一个AD结构的总长度说明后面2字节是它的内容01是AD类型表示Flags06是Flags值二进制00000110代表设备支持“一般可发现模式”并且“不支持BR/EDR”03是第二个AD结构的长度02是AD类型表示“完整的16位UUID列表”F0 FF是UUID值注意这里是小端序05是第三个AD结构长度09是AD类型表示“完整的本地设备名称”48 65 6C 6C 6F是ASCII码“Hello”所以这一整条广播的语义就是“我叫Hello我的UUID是0xFFF0我可以被发现”。实际开发中常用的AD类型就那几种0x01Flags可发现模式、是否支持经典蓝牙0x02/0x0316位UUID的部分/完整列表0x06/0x07128位UUID的部分/完整列表0x09完整设备名称0xFF厂商自定义数据有一个细节特别容易踩坑128位UUID和厂商自定义数据里的多字节字段一律小端序。比如iBeacon的Proximity UUID在广播报文里是按字节颠倒存的。很多人在解析时直接按大端读出来结果发现UUID对不上调了半天其实是字节序问题。3. 广播参数的取舍从20ms到10.24s背后全是功耗和时延的博弈3.1 广播间隔BLE最重要的一个旋钮广播间隔Advertising Interval指的是两次广播事件之间的时间范围是20ms到10.24s步长0.625ms。一个广播事件里设备会在37、38、39三个信道上各发一次广播报文所以扫描者不管蹲在哪个信道上都能听到。实际广播周期不是严格等于广播间隔而是在间隔之后会加上0到10ms的伪随机延迟。这是为了减少多个设备广播节奏完全同步时在同一个信道上反复碰撞的情况。广播间隔直接决定了设备被发现的速度间隔越短广播越密集手机扫到它的时间越短但设备醒来次数多功耗高。间隔越长越省电但扫描者可能要等好几个间隔才能在一次扫描窗口里撞上广播。以20ms间隔和10.24s间隔对比假设扫描器的扫描窗口是100ms那20ms间隔的设备在扫描窗口内基本必现而10.24s间隔的设备运气差的话要扫好多次才能碰到一次。我从实际项目中总结的经验值是这样使用场景推荐广播间隔理由高实时性可连接设备20ms-50ms手机一进范围就要能发现比如碰一碰连接通用可连接外设100ms-200ms功耗和发现速度平衡大多数设备在这个区间信标类不可连接设备200ms-1s广播内容固定不需要频繁刷新24小时常供电设备1s以上完全不需要考虑功耗时可以拉长减少信道占用3.2 一秒钟要广播多少次耗电多少算给你看广播功耗没有想象中那么可怕。做低功耗设备的人心里要有一笔账平均电流 广播事件电流 × 占空比 睡眠电流。拿一个典型的BLE SoC为例射频发射峰值电流大约15mA睡眠电流大约2uA。一帧ADV_IND广播报文37字节左右在1Mbps速率下空中传输时间约300us加上收发转换和扫描请求监听窗口一个广播事件总时长大约1.25ms具体取决于是否开启扫描响应。如果广播间隔设为200ms那么占空比就是1.25ms / 200ms ≈ 0.625% 平均广播电流 ≈ 15mA × 0.625% ≈ 94uA 总平均电流 ≈ 94uA 2uA ≈ 96uA一颗230mAh的纽扣电池在这种工况下理论上能用230mAh / 0.096mA ≈ 2395小时 ≈ 99天如果广播间隔拉到1s占空比 ≈ 1.25ms / 1000ms 0.125% 平均广播电流 ≈ 15mA × 0.125% ≈ 19uA加上睡眠电流后大约20uA出头一颗纽扣电池能用一年以上。这就是为什么很多信标设备只靠一颗CR2032电池就能跑大半年——不是广播不耗电而是广播的“占空比”低到让平均电流非常可观。3.3 发射功率与广播丢包不是越大越好发射功率是可配置的常见参数典型范围是-20dBm到8dBm。功率越高信号覆盖越远但有两个代价一是峰值电流上升二是对周围信道造成更大干扰。我之前在一批手环设备中发现一个现象发射功率从0dBm调到8dBm后设备端广播平均电流直接翻了一倍多但手机在近距离扫描时成功率并没有明显提升因为近距离本来就是强信号场景。后来只在需要远距离场景才把功率调高日常保持0dBm。实测下来一个调功率的经验法则先按距离需求定功率再按功耗预算定广播间隔顺序别反了。很多方案一上来就把功率拉满、间隔设得很短结果功耗远超预期后面又要花大力气降功耗其实是做反了。3.4 别忽略的系统级干扰扫描窗口和手机后台限制广播要想被收到扫描者必须正好在某个广播信道上打开射频接收窗口。手机端的扫描策略各家策略并不透明同一台手机在同一位置不同时间扫描的灵敏度都有差异。iOS和Android还有各自的限制iOS App退到后台后可连接广播很难保持常开系统的做法是限制后台广播类型和持续时间。想在后台长期广播基本上不可行。Android 8.0之后限制了后台扫描后台应用不能连续扫描需要周期性分批扫描Android 12之后进一步收紧。做信标类应用时后台扫描策略要按系统版本做兼容。这些限制对开发者来说属于“新手不知道、老手经常踩”的内容。后面第5节会展开说。4. 四种广播模式与连接建立的交互过程4.1 ADV_IND、ADV_DIRECT_IND、ADV_NONCONN_IND、ADV_SCAN_IND广播PDU类型决定了设备对外呈现的“性格”。常见的四种PDU TypeGAP广播模式可连接可扫描典型用途ADV_IND可连接可扫描广播是是大多数BLE外设比如手环、传感器ADV_DIRECT_IND定向可连接广播是否已知中心设备时的快速重连ADV_NONCONN_IND不可连接不可扫描广播否否iBeacon、Eddystone信标ADV_SCAN_IND可扫描不可连接广播否是希望被读取信息但不被连接的状态一个很容易混淆的点“可连接”和“可扫描”是两回事。可连接的设备中心设备可以向它发送连接请求CONNECT_REQ之后双方进入连接状态。可扫描的设备中心设备可以给它发送扫描请求SCAN_REQ设备收到后回复一个扫描响应SCAN_RSP给对方。扫描响应对不要求连接的场景特别有用因为它把携带数据的能力扩展了一些。扫描响应同样可以携带31字节数据所以“广播数据 扫描响应数据”最多能承载62字节。有些信标协议的设计不是把定位ID全塞进广播而是放一部分在扫描响应里这样即使不连接也能多传点信息。ADV_DIRECT_IND是里面最特殊的一个。它的载荷不是广播数据而是目标设备的地址和发起者自己的地址说白了就是“我只想跟那一台设备说话”。因为定向广播不带应用数据所以PDU里除了地址几乎没有别的东西数据量小、事件短非常省电很适合在已知对方MAC地址的场景下主动发起快速重连。需要注意有些协议栈里定向广播在一段时间没有连接请求后会自动停掉不能把它当常开广播用。4.2 从广播到连接CONNECT_REQ里到底约定了什么当一个中心设备收到ADV_IND且打算连接时它会向广播者发送一个连接请求CONNECT_REQ。这个包已经不属于广播PDU但它是通过广播信道发送的里面定义了双方在数据信道上的所有连接参数连接间隔两个连接事件之间的时间7.5ms到4s。从机延迟从机允许跳过最多多少个连接事件而不回包。这能让从机更省电。连接超时超过多少时间没有数据交互就判定连接断开。跳频种子和信道映射数据信道使用哪个频率跳变序列。收到CONNECT_REQ后广播者就没法再继续广播了除非显式停止连接并使用多角色方式双方转入数据信道通信。连接建立的那一刻起广播基本上是“功成身退”的状态。4.3 广播模式下的一问一答SCAN_REQ和SCAN_RSP我看过不少初学者对扫描响应不理解觉得“扫描响应不就是广播多了点数据吗为什么不直接加进广播里”原因是广播报文本身越短被收到的概率越高对信道占用越少。如果把所有信息塞进一个31字节的广播帧报文变长、空中时间变长、碰撞概率上升而且对不关心额外信息的扫描者来说也是浪费。所以协议的做法是广播里只放最核心的“门面信息”当扫描者发现这个设备后如果感兴趣就主动发一个SCAN_REQ来“问一声”设备再通过SCAN_RSP把更详细的信息发过去。这个一问一答的交互只在广播信道上完成不建立连接。有个经验分享调试时如果发现手机扫描列表能看到设备名称但用抓包器看不到SCAN_RSP断电重启一下扫描器大概率是扫描器侧广播过滤没配好。因为SCAN_REQ的目标地址伪装了很多扫描器并不会把扫描请求包显示出来。5. 把广播知识落地的实操经验参数联动、调试工具与真实项目里的坑5.1 广播间隔、扫描窗口和RSSI抖动三个因素一起看广播能不能被扫到不是只看广播端的间隔还要结合扫描端的扫描窗口和射频环境。这里说一个我调试时常用的思路先用抓包器确认广播本身在正常工作信道、频率、内容都OK再用手机扫描确认端到端能发现如果手机扫不到但抓包器能看到广播包问题九成在手机扫描策略或者后台限制上如果抓包器都看不到那就是广播端的问题去查射频、天线匹配、堆叠配置。RSSI值也是个参考维度。广播的RSSI天然是抖动的因为环境多径效应、人体遮挡、天线方向都会影响信号强度。调试距离时我习惯连续采样50个广播包取平均值而不是看单包。单包RSSI波动范围有时候能到10dB以上如果拿单包值去判断生产测试的阈值误判率会高到离谱。5.2 31字节不够用结构化设计广播数据广播空间很金贵31字节要用得省。设计广播数据时我的建议是Flags一定要有没有它很多手机把它当未知设备处理。设备名称如果超过长度优先放到SCAN_RSP里广播区放UUID。UUID优先用16位的省空间不支持的场景再用128位。厂商自定义数据里放动态变化的内容静态内容放广播区。举个例子一个有电池电量显示的BLE设备广播结构可以这样设计广播区Flags 16位Service UUID 厂商自定义数据协议版本产品型号 扫描响应区完整设备名称 剩余电量百分比这样手机扫到就能看到设备名、知道支持什么服务电量这种变化的值放在扫描里读一次刷新一次。不连接也能展示核心信息。5.3 常见的广播数据解析坑字节序和类型错位数据解析的坑主要集中在两点。第一是字节序。BLE空中协议里多字节字段都是小端传输。包括UUID、厂商ID、Beacon的major/minor全都要按“低字节在前”读。曾有个项目服务端收到终端上报的beacon消息解析Proximity UUID之后发现和配置的完全不一样排查了很久才发现是终端SDK已经把字节序翻转过了服务端又翻了一次等于翻回去变回原样。第二是AD类型的“完整”和“不完整”之分。AD Type0x02是不完整的16位UUID列表0x03才是完整的。如果设备广播被截断payload不够有些协议栈会把本来不完整的列表标记完整并掉“不完整”标志导致解析出来的时候误以为数据是完整。提示做广播数据解析时不要假设广播包里AD结构的顺序一定是你发送的顺序。虽然大多数广播端是按顺序组包的但扫描端拿到的解析结果不一定按原顺序呈现。解析时要以AD Type为准做遍历不要做顺序假设。5.4 手机端扫描限制的兼容策略做BLE应用开发绕不开手机厂商的各种限制。这里分享几个适用多数场景的处理策略iOS前台广播可以正常发自定义数据但要注意后台广播的格式和时间限制。想要Apple设备稳定接收广播数据时必须在Capabilities里勾选“Uses Bluetooth LE accessories”并且处理后台授权否则后台广播在iOS上基本是摆设。Android侧搞不定的是后台扫描限制。Android 8的后台扫描会周期性执行Android 12进一步限制原生的做法推荐用“前台服务”保活扫描或者按系统要求申请BLUETOOTH_SCAN权限。国产厂商系统还要单独处理厂商自带的耗电优化。广播频率设置不要超过系统建议。个别Android旧版本设备对极短广播间隔的扫描兼容性很差实测20ms间隔在若干型号上反而不如50ms稳定。如果目标用户群是Android为主广播间隔不要压得太极限。5.5 工具和流程调广播问题的工作流我调试广播问题时会准备一套固定流程效率比瞎试高很多第一步用抓包工具先看广播端。确认37/38/39三个信道都有广播包间隔符合预期内容解析正确结构完整。第二步用工具类App扫描。确认端到端可发现记录扫描到的时间验证广播参数在实际环境里的表现。第三步两台不同品牌的手机对比。排除单个厂商扫描策略带来的误判这个步骤很关键做消费者产品的同学尤其别省略。第四步在目标场景里做极限测试。比如商场、展会、电梯口测广播丢包率和RSSI分布。这四步走完绝大多数广播问题都能定位到根因。5.6 一个实际案例广播间隔10.24s导致的“搜不到”最后分享一个印象深刻的排查经历。某开发者做了一个小外设功能一切都正常但送到客户那边测试时手机死活找不到设备。远程抓包发现广播正常频率、功率、内容都没问题就是广播间隔配置成了10.24s。10.24s意味着什么一个扫描周期内设备平均要等5到6秒才广播一次。如果现场扫描器或者手机的扫描窗口恰好没有跟广播事件机会对上用户感官就是“找不到”。后来把间隔改成200ms现象立刻消失。这个案例让我记住了两件事第一广播参数的默认值一定要按“上电即被发现”的要求来定不能满足于实验室环境里“能扫到”第二交付前一定要在目标机器上做一遍真实的发现测试不能只看抓包器里的正常波形。广播基础这部分内容说白了就是三个核心数字——三个广播信道、31字节数据上限、20ms到10.24s的间隔范围外加一种结构化思维。把这些吃透了后面看连接参数、GATT、多连接这些进阶内容时会顺畅很多。尤其是做低功耗产品的同学广播参数怎么配、广播数据怎么排、功耗预算怎么算这几道基本功决定了产品能不能从“能跑”变成“好用且省电”。
