1. 某次续航翻车之后，我把功耗账重新算了一遍
三年前我刚接手一款蓝牙模块的功耗优化时，一直有个错觉：只要选了一颗标称待机电流只有1微安的BLE SoC，产品续航就不会差。结果样机在老化架上跑了不到两个月，电池电压就开始跳水，用户反馈的实际续航连标称的一半都不到。后来我把整条链路拆开重新测了一遍，才发现问题根本不在芯片，而在我对"平均电流"的理解太粗糙。这大概是我在自有制造兜底能效这件事上交的第一笔学费。
这篇文章把这段经历里真正有用的东西整理出来：BLE设备的功耗由哪些部分组成、硬件和协议栈各有哪些优化空间、制造环节又是怎么决定批量一致性的。适合刚接手低功耗无线产品、以及被"标称续航"坑过的硬件工程师参考。我尽量少讲空话，直接给方法和数据。
1.1 BLE功耗模型的三张面孔
做低功耗无线产品，脑子里要同时装三组电流数据，不是只看芯片手册上的一个数就够了。
第一组是待机电流（Sleep Current）。设备99%的时间都在睡觉，这个电流直接决定了续航的地板。现代BLE SoC在RTC唤醒、RAM保持的情况下，待机能做到1微安甚至更低。但"芯片待机"不等于"整板待机"，板上还有传感器、上拉电阻、电源芯片、指示灯，每一路漏电都会叠加。
第二组是事件峰值电流。一次广播，一次连接事件，一次传感器采样加Flash写入，都是毫秒级的电流尖峰。峰值电流本身不决定续航，但它决定了你的电池能不能扛得住，电压会不会瞬间跌到复位阈值以下。很多纽扣电池设备续航算得很好，实际却不断重启，就是因为峰值电流把电池电压拉崩了。
第三组才是决定续航的平均电流。平均电流不是三个数简单取平均，而是把所有周期性的电流波形对时间做积分再除以周期。BLE设备的工作状态高度碎片化，真正决定平均电流的，是"事件电流 × 事件时长 / 事件周期"这个占空比公式。
我习惯在项目一开始就建一张功耗预算表，把每个周期的每个状态都列出来：睡眠多久、醒来多久、射频开多久、传感器转多久、Flash写多久。这张表从立项到量产会不断修订，它是我判断“某处优化值不值得做”的唯一依据。
1.2 先学会估算，再谈优化
拿一个最常见的BLE温湿度标签举例。电池是CR2032，容量按220毫安时算。设备每10秒醒来一次，读传感器并广播一包数据。
我们先粗算：假设每次唤醒加广播事件需要5毫秒，事件期间平均电流8毫安（传感器加射频），睡眠期间平均电流3微安。那么一个10秒周期内的平均电流大概是：8mA × 0.005s ÷ 10s + 3µA ≈ 4µA + 3µA = 7µA。220mAh ÷ 7µA ≈ 3.5年。听起来很不错。
但这个估算是理想的。CR2032在持续几个毫安的脉冲负载下，实际可用容量会打折扣，低温下掉得更快；产线上每台设备的待机电流也不会都恰好是3微安，可能有的板子是5微安，有的是8微安。所以我的经验是：预算表里永远给自己留30%的电流裕量。上面这个例子，如果平均电流算出来是7微安，我会把产品目标定在10微安以内，否则后患无穷。
这也是"自有制造兜底"的意义所在：实验室里一台样机做到7微安很容易，但量产一百台、一千台都能稳定落在7微安附近，靠的是制造端的测试、筛选和校准。没有产线数据，功耗预算表就永远只是PPT。
1.3 测平均电流为什么不能拿万用表串联
很多第一次做BLE的工程师喜欢拿数字万用表的电流档直接串进电池回路，看一个读数就算完事。这个操作在纯直流电路里没问题，但在BLE设备上是灾难。
BLE的射频事件只有几毫秒，峰值电流十几毫安，而数字万用表电流档的采样率通常只有每秒2到5次，积分窗口又长，它对这种短脉冲的响应几乎全是低通滤波后的平均结果，且误差极大。更麻烦的是，万用表电流档的内阻通常有几十到几百欧姆，串进电池回路后，设备在射频事件期间可能直接欠压复位。你测到的不是设备真正的功耗，而是"设备被测量工具搞得不断重启"的功耗。
我现在的标准做法是：用高侧采样电阻加差分放大，配合示波器抓电流波形；或者直接用功耗分析仪，它的动态范围能同时覆盖微安级睡眠电流和毫安级射频脉冲。测平均电流时，示波器记录至少10个完整工作周期，用数学通道做积分平均。
还有一个人人都踩过的坑：调试器没拔。芯片的SWD引脚被调试器拉高，SoC永远进不了深度睡眠，待机电流从1微安直接飙到几百微安。所以每次测待机电流之前，先确认设备已经物理断开调试器，并且用电流波形确认睡眠状态确实进去了。
2. 硬件设计里的隐形耗电：电源拓扑、漏电路径与射频链路
软件配置确实是BLE功耗优化的大头，但硬件设计里的隐形消耗往往更阴险。它不是一次性吃掉几十毫安，而是让设备的"地板电流"悄悄抬高几微安，你很难从功能表现上察觉，只能靠高精度测量发现。
我复盘过不少项目，发现硬件侧的功耗问题集中在三个方向：电源转换拓扑选择不当、外围无源器件漏电、射频天线失配。这三个问题有一个共同特征：它们几乎不会在单台样机上暴露，而是等到批量生产或温度变化时才集中爆发。
2.1 DC-DC在轻载时可能比LDO更费电
BLE设备经常是"睡10秒、醒5毫秒"的工作模式，平均负载电流很小，只有几微安到几十微安。很多工程师一看电池供电，下意识就选DC-DC降压，觉得开关电源效率高。这个想法在平均负载几十毫安以上没错，但在微安级负载下可能完全反过来。
DC-DC的静态电流（Quiescent Current）和开关损耗在那里摆着，哪怕没有任何负载，它本身也要消耗几微安到几十微安。LDO虽然转换效率低，但静态电流通常只有几百纳安到几微安。如果设备平均电流只有10微安，DC-DC在轻载下可能从电池吃掉20微安，而LDO加一个低功耗SoC可能总共只吃掉12微安。账一算，LDO反而更省。
我在某个低功耗门磁项目里就遇到过这种情况：硬件上用了某国产DC-DC，空载静态电流标称5微安，实际低温下漂到15微安，整机待机电流比预期多了将近10微安。后来把方案改成"传感器用LDO、射频峰值期间靠大电容缓冲"，待机电流才降回来。当然，如果设备的射频事件频次很高、平均负载达到几百微安以上，DC-DC的优势就很明显。这里没有绝对答案，只有针对你的占空比算出来的答案。
2.2 一颗电容在低温下改写了整个功耗曲线
有两类电容问题在量产阶段最容易爆雷。
第一类是滤波电容和储能电容的漏电。陶瓷电容的绝缘电阻理论上很高，但不同介质、不同厂家的实际漏电差别很大。我们曾经在产线上抽检待机电流，发现同一批板子中有大约5%待机电流比平均值高出3到5微安。逐板排查，最后定位到一颗X5R材质的100nF电容，在板子清洗不干净时会形成微小的漏电通道。换用漏电流更低的C0G电容并改进清洗工艺之后，问题消失。
第二类是射频匹配电容的温度特性。X5R、Y5V这些高介电常数陶瓷电容，容值会随温度和直流偏置电压大幅变化。Y5V在低温下容值可能掉到标称值的50%以下。放在射频匹配网络里，一颗电容容值变了，整个匹配就偏了，反射损耗变大，发射功率上不去，设备只能拿更高的PA电流去补偿，或者干脆不断重传。电流多出来多少？我们实测过一个项目，匹配电容在零下20度漂移后，同样信号强度下发射电流增加了约2毫安，重传率也明显上升。所以射频匹配电路里，我坚持只用C0G/NP0电容，贵一点，但值。
2.3 天线效率比发射功率更容易被忽视
很多团队把射频功耗等同于"改发射功率等级"，却忽略了天线效率才是最值得抠的地方。
设一个简单场景：某模块在0dBm发射功率下PA电流是13毫安，天线效率50%时，实际对外辐射的等效功率大约是-3dBm；如果把天线效率做到70%，同样0dBm传导功率下，对外辐射变成-1.5dBm，效果相当于白赚了1.5dB链路预算。反过来，如果天线效率只有30%，辐射功率就变成-5.2dBm，为了找回这2.2dB，你可能要把发射功率从0dBm调到+4dBm以上，PA电流跟着往上跳。
我在设计阶段就养成了一个习惯：不光看传导功率指标，还要看整机天线效率。天线周围有没有金属件、结构件介电常数多少、净空区是否被PCB铺铜侵占，都会影响效率。用网络分析仪看S11只是第一步，更靠谱的是在暗室里测整机效率，或者至少在近场用标准天线做对比测试。
天线效率差的设备还有一个隐藏代价：接收灵敏度也差。灵敏度差，主机收不到包，从机就得重发，重发又拉高平均电流。所以很多设备"功耗高"的根源，不在软件配置，而在天线周围那一小片PCB的物理设计。
3. 协议栈与固件配置：同样的芯片能差出10倍电流
硬件底子定好之后，BLE协议栈的配置就是最大的功耗变量。同一颗SoC、同一块板子，广播间隔从20毫秒改成1秒，平均电流能差出一个数量级。连接参数调得好不好，又能让设备在同样的工作内容下差出几倍电流。这一块不需要改硬件，是所有项目里性价比最高的优化点。
但协议配置没有"万能最优参数"，它永远是在功耗、实时性、可靠性之间做取舍。下面把几个关键旋钮逐个拆开讲。
3.1 广播间隔的固定开销
BLE广播不是只发一个包就结束，每个广播事件里，设备会在三个广播信道上依次发送，还要留出接收扫描请求或连接请求的窗口。这意味着每个广播事件都有一个"固定开销"：射频前端打开、锁相环稳定、按事件收发、再关上。这个开销通常持续1到3毫秒，期间电流是毫安级的。
如果广播间隔是100毫秒，每个事件2毫秒、事件期间10毫安，那么广播带来的平均电流大约是10mA × 2ms ÷ 100ms = 200微安。把间隔改成1秒，同样的事件，平均电流直接降到20微安。这是10倍的差距。所以对于不要求被秒发现的应用，广播间隔尽量拉长到1秒以上。对于需要快速配网的产品，可以做成"启动后先用短间隔广播30秒，然后再切到长间隔"，而不是一直用短间隔烧电。
另一个容易被忽略的是"可连接广播"与"不可连接定向广播"的区别。可连接广播会在每个事件后打开一小段接收窗口，等连接请求；可扫描广播还会额外接收扫描请求并回复扫描响应。这些额外的射频接收和发送都会增加事件时长。如果设备只需要单向上报，而且不需要被扫描，就选择最简的广播类型，把事件窗口压到最短。
3.2 连接间隔与Slave Latency是一把双刃剑
建立连接之后，从机每次都要在连接事件里醒来，接收主机的包、回复自己的数据。连接间隔越短，设备越"勤快"，功耗越高；间隔越长，数据延迟越大。折中的经典工具是Slave Latency：允许从机跳过若干个连接事件，只在第N个事件才真正醒来。
举个例子：连接间隔30毫秒，Slave Latency设为0，从机每30毫秒醒来一次；一个连接事件按3毫秒算，事件期间电流10毫安，平均电流约1毫安——这已经很高了。如果把Slave Latency调成9，从机可以每300毫秒才醒一次，平均电流降到约100微安，省了一个数量级，但主机发来的数据要被延迟到下一个有效事件才能收到。对于上报型传感器，这个延迟完全可接受；对于实时控制类设备，就不行。
这里要提醒一句：连接参数是由主机发起请求的，从机可以建议，但最后拍板的是主机。很多手机APP在建立连接时用默认的快速参数，从机只能接受。如果产品是和自研网关配合，记得在网关侧把连接参数设计好；如果是要兼容别人的主机，可以配置从机请求更新连接参数，但不是所有主机都会理你。
3.3 外设往往比射频更耗电：传感器与Flash的功耗画像
我见过太多团队死磕广播间隔和发射功率，却忽视了板上传感器和Flash才是真正的电老虎。
很多数字传感器标称"工作电流1毫安"，但如果你让它一直上电、一直测量，它比BLE射频还费电。正确做法是用一个GPIO当开关，给传感器单独供电。只在采样前的10毫秒内上电，采完立刻断电。这个操作可以把传感器的平均电流从几毫安降到几微安。
Flash写入更是典型的"毫安级短脉冲"。一次页擦除加写入可能要消耗10到20毫安，持续几到几十毫秒。如果每一条日志都立刻写Flash，平均电流会被拉得很高。我通常把数据先缓存在RAM里，攒够一整页再一次性写入，写完后立即把Flash切到深度掉电模式。这个看似简单的改动，经常能省下几十微安的平均电流。
还有一类坑是I2C上拉电阻。传感器断电后，如果I2C上拉电阻还挂在VCC上，上拉电阻到传感器引脚之间可能形成漏电路径，电流虽然只有几微安，但在睡眠状态下占比不小。设计时我倾向于把传感器电源控制和I2C上拉一起考虑，要么上拉电阻也受同一个GPIO控制，要么确保传感器在断电时引脚处于高阻态。
4. 自有制造兜底：产线校准、一致性与功耗筛选
我在文章开头说过，研发样机功耗低不算本事，量产一百台都低才算。蓝牙模块的功耗优化，离开了制造环节的兜底，就是一座随时可能塌的沙塔。传统的购买公版模块方案，你能做的就是"选一个宣称低功耗的模块"，至于模块里的校准参数、天线匹配状态、物料批次一致性，你全都控制不了。而自有制造的最大优势，就是能在产线上用自己的测试体系，把每一台设备的功耗和射频参数都兜住。
这一章讲产线上实际怎么落地。
4.1 研发样品能跑，不代表产线每台都能跑
我第一次做量产功耗抽检时，发现一个很扎心的现象：研发阶段的十台工程样机，待机电流都在1.5微安左右，非常漂亮。到了小批量试产，待机电流的分布拉得很开，有三分之一的板子超过3微安，个别甚至到8微安。
逐台排查下来，原因五花八门：有的板子在清洗后助焊剂残留导致微短路，有的电容来料批次绝缘电阻偏低，有的SoC内部LDO配置在烧录时被意外改过，还有的板子GPIO悬空引脚在程序里没配成输入下拉，导致漏电。
这些问题的共同点是什么？都不是设计上的致命错误，而是制造过程中必然出现的随机波动。没有产线测试兜底，这些"小毛病"就会变成用户的续航投诉。所以我在产线上坚持做整机功耗筛选，而不是只在研发阶段测一台样机。
4.2 产测项目怎么设计才能兜住功耗
产线测试不可能像实验室那样精细，但有几道测试是必须加的，缺一不可。
首先是烧录后的静态电流抽测。整机烧录完成后，不进老化，先在功耗分析仪上测一遍睡眠电流。这道测试能发现大部分漏电和配置问题。标准可以定在产品平均值的上限，比如目标3微安以内，超过的直接返修。千万别小看这一步，一台多3微安的设备，在220毫安时电池下会少活一年多。
其次是射频校准。每一台设备都要做发射功率校准和频偏校准。PA的增益在不同芯片之间本来就存在离散，温度也会影响频率精度。通过生产校准，把每台设备的功率和频偏调到目标范围内，既能保证通信质量，也能避免"为了凑合弱天线而被迫提高发射功率"这种隐性功耗浪费。
最后是高低温抽样。我通常会在每批产品里抽几台，放到-20度和55度下测待机电流和发射功率，看有没有温度敏感的物料混进来。这个测试不用全检，但能提前预警来料批次问题。这里多说一句：产测数据一定要带序列号存数据库。后面售后如果出现某批设备功耗异常，能直接回溯到产线数据，判断是批次物料问题还是测试设备漂移。
4.3 天线匹配一致性：射频功耗的制造变量
天线匹配是无线产品里制造一致性最脆弱的一环。PCB板材的介电常数有公差，电容电感有精度，结构件和电池靠近天线的位置有装配误差，这些都会让天线的谐振频率发生偏移。
同样的匹配网络，不同供应商的同一规格电容，在2.4GHz下的表现可能差得远。我们在一个项目里遇到过：贴片电容换了一个供应商，标称值都是1pF，但实际在2.4GHz下的等效串联电阻不一样，匹配损耗多了将近0.5dB。0.5dB听起来不大，但如果你的产品对续航极其敏感，这就是白白多耗的电流。
所以射频匹配电路在设计阶段就要预留调焊盘，典型做法是π型网络，保留串联和并联电容位置，产线调试时可以通过更换元件把阻抗调回目标。如果产能和成本允许，射频部分每台都做校准是最好的。不能每台校准的话，至少每批抽取前几台，用网络分析仪看S11，或者直接测整机灵敏度。
结构件的影响也要提前验证。很多产品塞进外壳之后，天线谐振频率会偏几十兆赫，辐射效率和接收灵敏度双双下降。我遇到过最夸张的一次，外壳里有一根金属加强筋正好压在天线净空区上方，整机灵敏度掉了5dB，设备为了维持连接不断重传，平均电流翻了一倍。这种问题在研发阶段不用整机做一次射频测试，根本发现不了。
5. 一次实测复盘：平均电流从32微安降到8.7微安的完整过程
前面讲了一堆原则，这一章用一个我最近跟进的模拟项目——某款BLE温湿度记录仪——把排查和优化流程完整走一遍。这个项目最初的平均电流是32微安，目标是压到10微安以下，电池是一颗240毫安时的锂亚电池，客户期望续航两年以上。
按32微安算，240毫安时的理论续航约是8500小时，不到一年。所以这个问题不解决，产品连交付门槛都过不去。
5.1 电流波形上的毛刺，一顿定位排查
拿到样机后，我没有急着改代码，而是先在功耗分析仪上挂了24小时。电流波形显示，大部分时间设备确实在深度睡眠，底电流约3微安，很干净。但每隔30秒，就会出现一个持续约20毫秒、电流平均8毫安的尖峰，尖峰里还套着两个小峰。
第一个怀疑对象是温湿度传感器。看代码，传感器每30秒唤醒一次，模块上电后要等待稳定，然后连续做两次测量，再通过I2C读取，整个过程大约15毫秒。我把传感器供电引脚用飞线断开，波形上的第一段尖峰消失了，坐实了传感器是第一个罪魁祸首。
第二个小峰在传感器数据读取之后出现，高度更高、持续时间更短。我顺着代码查，发现每次采样完成后，程序会把一条带时间戳的记录写入外部Flash。Flash擦写就是那个更高更短的第二段尖峰。到这里，两个元凶都定位了。
5.2 每一项优化各自贡献了多少微安
定位之后，我做了几个硬件和固件改动，每改一步都在功耗分析仪上重新测至少一小时，记录平均电流的变化。
第一项：传感器供电改GPIO控制。原来传感器始终由主电源供电，现在改成采样前10毫秒才开启，采完立刻关闭，同时把I2C总线上拉电阻也改由同一GPIO控制，防止断电漏电。这一项优化后，平均电流降了约9微安。
第二项：Flash写入合并。原来每30秒写一条12字节记录，Flash擦写一次耗电很大。我改成在RAM里攒够16条再一次性写入，并且只在整页写入时消耗一次擦写电流。这一项降了约8微安。
第三项：广播和连接参数调整。这个产品平时是被网关主动连接的，原来的连接间隔是30毫秒，Latency为0。我们和网关端协商，把运行时的连接间隔改成60毫秒，Slave Latency设为4，数据上报改为事件触发，不要求秒级实时。这一项又降了约5微安。
第四项：射频匹配微调。在暗室对比测试时发现，有一批板子在0dBm下的实际辐射效率比研发阶段低1.8dB，原因是外壳结构件离天线太近。我们在匹配网络里调整了一颗并联电容，把失配拉回来，同时把产线校准的目标从0dBm调整到+0.5dBm，保证整机等效辐射功率不降。这一项没有直接让平均电流下降，但它避免了重传率上升带来的隐性电流上升。在重传率从8%降到2%之后，平均电流又降了约1微安。
做完这四步，平均电流落在8.7微安，240毫安时的电池理论续航约2.7年，达到了客户的预期。
5.3 这套排查流程，你可以直接抄走
复盘下来，真正有价值的不是那几个参数，而是排查的顺序：
第一，先看波形，再动手改。没有24小时的电流曲线，你连问题出在哪都不知道。很多工程师上来就调广播间隔，属于打地鼠。
第二，按"硬件漏电、外设功耗、射频功耗、协议功耗"的顺序挨个排除。硬件问题不解决，后面改协议全是白费。
第三，每次只改一个变量，改完至少测一个完整周期。同一个周期内同时改三个地方，你永远不会知道哪个改动真正有效。
第四，把产线抽测数据拉出来看分布。如果只盯着研发样机，你永远不知道批量制造里的功耗方差有多大。这台记录仪在产线上后来加了一道睡眠电流全检，超过12微安的板子直接隔离，那些板子主要是传感器上电时序和电容漏电问题，修完之后整批平均电流稳定在9微安以内。
6. 边界在哪：功耗优化不是无脑压低所有参数
做了几年低功耗产品，有个体会越来越深：功耗优化做过头，比不做更危险。低功耗是一个系统约束，不是唯一目标。为了省几个微安，把可靠性和通信余量全部牺牲掉，最终会在售后数据上付出更大的代价。
这一章聊聊我理解的边界。
6.1 射频功率过低，反而会让电池死得更快
很多入门工程师一看发射电流随发射功率上升，就想把TX Power调到最低档，觉得这样一定省电。这在实验室里看单次发射确实省了，但在真实环境里不一定。
链路余量不足，数据包在远一点的地方就解不出来，设备于是不断重传。重传一次，射频事件就多一次，平均电流反而上去了。我们实测过：某个标签设备把发射功率从0dBm降到-8dBm，单次发射电流降了约3毫安，但在15米距离上的重传率从2%涨到20%以上，整机平均电流反而从12微安涨到18微安。你说这是省了还是费了？
我的经验是：先根据产品最远通信距离和路径损耗算链路预算，留出至少6到8dB的余量，再定最低发射功率。不要为了省电牺牲掉最基本的通信可靠度。
接收窗口也是一样的道理。Slave Latency调太大、接收窗口压太窄，主机发的包经常错过，就会触发重传机制。重传的电流开销，远大于你省下来的那点接收电流。协议参数的设计要基于数据到达率和延迟要求来定，而不是单纯追求数字好看。
6.2 电池自身的脾气比你想的多
最后说一下电池这个"被动的耗电参与方"。
纽扣电池和软包锂电池的可用容量，和放电电流强相关。CR2032在微安级负载下能放出220毫安时，但在20毫安脉冲负载下，实际可用容量可能只剩60%到70%，而且内阻会造成明显的电压跌落。如果设备的事件峰值电流太高，容量再大也没用，因为电压在脉冲期间就塌了。
我见过一个项目，把电池从CR2032换成同尺寸的锂锰电池，容量差不多，但脉冲负载能力好很多，设备不再出现射频事件期间复位的情况。这提醒我：做低功耗设计时，一定要把电池的脉冲放电曲线拉出来看，不能在平均电流的数字上自嗨。
温度对电池的影响同样被严重低估。锂亚电池在低温下电压平台会下降，内阻会增大，设备低温通信距离变短、功耗升高，经常被误判为射频问题。我们后来在低温测试规范里明确规定：-20度环境下的待机电流测试，必须用在该温度下平衡过的电池，否则测出来的数据会误导整个优化方向。
6.3 我保留的一个习惯：给功耗预算留"负数裕量"
聊到这儿，我想把最后一个习惯分享出来：功耗预算表里，我不光算平均值，还会算"最差情况"和"期望情况"两个版本，并且用最差情况来定电池容量和保质期。
最差情况包括：睡眠电流取产线分布的95分位、射频事件重传率按满载场景估算、传感器每次转换时间取上限、电池容量按数据手册最小值再打八折。算完如果还能满足续航目标，这个产品才有底气说自己在极端场景下不至于翻车。
如果算下来最差情况超标，我会优先回到制造端找答案：是不是待机电流的分布太宽？是不是天线效率的一致性太差？通过产线筛选把分布收窄，比在固件里拼命压参数要靠谱得多。自有的制造能力在这里就是最后一道保险：你有能力校准、筛选、返修，才有资格对客户负责任。
这几年做下来，我的体会是：蓝牙模块功耗优化从来不是某一个工程师、某一份代码、某一颗芯片的独角戏，而是硬件设计、协议栈配置、制造测试和电池选型共同配合的结果。一个产品能不能把标称续航兑现给用户，关键看你在研发阶段有没有把"制造端的不确定性"提前纳入设计，并在产线上真正兜住它。
