IoT 设备的功耗优化：从硬件选型到软件策略的系统性思考

做 IoT 设备的人，迟早会被功耗问题找上门。开发阶段插着调试器，程序跑起来一切正常；一旦换成电池供电，设备可能在几天内就彻底没电。一个典型的电池供电传感器节点，往往需要在纽扣电池或两节 AA 电池下连续工作半年以上，这对硬件和软件都提出了完全不同于开发板阶段的要求。

很多团队遇到这个问题后的第一反应是换一颗低功耗 MCU，觉得只要芯片选得省电，问题就解决了一半。真正动手后才会发现，功耗的消耗分布在电源转换、传感器供电、无线通信、软件调度等各个环节。换一个芯片可能只是把其中一块压低，其他短板照样把平均电流拉高。IoT 设备的功耗优化从来不是某个器件的参数游戏，而是一条从硬件选型到软件策略的完整链路。

先算一笔功耗账，再谈硬件选型

很多选型讨论一上来就比“待机电流”或“峰值电流”，这其实是本末倒置。真正的起点是设备的业务时序模型：它多久醒一次，醒来做什么，需要多久做完，然后能不能立刻回去睡。

举个例子，一个温湿度传感器打算每十分钟上报一次，每次从采集到无线发送需要 300 毫秒，平均电流可以这样估算：

• 睡眠电流：3 μA，占空比约 99.5%
• 唤醒工作电流：平均 5 mA，持续 300 ms
• 加上偶尔的数据处理，整体平均电流大约在 15 到 20 μA

如果换成所谓“超低功耗”的 MCU，但无线模块每五分钟要连一次网络，空闲时仍消耗几十 μA，那么整体平均电流会高出很多。所以功耗预算应该先于芯片选型。没有业务模型，选型就是盲目的。

硬件选型：MCU、外设和电源转换

MCU 选型有三个参数必须放在一起看：运行电流、睡眠电流、唤醒时间。有的 MCU 运行电流很低，但深度睡眠唤醒需要几百微秒，对于需要频繁响应外部事件的设备并不合适；有的 MCU 睡眠电流达到了微安级，但内部 LDO 或参考电压无法关闭，实际睡眠电流远远超过手册标称。

很多团队只看芯片，却忽略了两件更重要的事：外设的静态电流和电源转换效率。传感器、Flash、无线模块即使不工作，如果供电没有被真正切断，也会从电池里消耗电流。常见做法是用 MCU 的 GPIO 直接给外设供电，但 GPIO 在睡眠时不一定能维持稳定的输出，更可靠的是加一个负载开关，由 MCU 在进入睡眠前断开。

还有一个容易忽略的分类是电压转换。如果电池电压是 3.7V 锂电池，而 MCU 和传感器工作在 3.3V，线性稳压器会把压差变成热量，静态电流可能就有几十微安。低功耗场景下更值得考虑的是高效率的 DCDC，或者根据系统设计只让部分电路常供电，高功耗电路按需开启。

无线通信方案怎么选，功耗只是其中一个维度

无线模块通常是整个设备功耗最高的部分，尤其在上报数据时。但对比不同方案时，不能只看发射峰值电流，还要看它为了维持通信链路所付出的“隐形成本”。常见方案的对比如下：

从硬件上看，BLE 在短距离场景下的平均功耗通常最低，但它需要网关或手机作为桥梁；LoRa 的峰值电流高，但由于没有持续在线成本，低频上报场景中反而很省电；NB-IoT 的发射电流最高，但 PSM 模式下不通信时几乎断网，适合需要随时随地唤醒但上报频率很低的设备。

选无线方案时还要考虑业务对时延的要求：事件触发后，BLE 可以很快和网关建立连接；NB-IoT 在 PSM 模式下需要重新进入联机状态，可能增加几秒时延。这个取舍决定了用户感知，也决定了软件策略能优化到什么程度。

软件策略：从轮询到事件驱动

硬件选型确定了功耗的下限，软件策略决定能不能接近这个下限。最常见的软件问题是轮询式编程。MCU 主循环里不断读传感器、做判断，CPU 几乎没有机会进入睡眠。即使每次循环很短，累加起来也会造成不小的平均电流。

正确的思路是事件驱动加周期唤醒。所有外部输入通过中断唤醒，周期任务由 RTC 定时器触发，设备空闲时保持深度睡眠。代码结构大致是：

while (1) {
    // 进入停止模式，等待 RTC 或外部中断唤醒
    enter_sleep(SLEEP_MODE_STOP, RTC_WAKEUP_INTERVAL);

    if (event_source == EVENT_SENSOR) {
        read_sensor_and_process();
    }

    if (event_source == EVENT_REPORT) {
        build_report();
        send_report();
    }

    configure_next_cycle();
}

这段代码省略了很多细节，比如进入睡眠前需要关闭无关外设、把 GPIO 配置为确定状态，然后打开唤醒源。醒来后要尽快完成处理，再回到睡眠，而不是发送完数据后继续在主循环里空转。

这里有一个容易被忽略的点：唤醒时不可避免会产生瞬态尖峰电流，尤其是给无线模块上电的瞬间。如果软件把多个高功耗动作放在同一个唤醒窗口里，尖峰电流叠加会让电源设计变得紧张。有时刻意把采集和上报分成两个独立唤醒，反而能分散冲击电流，降低电源电路设计难度。

此外，Duty cycle 的计算要留出余量。芯片手册里的睡眠电流通常是理想环境下的数值，实际电路会因为漏电、温度、湿度略有升高。软件上把睡眠时间做得足够长，是降低平均电流最简单的方法，但也意味着设备对事件的响应变慢。这里需要在产品体验和功耗之间做明确取舍，没有标准答案。

几个容易被忽略的功耗误区

很多团队在功耗优化上有一些共同误区，列出来更容易自查：

• 只认芯片，不认系统。花了大力气换低功耗 MCU，却让一颗带状态指示灯的检测电路常年耗电。
• 睡眠前没有处理 GPIO 和外设。GPIO 悬空、上拉或者外设供电未切断，睡眠电流可能比数据手册高几倍到几十倍。
• 为了省电把上报间隔拉到很长。结果业务上出现盲区，参数波动察觉不到，最后只能通过降低采样频率去补，功耗反而没有降下来。
• 忽略电池本身和电源转换。电池自放电、低温容量变化、DCDC 的静态电流，这些因素在长期运行中会和设备功耗叠加。

这些问题的共同点是：功耗问题不是芯片手册能回答的，必须在具体电路和系统运行中去发现。

怎么把功耗优化落到实际项目里

功耗优化要落地，测量是第一步，也是最容易暴露问题的一步。很多团队习惯拿万用表串电流，但实际上设备睡眠时电流在微安级，万用表分辨率不够，有时读数会跳来跳去。建议至少使用示波器加电流探头，或者使用精度更高的功耗分析仪，记录一段完整的工作周期，然后分段计算平均电流。

一个很容易踩的坑是调试接口。开发阶段通过调试器供电和连接，调试器会从引脚向 MCU 灌入电流，导致测出来的睡眠电流并不是设备的真实运行状态。量产之前，固件应关闭调试接口，至少做功耗测试时要注意断开调试器。

举例来说，一个智能门磁设备在测试时电流始终比估算值高 0.2 mA，排查了很久，最后发现是磁簧传感器的上拉电阻默认使能，MCU 睡眠时电流从引脚漏掉，修改 GPIO 配置后电流恢复正常。这种问题只靠纸面计算发现不了，必须用分模块测量的方式逐个电源域检查。

另一个更典型的场景是资产追踪产品。GPS 模块峰值电流接近几十毫安，如果持续开着，再大的电池也不够用。方案是让加速度计持续工作，用低功耗的加速度计中断唤醒 MCU，再由 MCU 打开 GPS，定位成功后立即关闭电源。这样一来，功耗从“持续耗电”变成了“按需耗电”，系统的续航立刻有了数量级改善。

如果现在有一个需要低功耗设计的 IoT 产品，可以按下面几条来推进：

1. 建立功耗预算表，把每个运行状态的电流、持续时间和频率列出来，先算出理论平均电流。
2. 根据业务模型选择平台，重点关注睡眠电流、唤醒时间和外设电源域，不只看运行功耗。
3. 搭建功耗测量环境，按模块测量当前电流，和预算表对比，找出差异来源。
4. 在软件里引入低功耗状态机，明确每个状态之间的转换条件，优先跑通“睡眠-唤醒-处理-上报-睡眠”的基础链路。
5. 做长期电流曲线记录，观察是否存在偶发异常唤醒，以及电池电压在低电量区域的下降规律。

如果预算表显示平均电流已经接近目标，但实测仍然偏高，可以从外设漏电和电源转换效率继续排查。不要为了某一个参数盲目调整方案，任何一个优化都有代价。

功耗优化的本质，是在业务需求和物理限制之间做平衡。硬件选型决定了方案的功耗下限，软件策略决定如何逼近这个下限，而测量验证保证所有假设都经得起推敲。IoT 设备的功耗问题不会一次性解决，产品越往后演进，关于续航、体积和成本的约束只会更紧。与其把它当成一个专项修复任务，不如把功耗当作一个持续演化的功能需求来管理——这可能是读完这篇文章后，最重要的认知变化。