2、BLE广播与扫描：广播模式、扫描模式、广播间隔与功耗的关系

好，咱们进入第二个话题。广播与扫描，这俩是BLE最基础的通信方式。说白了，一个设备在喊“我在这儿”，另一个设备在听“谁在喊”。

但你别小看这个“喊”和“听”。我见过太多项目，功耗降不下来，或者连接不稳定，根源都在广播和扫描的参数没调好。今天咱们就把这块掰开揉碎了讲。

2.1 广播模式：你是在“喊”还是在“悄悄说”？

BLE的广播模式，其实分好几种。我个人习惯把它们分成三类：

• 可连接广播：最常用。设备发广播，别人可以连上来。比如你的手环在广播，手机扫描到就能配对。
• 不可连接广播：只发数据，不接受连接。典型场景是信标（Beacon），比如商场里的位置推送。
• 可扫描广播：介于两者之间。别人可以扫描你，获取更多数据，但不能直接连接。

嗯，这里要注意：广播模式的选择，直接影响功耗。我在项目中遇到过，有人把信标设备设成了可连接广播，结果电池一个月就耗光了。其实信标只需要单向发数据，用不可连接广播就够了，功耗能降一半以上。

2.2 扫描模式：你是“竖着耳朵听”还是“随便听听”？

扫描模式，说白了就是接收端的行为。分两种：

• 被动扫描：只听，不发任何包。省电，但信息量少。
• 主动扫描：听到广播后，会发一个扫描请求，让对方回复更多数据。信息量大，但功耗高。

你想想看，主动扫描相当于你喊一声“谁在说话？”，对方再回你一句。一来一回，功耗自然上去了。

我曾经做过一个室内定位项目，扫描端是手机。一开始用主动扫描，手机发热严重，半天就没电。后来改成被动扫描，只解析广播包里的RSSI值，功耗降了40%，定位精度也没差多少。

2.3 广播间隔：快与慢的博弈

广播间隔，就是设备每隔多久发一次广播包。这个参数，是功耗与实时性的核心平衡点。

咱们看一组典型数据：

广播间隔	平均电流	发现延迟	适用场景
20ms	~1.5mA	~10ms	高实时性，如遥控器
100ms	~0.3mA	~50ms	一般交互，如鼠标
1s	~0.03mA	~500ms	低功耗，如传感器
10s	~0.003mA	~5s	极低功耗，如信标

为什么会这样？因为每次广播，射频都要打开一小段时间（约0.3ms~1ms）。间隔越短，射频打开的次数越多，功耗自然就上去了。

我记得有个项目，客户要求设备能被“秒发现”。我一开始设了20ms间隔，功耗高得吓人。后来跟客户沟通，发现其实3秒内发现就行。我把间隔调到500ms，功耗直接降了一个数量级。

2.4 广播与扫描的功耗公式

咱们来点硬核的。广播功耗的估算公式：

P_broadcast = V × I_tx × T_tx × N

其中：

• V：供电电压（通常3V）
• I_tx：发射电流（约5~15mA）
• T_tx：每次发射时长（约0.3ms~1ms）
• N：每秒广播次数（1/广播间隔）

举个例子：3V供电，发射电流10mA，每次发射0.5ms，广播间隔100ms。

P = 3 × 0.01 × 0.0005 × 10 = 0.00015W
平均电流 = 0.00015 / 3 = 0.05mA

嗯，这个值很小。但别忘了，还有MCU唤醒、协议栈处理等额外开销。实际功耗通常是理论值的2~3倍。

2.5 实战：如何调优广播与扫描参数？

我总结了一套调优步骤，供你参考：

1. 先定需求：设备需要多快被发现？3秒？10秒？还是1分钟？
2. 选广播模式：需要连接吗？不需要就用不可连接广播。
3. 定广播间隔：根据发现延迟需求，选最长的间隔。比如3秒发现，间隔可以设1秒。
4. 选扫描模式：扫描端用被动扫描，除非必须获取额外数据。
5. 实测验证：用电流表或功耗分析仪，测实际平均电流。

我曾经帮一个客户优化智能门锁的功耗。原来广播间隔100ms，电池只能用3个月。我改成1s，同时把扫描端（手机APP）改成被动扫描，电池直接撑到1年半。客户都惊了。

2.6 总结

广播与扫描，看似简单，但里面的门道不少。核心就一句话：用最慢的广播间隔、最省电的扫描模式，满足你的业务需求。

别一上来就追求“秒发现”，那是以电池寿命为代价的。先想清楚你的场景到底需要多快，再反过来推参数。这样设计出来的产品，功耗和性能才能平衡。

下一章，咱们聊聊连接参数与功耗的关系。那个坑更多，我到时候给你讲讲我踩过的雷。