1. BLE功耗模型：为什么需要休眠？
做蓝牙开发这些年，我经常被问到同一个问题：“为什么BLE设备非得休眠？让它一直跑着不行吗？”
说实话，我刚入行时也这么想过。直到有一次，我帮客户调试一个智能门锁——电池是CR2032，标称容量225mAh。如果让芯片一直保持接收状态，你猜能撑多久？不到三天。客户当场就炸了。嗯，从那以后，我再也不敢轻视休眠这件事了。
1.1 BLE设备的功耗组成
要理解为什么需要休眠，先得搞清楚电都耗在哪了。BLE设备在工作时，功耗主要来自以下几个部分：
| 功耗模块 | 典型电流 | 说明 |
|---|---|---|
| MCU活跃模式 | 2~10 mA | CPU执行代码、处理数据 |
| 射频发射（TX） | 5~15 mA | 发送广播或数据包，峰值最高 |
| 射频接收（RX） | 5~15 mA | 监听信道、接收数据 |
| 外设（传感器、LED等） | 0.1~50 mA | 视具体外设而定 |
| 休眠模式 | 0.5~5 µA | 仅保留RTC和唤醒逻辑 |
你看，休眠和活跃差了整整三个数量级。说白了，休眠就是BLE设备的命根子。
1.2 电池寿命与Duty Cycle的关系
这里有个核心概念——Duty Cycle（占空比）。它指的是设备活跃时间占总时间的比例。
公式：
平均电流 = 活跃电流 × Duty Cycle + 休眠电流 × (1 - Duty Cycle)
电池寿命（小时） = 电池容量（mAh） / 平均电流（mA）举个例子。假设一个BLE温度传感器：
- 活跃电流：10 mA（发送一次广播包，耗时3 ms）
- 休眠电流：2 µA
- 广播间隔：1秒
那么Duty Cycle = 3 ms / 1000 ms = 0.3%。平均电流算下来：
平均电流 = 10 mA × 0.003 + 0.002 mA × 0.997 ≈ 0.032 mA用一颗225 mAh的CR2032电池：
电池寿命 ≈ 225 / 0.032 ≈ 7031 小时 ≈ 293 天将近10个月。如果换成100 ms的广播间隔，Duty Cycle变成3%，平均电流飙升到0.3 mA，寿命直接缩到31天。差距就是这么残酷。
我的经验： 我在做可穿戴设备时，客户要求续航至少6个月。我们硬是把广播间隔从200 ms拉到1秒，同时优化了广播包长度。最后实测续航8个月，客户很满意。说白了，Duty Cycle每降低一个数量级，寿命就翻好几倍。
1.3 为什么不能一直休眠？
你可能会问：那我把Duty Cycle压到无限小不就行了？
嗯，这里有个平衡问题。休眠太久，设备响应就慢。比如门锁，你按了手机开锁，结果等5秒才响应，用户早骂街了。我遇到过最极端的案例——一个智能灯泡，为了省电把连接间隔设到4秒，结果用户开关灯时感觉像在玩“延迟游戏”。
所以，休眠不是目的，平衡功耗和响应才是。
1.4 BLE功耗模型的核心逻辑
为了让你更直观地理解，我画了一张图：
1.5 避坑指南
我曾经踩过的坑：
- 别只看峰值电流——有一次我光盯着TX电流优化，结果发现休眠电流从2 µA涨到了10 µA，因为一个GPIO没配置成下拉。平均电流反而更高了。
- Duty Cycle不是越小越好——连接间隔太长会导致链路层频繁重传，反而更耗电。我见过一个项目，把连接间隔从30 ms拉到100 ms，结果重传率飙升，功耗没降反升。
- 电池容量要留余量——标称225 mAh的CR2032，实际在低温下可能只有180 mAh。做产品时至少留20%的余量。
1.6 小结
这一章我们聊了BLE功耗模型的核心：功耗组成、Duty Cycle、电池寿命。说白了，休眠不是目的，而是手段。真正要追求的是在满足响应要求的前提下，把Duty Cycle压到最低。