4、广播参数调优：广播间隔、广播时长、广播数据包大小对功耗的影响
做 BLE 低功耗产品，广播阶段往往是功耗的第一道坎。很多工程师一上来就盯着连接后的电流看，却忽略了广播期间那几毫秒到几十毫秒的脉冲电流。说实话，广播参数没调好，后面再怎么优化都是白费力气。
我个人习惯把广播阶段称为“功耗的隐形杀手”。为什么这么说？因为广播是设备上电后第一个开始工作的模块，而且它一直在重复、重复、再重复。你想想看，一个设备如果广播间隔设得太短，哪怕连接后的功耗再低，电池也会在不知不觉中被耗光。
核心结论：广播参数对功耗的影响，本质上是在“被发现的速度”和“电池续航”之间做权衡。调优的目标不是追求最低功耗，而是在满足业务需求的前提下，把功耗压到最低。
4.1 广播间隔：最直接的功耗杠杆
广播间隔，说白了就是设备两次广播事件之间的时间间隔。BLE 协议规定这个值范围是 20ms 到 10.24s，步进为 0.625ms。但实际开发中，我们很少用到极端值。
我在项目中遇到过这样一个案例：一个 Beacon 产品，客户要求广播间隔设为 100ms，结果电池只能用两周。后来我建议改成 500ms，电池直接撑了两个月。你看，只是改了一个参数，效果天差地别。
广播间隔对功耗的影响，可以用一个简单的公式来理解：
平均广播电流 = 单次广播事件电流 × (广播事件时长 / 广播间隔)举个例子：假设单次广播事件电流为 10mA，持续 3ms：
| 广播间隔 | 平均电流（估算） | 适用场景 |
|---|---|---|
| 20ms | 1.5mA | 高实时性连接、快速发现 |
| 100ms | 0.3mA | 普通连接、一般发现需求 |
| 500ms | 0.06mA | Beacon、低频率数据广播 |
| 1000ms | 0.03mA | 极低功耗、非实时场景 |
我的经验：如果产品需要被手机快速发现（比如配网场景），广播间隔建议设在 100ms-200ms。如果是纯 Beacon 广播，500ms-1000ms 是比较稳妥的选择。低于 50ms 的广播间隔，除非有特殊需求，否则我一般不建议用——功耗增长太快了。
4.2 广播时长：别让设备“空转”
广播时长，指的是设备持续广播的时间。很多芯片支持设置广播超时时间，比如 30 秒、60 秒，或者一直广播。这个参数对功耗的影响，很多人会忽略。
我记得有一次调试一个智能门锁，发现设备在未连接状态下电流一直偏高。查了半天，原来是广播超时时间设成了 0（表示一直广播）。门锁平时根本不需要被频繁发现，结果一直在那里“喊”，白白耗电。
广播时长的调优策略，我总结了几点：
- 按需广播：只在需要被发现的时候开启广播。比如门锁在检测到有人靠近时才广播，平时进入深度睡眠。
- 超时关闭：设置合理的广播超时时间。如果设备在 30 秒内没有被连接，自动停止广播，进入低功耗模式。
- 动态调整：在广播期间动态调整广播间隔。比如前 10 秒用 100ms 间隔快速被发现，之后切换到 500ms 间隔省电。
注意：广播超时时间不是越长越好。有些芯片在广播状态下无法进入深度睡眠，即使没有数据发送，也会消耗几百微安到几毫安的电流。我曾经见过一个产品，广播超时设成了 10 分钟，结果待机电流比预期高了 5 倍。
4.3 广播数据包大小：被忽视的“隐形消耗”
广播数据包的大小，很多人觉得无所谓——反正就多几个字节嘛。但实际测试下来，数据包大小对功耗的影响比你想象的要大。
为什么会这样？因为 BLE 广播信道的数据包长度是可变的，从 0 字节到 31 字节（广播通道）或 255 字节（扩展广播）。数据包越大，发送时间越长，射频开启的时间就越长，功耗自然就上去了。
我做过一个对比测试，用同一款芯片，同样的广播间隔（200ms），只改变广播数据包大小：
| 数据包大小 | 单次广播事件时长 | 平均电流（估算） |
|---|---|---|
| 0 字节（空包） | 约 1.2ms | 0.06mA |
| 10 字节 | 约 1.8ms | 0.09mA |
| 20 字节 | 约 2.4ms | 0.12mA |
| 31 字节（满包） | 约 3.0ms | 0.15mA |
你看，从 0 字节到 31 字节，平均电流差了 2.5 倍。虽然绝对值不大，但如果设备需要长时间广播，这个差距就会累积成可观的电量消耗。
我的建议：广播数据包只放必要的信息。比如 Beacon 只需要 UUID、Major、Minor 就够了，不要塞一堆自定义数据。如果确实需要传输较多数据，可以考虑用扫描响应（Scan Response）来分担，或者等连接后再通过 GATT 传输。
4.4 三个参数的协同调优
广播间隔、广播时长、数据包大小，这三个参数不是孤立的。它们之间会相互影响，调优时需要综合考虑。
下面这张图展示了三个参数之间的协同关系：
在实际项目中，我一般会按以下步骤来调优：
- 明确需求：设备需要多快被发现？是秒级还是分钟级？
- 确定广播间隔：根据发现延迟需求，选择最小的可行间隔。
- 精简数据包：去掉所有非必要字段，只保留核心数据。
- 设置广播时长：如果不需要持续广播，加上超时机制。
- 实测验证：用电流计实测广播阶段的平均电流，确认是否符合预期。
避坑指南：我曾经在一个项目中，把广播间隔从 200ms 改到 500ms，结果发现设备连接成功率大幅下降。后来排查发现，是因为手机端的扫描窗口设置得太短，导致经常错过广播包。所以调优广播参数时，一定要考虑对端设备的扫描行为。如果对端扫描间隔很大，你的广播间隔就不能太大，否则容易丢包。
4.5 实战案例：一个 Beacon 产品的调优过程
最后分享一个我实际做过的案例。一个室内定位 Beacon 产品，要求广播距离 30 米，电池续航 6 个月以上。
初始参数：
- 广播间隔：100ms
- 广播时长：一直广播
- 数据包大小：31 字节（满包）
- 实测平均电流：约 0.3mA
- 电池容量：1000mAh（CR2032）
- 理论续航：约 138 天（不到 5 个月）
调优后参数：
- 广播间隔：500ms
- 广播时长：按需广播（检测到运动时开启，静止 30 秒后关闭）
- 数据包大小：10 字节（只保留 UUID + Major + Minor）
- 实测平均电流：约 0.03mA
- 理论续航：约 3.8 年（远超 6 个月需求）
你看，只是调整了三个参数，续航从不到 5 个月提升到了 3 年以上。这就是广播参数调优的价值所在。
最后说一句：广播参数调优没有标准答案，每个产品都有自己的业务场景。我的建议是，先理解你的产品需要什么，再动手调参数。不要为了省电而牺牲用户体验，也不要为了追求极致性能而忽略功耗。找到那个平衡点，才是真正的调优高手。