3、蓝牙协议栈功耗分析：广播间隔与功耗、连接间隔与功耗、Sniff Subrating模式

好，咱们进入第三章。这一章我打算聊聊蓝牙协议栈里跟功耗最相关的三个参数：广播间隔、连接间隔，还有Sniff Subrating模式。说白了，这三个东西就是TWS耳机功耗的“命门”。你调好了，续航蹭蹭往上涨；调不好，用户一天充三次电，骂娘都是轻的。

3.1 广播间隔与功耗

先说说广播间隔。这个参数决定了耳机在“未连接”状态下，多久发一次广播包。你想想看，耳机从充电仓拿出来，到跟手机配对成功，这段时间它一直在广播。广播间隔设得越短，手机发现得越快，但功耗也越高。

我个人的习惯是，在配对阶段用短间隔，比如20ms到30ms。这样用户体验好，一拿出来就秒连。但一旦连接建立，我会立刻把广播停掉。嗯，这里要注意：有些方案商偷懒，连接后还让广播开着，那功耗就白费了。

我在项目中遇到过一个问题：某款耳机在手机附近总是断连重连。查了半天，发现是广播间隔设得太短，导致射频频繁发射，干扰了正常的连接事件。后来我把广播间隔从20ms调到40ms，问题就解决了。所以啊，广播间隔不是越短越好，得平衡。

广播间隔	平均电流（典型值）	适用场景
20ms	~500μA	快速配对、寻找设备
100ms	~300μA	常规待机广播
1000ms	~100μA	低功耗待机、电量广播

3.2 连接间隔与功耗

连接间隔，这是TWS功耗的“大头”。连接建立后，主设备和从设备按照固定的时间间隔交换数据包。这个间隔就是连接间隔。

连接间隔的范围是7.5ms到4s。你设得越小，数据延迟越低，但功耗越高。设得越大，功耗越低，但延迟就上去了。对于TWS耳机来说，音频数据是实时流，连接间隔一般设在20ms到50ms之间。

为什么会这样？因为蓝牙音频的编码帧通常是20ms一包。如果连接间隔大于20ms，你就得等下一个连接事件才能发数据，延迟就翻倍了。我曾经试过把连接间隔调到30ms，结果用户反馈音画不同步，看电影时嘴型对不上。后来老老实实改回20ms。

我建议的做法是：在连接请求中，同时提交多个可接受的连接间隔值，让主设备选。比如提交20ms、25ms、30ms三个选项。这样兼容性最好。

另外，连接间隔跟功耗的关系不是线性的。你想想看，连接间隔从20ms翻倍到40ms，理论上功耗减半，但实际上因为每次连接事件都要重新锁频、校准，所以功耗只降低30%-40%。嗯，这里要注意：连接事件里的数据包长度也很关键。如果你每次只发一个空包，那大部分能量都浪费在射频开启和关闭的 overhead 上了。

3.3 Sniff Subrating模式

Sniff Subrating，这个名词听起来挺唬人，说白了就是“更省电的监听模式”。

在经典蓝牙（BR/EDR）里，有个Sniff模式，设备可以隔一段时间才醒来监听主设备的数据。但Sniff模式的缺点是，每次醒来都要监听完整的连接事件，功耗还是偏高。

Sniff Subrating 是蓝牙4.1引入的改进。它允许从设备在连接事件中只监听一部分时间，甚至跳过某些连接事件。这样，从设备可以睡得更久，醒来时间更短。

我记得在做一个TWS项目时，手机端不支持Sniff Subrating，结果耳机功耗比竞品高了20%。后来我查了协议栈，发现是手机蓝牙芯片太老，只支持标准的Sniff模式。没办法，只能在耳机端做优化，把连接间隔拉长到45ms，同时减少每次连接事件的数据量。

实际项目中，我一般把Subrate设为2或3。再大就不行了，因为音频数据需要及时确认。如果Subrate太大，主设备发来的音频包可能因为没及时确认而重传，反而更耗电。

我曾经踩过一个坑：把Subrate设成4，想着省电。结果耳机在弱信号环境下频繁断连。原因是主设备发了数据包，耳机要等4个连接事件后才确认，主设备等不及就超时断连了。后来我把Subrate改成2，同时把连接间隔从20ms降到15ms，问题解决。

最后总结一下这三个参数的取舍：

• 广播间隔：配对时短，连接后停掉。待机时长一点，比如500ms到1000ms。
• 连接间隔：音频场景用20ms-30ms，非音频场景（如OTA升级）可以拉到100ms以上。
• Sniff Subrating：能开就开，Subrate设2或3。记得先跟手机协商。

这三个参数调好了，TWS耳机的待机功耗可以从1mA降到300μA以下。嗯，这就是我常说的“调参如调命”。