企业官网建设流程全解析

我做的第一版宠物摄像头，原型机跑起来其实很欢乐：能抓拍、能识别、能推送，结果一算续航，3000mAh电池只撑了不到4天。客户说“这哪是AI摄像头，这是血汗工厂监控”。后来我把这个项目从头拆了一遍，从芯片选型、电源树设计、算法链路到系统休眠，一步步把平均功耗压下来，最终同样是3000mAh电池，续航做到了50天左右。这篇文章想把这套“从芯片、算法到系统”的低功耗设计思路完整写出来，给正在做或准备做电池供电类AI摄像头产品的朋友一个参考。

AI摄像头低功耗设计这件事，最容易踩的坑就是只盯着某一个环节：有人觉得换个低功耗芯片就完事，有人天天调模型精度的同时根本不管NPU在算的时候吃多少电流。实际情况是，芯片、算法、系统三个层面互相牵扯，任何一个环节偷懒，整机续航都会立刻给你颜色看。下面我就按项目推进的顺序，把每个阶段的决策逻辑、实测数据和踩过的坑一起说清楚。

1. 场景决定设计：宠物AI摄像头的低功耗需求从哪来

1.1 用户买的不是摄像头，是“安心感”

先别急着谈芯片参数，得先想清楚用户到底拿这个设备干什么。宠物摄像头的核心场景基本是：主人出门上班或出差，想知道猫粮有没有吃完、猫砂盆附近有没有异常、狗狗有没有拆家、猫咪今天有没有精神问题。用户要的不是7×24小时无间断录像，而是“关键事件发生时，设备能识别出来并告诉我”。

这个判断直接改变了整个产品的技术路线。如果按“持续录像+云端分析”来做，功耗根本压不住；如果按“事件驱动的本地识别+按需联网告警”来做，低功耗就有解。所以我们把产品定义成三件事：平时待机监听、检测到异常时快速识别、确认后推送一段短视频或抓拍图。目标续航按“充电一次用一个月”来定，这样用户出差一周，设备也能撑得住。

1.2 从电池容量反推平均功耗预算

做低功耗设计，第一件事不是画原理图，而是算一笔“功耗预算账”。我拿3000mAh的单节锂电池举例，3.7V标称电压，实际可用能量大约11Wh。如果目标是30天续航，平均功耗预算就是11Wh除以720小时，约15mW，换算成平均电流大概是4mA左右。

4mA听起来很宽松，但这里有个陷阱：设备在工作瞬间的电流是几百毫安甚至安培级，不可能用平均电流去衡量瞬时行为。所以正确做法是把设备拆成多个工作状态，每个状态单独记电流和时长，再用“各状态电流×时间占比”累加，看最终日均消耗能不能落在预算内。

这是我做所有低功耗产品都坚持的第一步。很多团队上来就选芯片、调模型，结果整机做出来发现续航差一大截，再回头算账，往往问题就是出在“某个状态的占比比预想高得多”。

1.3 三类核心业务的功耗画像

宠物摄像头的业务大体可以分成三类：待机监听、事件识别、联网上报。

待机监听是占时间最长的状态，必须做到微安级。这里用的是PIR人体红外传感器加上MCU的低功耗定时唤醒，成本低、电路简单、待机电流只有几个微安。事件识别状态比较短，一般只有几百毫秒到几秒，但电流高，涉及摄像头传感器上电、图像采集、NPU推理。联网上报最凶，Wi-Fi模组一发数据就是几百毫安，好在我们可以把单次上报时间压缩到两三秒以内。

三类业务的功耗画像可以用一个表格表示：

这样算下来，待机+事件识别+AI推理一天的消耗也就几毫安时，真正的大头是联网上报和实时预览。所以设计重心很快清晰了：AI推理不能频繁跑，联网上报必须克制，实时预览只允许用户主动打开时才启用。整个低功耗策略都是围绕这三句话展开的。

2. 芯片层的关键决策：主控选型、协处理器分工与电源域

2.1 先算待机账，再选主控

选主控时最常见的问题是“什么芯片算力强选什么”，但对电池设备来说，算力强往往意味着待机功耗高。我评估过三类方案：

一类是STM32F103C8T6这类传统MCU，最小系统板很便宜，上手快，生态资料多。它在停机和待机模式下能做到几十微安级别，对于“只做控制、不跑AI”的定位完全够用。缺点是算力有限，跑不了像样的神经网络模型。

另一类是ESP32系列，自带Wi-Fi/BLE，可以跑轻量级模型，性价比非常高。但它不是专用低功耗芯片，跑Wi-Fi时电流不低，必须在系统层面做好电源管理。

第三类是RK3588这类带NPU的SoC，算力强，能做宠物识别、行为分析等复杂AI功能，但它的常态功耗和瞬态功耗都很大，基本只能做插电产品，或者搭配大电池和快充，不适合纯电池供电的小型设备。

我的结论是：重新做一款纯电池供电的宠物AI摄像头，优先考虑系统级方案，也就是一颗超低功耗MCU做主控，专门负责待机、外设管理和唤醒逻辑，再加一颗负责图像采集与AI推理的视觉协处理器。MCU睡到深睡模式，整个待机电流能压到10微安以下；视觉协处理器平时完全断电，需要时才上电工作。

2.2 视觉协处理器架构的省电逻辑

我在项目里评估过BR100这一类的低成本视觉协处理器芯片，它的套路和通用SoC不一样：内部往往集成一个Cortex-M级别的核，加上硬件图像采集接口和一些加速算子，最关键的是它把“待机—唤醒—推理—再待机”这条路径优化过，切换时间短，空闲时功耗极低。

这类芯片看手册时，第一件事不是看算力有多少TOPS，而是看三组参数：深睡待机电流、从深睡唤醒到第一帧图像可用的时间、工作时从摄像头传感器取图的整体功耗。我测过一些方案，唤醒到出图能压到几十毫秒，这就够了，因为PIR触发后用户根本感知不到这点延迟，而每次唤醒省下的时间都以电流积分的方式体现在续航数据里。

当然，BR100这类芯片也有明显短板：生态相对封闭，文档少，调试工具弱。如果你团队里没有能啃芯片手册和寄存器的人，建议先用成熟平台跑通业务逻辑，再评估换低功耗视觉协处理器。

2.3 电源树设计：USB-C充电、电池直供与负载开关

电源树是整个低功耗设计的地基。我习惯把电源域分成三块：常开域、受控域、开关域。

常开域只给MCU待机唤醒电路和实时时钟供电，用一颗静态功耗极低的LDO就行，整体电流控制在微安级。受控域给摄像头传感器、AI芯片、SD卡等供3.3V或1.8V，由MCU的GPIO控制负载开关，平时断电，工作时才上电。开关域给Wi-Fi模组和红外补光灯这些大功率外设，直接用MOS管做开关，减少在路静态电流。

这里有个非常容易踩的坑：有的工程师习惯用TPS5430这类降压芯片给整套系统供电。TPS5430本身是颗不错的DC-DC，但它最低输入电压是5.5V，电池供电设备如果用单节锂电池，电压范围是3.0V到4.2V，根本驱动不了它。这种芯片适合12V或24V适配器输入的场景，拿来给电池产品供3.3V就是选型错误。

电池充电部分，我们用的是TP4054这类线性充电芯片，充电电流设到300mA到500mA，发热可控，成本低。需要注意的是，USB-C接口的线缆质量会影响充电电流，劣质线经常因为没有E-Marker芯片导致电流协商不正常，表现为充一天都充不满，这会间接影响用户体验。量产时要对随附充电线做兼容性验证。

2.4 快速冷启动与低功耗启动链

芯片工作之后，下一步要解决的是“怎么从待机快速进入工作再快速睡回去”。很多通用SoC的启动流程很长：bootrom启动、DDR初始化、加载内核、启动应用，整套下来几秒钟，这对于低功耗设备来说是不可接受的。

低功耗设备不能走这个流程，标准做法是“不真正关机”。MCU一直保持低功耗运行，PIR触发后立刻唤醒摄像头和AI芯片，AI芯片从保留RAM的恢复模式唤醒，跳过大部分初始化，几百毫秒内就能出结果。整套唤醒链路是：PIR中断唤醒MCU、MCU打开摄像头电源和视觉芯片电源、视觉芯片初始化摄像头并抓帧、完成本地识别、关掉视觉芯片、MCU决定是否需要联网上传。

这套链路跑熟之后，单次事件从触发到AI得出结果的平均时间可以控制在1秒以内，其中大部分时间耗在摄像头传感器的自动曝光和Wi-Fi模组启动上。如果AI结果不需要上报，设备会再次进入深睡，整个过程的平均功耗就会很漂亮。

3. 算法层：用“事件驱动”把AI从穷算变成精算

3.1 7×24小时全帧推理是最大的功耗浪费

刚做AI摄像头的人最容易犯的错，是把训练好的模型直接接到视频流上，每一帧都推理。头几次demo效果确实好，猫一进门屏幕上就能框出来，但功耗报表一拉，AI推理模块一天运行几万次，电池根本扛不住。

这里要明白一个事实：宠物场景里99%的时间是没有事件发生的。猫在睡觉、狗在发呆、家里空无一人，这些帧都拿去推理就是在白烧电。正确思路是“先用便宜的方式筛选，再用AI做精识别”，把高功耗的AI推理放到已经确认有异常的帧上。

这也是算法层低功耗设计的核心思想：不要把AI当第一道关卡，而是把AI当最后一道精检关卡。前级的PIR红外和图像差分都是微安和毫安级别的操作，它们的任务是减少AI的启动次数。

3.2 两级/三级事件链路：PIR、帧差、AI识别

我的做法是把事件链路拆成三级：PIR触发、图像差分确认、AI精识别。

第一级PIR最便宜，功耗微安级，但它有个问题，对静止目标不敏感。猫蹲在食盆前一动不动，PIR可能不触发。所以第二级我用图像差分兜底：每隔100到200毫秒抓两帧灰度图，求差的绝对值，超过阈值的区域合并成运动块，有运动块才进入下一步。这一步只要摄像头传感器周期上电，单次成本只有几十毫安和几十毫秒，比AI推理便宜一个数量级。

第三级才是AI模型。图像差分确认有运动后，把当前帧送进轻量化分类或检测模型，模型判断是人还是宠物、宠物在做什么动作。确认有异常事件才唤醒Wi-Fi上传。这套链路下来，AI单日运行次数从几千次降到几十次，日均AI推理功耗直接缩到1mAh左右。

3.3 轻量化模型的量化剪枝与算子搜索

即便AI调用次数已经很少，模型本身的单次推理功耗仍然值得优化。模型优化我按两条线走：一条是模型压缩，一条是算子选择。

模型压缩三板斧是量化和剪枝加蒸馏。我们在RK3588平台上试过把FP32模型转到INT8量化，模型体积缩小到原来的四分之一，推理速度提升，实测算力功耗也降了将近一半，精度损失控制在1%以内。剪枝则是把模型里贡献度低的通道去掉，这个流程可以用结构化剪枝工具做，效果取决于模型冗余度，常规分类模型剪掉20%到30%的通道一般不会掉精度。

算子选择这块不少人会忽略。同样的卷积操作，不同芯片支持的指令集和算子库实现可能差很多。我在配置模型时会把所有算子逐层列出来，对每一层用推理时间评估跑分，再用类似于二分搜索和贪心搜索的思路，逐层尝试替换算子，找到满足精度、帧率和功耗三者平衡的组合。这个“算子组合搜索”的过程看起来繁琐，但往往能让单次推理功耗再降20%到30%。

3.4 动态帧率与ROI：少算一帧是一帧

模型优化完之后，还能从“计算负载”角度继续抠功耗。动态帧率是必然用法：没有事件时，图像差分只要1fps就够；一旦检测到运动，立刻切到10fps或15fps进行跟踪和二次确认。

这里有个从信号与系统里学来的基本概念可以帮我们减少无效算力：宠物动作的显著变化通常在几赫兹量级，5fps到10fps足以捕捉“突然跑动”这类事件，没必要全天用25fps或30fps。高帧率只在用户主动打开实时预览时才开启，而且预览画面建议做成标清而不是高清，省流又省电。

ROI区域检测也很有用。大多数宠物摄像头的画面里，真正有信息量的区域是食盆、猫砂盆、窝这些固定位置，背景和天花板全是无效区域。我们在图像差分阶段就只处理ROI区域，AI模型也只对ROI区域做检测，计算量能再降一半。整套做下来，单次事件的算力消耗明显下降，而且检测效果没有变差。

3.5 让功耗跟着电量走：增量式调参思路

最后再从算法策略上分享一个让设备“越没电越省”的思路。传统做法是灵敏度固定，结果往往是电量低了设备还一直高频工作，续航崩得特别快。后来我把功耗调节做成一个闭环，参考增量式PID算法的思路，不直接大幅改变参数，而是每次只微调一个量。

具体来说，把检测灵敏度作为执行器，把剩余电量作为被控量。电量充足时，PIR阈值低、差分阈值低、AI识别频率高；电量低于30%后，每10分钟微调一次阈值，适当增大差分触发门槛、减少上报次数、把红外补光灯亮度调低一档。用“增量”方式调节是为了避免震荡，比如上一轮已调低了灵敏度，这一轮只在那个基础上再微调，而不是突然把检测关掉。

这套策略在实测里效果非常明显：电量从30%降到5%的过程中，设备依然能工作，虽然事件报告变少了，但至少关键时刻能保住一次抓拍，用户不会彻底失去对设备的掌控。

4. 系统层：RTOS调度、休眠状态机与唤醒链路

4.1 裸机能跑，但低功耗必须依赖统一调度

很多MCU开发者习惯裸机while循环加中断，这种模式做简单外设控制没问题，但一旦要同时协调PIR中断、摄像头初始化、AI芯片通信、Wi-Fi状态机和看门狗，很容易出现事件优先级混乱，导致某些外设忘了关、某些线程空转，功耗自然失控。

我把代码迁到FreeRTOS上之后，最大的收益不是“多任务并发”，而是能用节拍管理来做统一的空闲处理。FreeRTOS的tickless模式可以在系统空闲时停止SysTick，改用低功耗定时器计时，MCU自动进入睡眠，唤醒后继续执行。系统的空闲钩子函数里，我会做一次“外设体检”，检查摄像头、Wi-Fi、视觉芯片是否都已断电，如果有外设没关就自动关掉。

环境准备这一步没什么高科技，但容易翻车。比如在STM32CubeMX里配置工程时，需要先安装对应的芯片支持包，我当时装F1系列和L4系列的包时因为版本不对折腾了半天。芯片包安装好之后，记得确认FreeRTOS的tickless模式和低功耗定时器配置正确，否则编译能过，功耗却一点没降。

4.2 用状态机把功耗“切”成几个档位

系统软件层面，我维护了一个低功耗状态机，把设备明确切成四档：深度睡眠、轻度睡眠、活动空闲、活动繁忙。

深度睡眠时，主控MCU进入深睡待机，只有PIR中断和一个低频定时器在跑，整机电流微安级。轻度睡眠时，MCU部分外设时钟关闭，但RAM保持，摄像头和AI芯片仍断电，可以快速响应定时任务。活动空闲是指设备刚被唤醒，正在做图像差分或网络连接，电流几十到几百毫安。活动繁忙则是AI推理或视频上传进行中，电流最高。

每个状态定义了三件事：进入条件、退出条件、最长停留时间。最长停留时间特别重要，防止设备因某个外设卡住而一直停留在高功耗状态。比如Wi-Fi连接如果超过5秒没成功，立刻断开重试，不能死等。状态机另外配合一个超时看门狗，任何情况下超过允许时间都会强制回退到浅睡档。

4.3 外设电源域与网络模组的“用前上电、用后断电”

系统层还得管住外设的电源。摄像头传感器、AI视觉芯片、Wi-Fi模组、红外LED补光灯，这些外设各自都带功耗，不能在整机工作时全部同时待命。

摄像头传感器的控制逻辑是“上电抓帧，抓完断电”，单次使用时间控制在最短。AI视觉芯片平时完全断电，只有在差分确认有运动后才上电。Wi-Fi模组是最耗电的，功耗最高的状态就是保持长连接，所以不能让Wi-Fi一直在线，而是采用“长心跳”机制，平时完全关闭或进入Power Save模式，省得随时随地收包唤醒。

红外补光灯这块也提个醒：大功率红外LED不能直接从MCU引脚或主控芯片供电，一定要用专门的LED驱动芯片，并且用PWM控制亮度。否则单个灯珠的电流就能把整机功耗拉上去，还会发热。我测过，同样的补光效果，用专驱芯片比用简单限流电阻方案整机功耗能低十几毫安。

4.4 日志、OTA和调试口：隐蔽的功耗漏洞

系统层还有一个很容易被忽视的地方：调试用的日志输出。开发阶段大家习惯在串口打日志，这没问题，但产品固件里如果没关掉printf，一个高频串口输出就能把整机功耗拉高几十毫安，放在低功耗设备里就是致命的。

我的做法是在编译时定义日志宏，量产固件直接不编译日志代码，从源头杜绝。OTA也一样，固件下载期间功耗很高，而且下载过程中如果断电可能导致变砖。所以系统里必须做电量检查，电量低于30%时禁止OTA，等到设备充电时再恢复。

调试阶段的实时预览功能也要做权限控制。宠物摄像头实时预览非常耗电，如果设计成用户一打开App就自动开启摄像头，整机电流能飙到400mA以上，连续预览一小时就没电了。我建议把实时预览做成“用户主动点击才启动”，并且启动后超过10分钟无操作自动关闭，这既保续航又不会影响体验。

5. 实测数据：一块3000mAh电池从4天到50天的调优记录

5.1 电流测量方法：别急着优化，先学会测

功耗优化的前提是测得准。测电流的仪器选择很关键，普通万用表的分流电阻会引入额外压降，低功耗电流uA级别时根本测不准。我在项目里用的是带高精度电流采样功能的功耗分析仪，配合示波器看瞬态电流波形。

如果条件有限，也可以用万用表串联测量+RC低通滤波取平均值，虽然看不到瞬态波形，但对整机日耗电估算够用了。真正调试时，我习惯接上功耗仪跑一整晚，第二天看分时电流曲线，哪个时间段电流异常偏高一眼就能看出问题。第一版样机就是这么暴露问题的：晚上18点到22点，摄像头被红外补光灯反复触发，AI频繁启动，电流曲线像锯齿一样，功耗惨不忍睹。

5.2 优化前的功耗分布

第一版样机我犯的典型错误是“全帧AI检测”：摄像头每3秒抓一帧，直接把每一帧送进AI模型做宠物识别，模型在RK3588上跑一次大约150ms，每次推理都是几百毫安级别的电流消耗。再加上Wi-Fi保持常连，串口调试日志一直开，整机日耗电接近800mAh。

用3000mAh电池实测，3天半到4天就没电了，完全不符合30天续航目标。这版功耗分布大致是：AI推理贡献了约40%，Wi-Fi常连贡献了约30%，摄像头周期曝光贡献了20%，剩下的是调试日志和其他外设。这个分布让我意识到，只换芯片不砍算法，根本救不回来。

5.3 三版迭代的关键改动与实测对比

第二版开始上事件驱动。PIR触发后再启动图像差分，差分确认有运动才做AI推理，Wi-Fi从常连改成按需连接。这一版砍掉了80%以上的AI调用次数，日耗电从800mAh降到180mAh左右，续航从4天提到了16天。

第三版做了三件事：摄像头周期曝光频率降到1fps、AI模型INT8量化+剪枝、ROI区域检测。日耗电进一步从180mAh降到45mAh。第四版又加了动态帧率、OTA低电量保护、关闭调试日志、外设独立断电，最终日耗电稳定在38mAh左右，3000mAh电池实测续航超过70天，平时使用环境下50天很稳妥。

这里要说清楚，70多天只是实验室理想值，用户家里Wi-Fi信号弱、红外补光灯频繁启动、猫的活动量大的时候，续航会降到30到50天。但即便如此，和第一版的4天相比，已经完全满足“充电一次用一个月”的产品目标了。

5.4 两次失败尝试：降频和云端识别

优化过程中我试过两个方向，最后都推倒重来，写出来给大家避坑。

第一次是把MCU主频从240MHz降到80MHz，以为降低主频就能降低功耗。实测AI推理时间从300ms涨到1100ms，设备活跃时间翻了将近4倍，整体功耗反而升高了。低功耗不是单纯低频，处理器只有在高频“尽快睡回去”的情况下才是低功耗，降频只适用于非实时性任务。

第二次是“本地算力不够就传云端识别”。我在很长一段时间里试图把视频帧推到云端服务器做AI识别，结果Wi-Fi模块一传数据就是几百毫安，一张图的传输时间比本地推理还长，网络延迟高，个人数据传到云端也带来隐私问题。后来我彻底接受“端侧小模型能干什么就干什么”的定位，本地能做的事件绝不依赖网络。

6. 从样机到量产：产线上容易翻车的低功耗细节

6.1 芯片选型要留“备胎”

低功耗芯片往往集中在少数几家供应商手里，尤其是视觉协处理器这类小众芯片，供给波动影响很大。我在选BR100这类协处理器时，一开始就看有没有第二供应商。哪怕功能有一定差异，至少引脚和驱动层面要在设计时留好兼容接口，不然后期芯片缺货，整个产品线都会被卡住。

另外一个选型教训来自一次项目里的乌龙：有工程师按关键词搜“摄像头芯片”，买回来一颗TPLO501，翻芯片手册才发现是数字电位器，根本连摄像头接口都没有。选型第一件事永远是看芯片手册的功能类别、封装、电源电压和通信接口，不能光看关键词和标题，不然打样时才发现型号错了，浪费的就不只是几颗芯片的钱，还有整个迭代周期。

6.2 电源芯片不是降压就行：TPS5430与锂电池的兼容性

电源芯片的选型在量产阶段最容易出问题，举TPS5430的真实例子。这颗芯片在很多AC-DC适配器、车载电源方案里用得很多，输入电压范围5.5V到36V，输出电流能到3A，性价比很高。但如果你拿它做单节锂电池供电的宠物摄像头，输入电压根本不够，因为锂电池满电才4.2V，放电到3.0V之后还在正常工作，TPS5430完全启动不了。

正确的做法是分场景选型：如果是纯电池供电，用低静态电流的LDO给MCU供电，用DC-DC Buck-Boost或低压差升降压芯片给摄像头和AI芯片供3.3V。如果是适配器供电、电池只做备份，那TPS5430这类高压降压芯片才有发挥空间。电源芯片这一项选错，后面整个电源树都要返工，所以前期的电源需求要写清楚。

6.3 Flash磨损、老化测试与待机电流抽检

量产还有几个看不到的“防不胜防”的低功耗问题。比如日志频繁写入Flash，不仅磨损存储，还会在写入瞬间拉高电流。我的做法是日志先缓存在RAM里，攒够一定量再批量写入，减少写入次数，也让平均功耗更稳。

老化测试阶段，低功耗产品一定要做“待机电流抽检”，不能只看功能是否正常。我见过一批次产品功能全部正常，但因为某颗LDO批次性静态电流偏高，整机待机电流比正常批次高出3倍，用户收到后续航明显缩短。待机电流抽检很简单，老化后抽几台设备，用功耗仪测深度睡眠状态电流，超出规格书范围就整批排查。工厂产线如果有MES系统或WMS系统，可以把每台设备的待机电流数据记录在案，后续追溯到具体批次和物料，排查效率高很多。

量产最后一道关卡是“每台设备的缓存数据不落地”。有些团队在产测时会把测试数据写进Flash，设备出库后这些数据还在Flash里，日积月累会侵占存储空间并影响写入功耗。产测完成后要执行一次“出厂复位”，清空测试数据。

7. 复盘：我在这类项目里沉淀下来的几条原则

7.1 功耗是算出来的，不是省出来的

做低功耗AI摄像头，最容易犯的错就是“先做功能，再想续航”。功能做得越花哨，后期砍功耗越痛苦。正确的顺序是立项第一天就立一个功耗预算，然后把平均电流公式写清楚，每个状态的目标电流、目标时长、每日次数都列出来，后面所有芯片选型和架构设计都对照这张预算表做取舍。

芯片选型不能被算力参数带跑，要看它在真实工作流里的平均功耗。算法调优不能被mAP指标带跑，要看它一次推理要花多少毫秒、多少毫安。系统设计不能被功能需求带跑，要看每个功能是否值得它消耗电池能量。把“平均功耗=各状态电流×时间占比之和”这个公式时刻记在脑子里，产品方案就会清晰很多。

7.2 平均功耗公式是贯穿项目的主线

我这套项目做下来，最深的体会是：低功耗设计不是一个专项，而是一种贯穿芯片、算法、系统三个层次的思维方式。芯片层决定了功耗地板，算法层决定了高功耗模块的调用频率，系统层决定了外设的管理效率。三者必须同时在线，缺一个环节，续航都做不起来。

7.3 最后分享一个最笨但最有效的方法

最后一个建议可能听起来很土，但效果最好：每次改完一版固件，都别凭感觉说“功耗应该降了”，而是老实接上功耗仪跑一个晚上，看分时电流曲线。那条曲线比任何估算都诚实。我V3到V4的很多优化细节，就是从夜里的电流曲线上发现的。

最典型的例子是红外补光灯。我一开始觉得补光灯只在晚上工作，耗电无所谓，结果曲线显示它在夜里每隔十几秒就启动一次，一整晚累计下来吃掉了几毫安时。后来我把补光灯触发逻辑改成“差分确认有人或宠物出现在ROI区域才开灯”，红外补光灯的启动次数降了90%，整机续航又上一个台阶。老老实实看曲线，远比拍脑袋优化管用。