智能手表功耗建模与分析¶

功耗分析可以根据预计的日常使用情况估算续航；更重要的是，它能按耗电贡献，排出值得优先优化的负载顺序。本页以提供的智能手表功耗分析工作簿（英文版）为例，说明如何计算各使用场景的每日耗电量（mAh）、找出功耗预算中的主要负载，并将表格模型转化为可执行的测量计划。

关于系统架构和固件层面的低功耗设计，请结合低功耗概览阅读；关于如何验证模型，请参阅功耗测量与验证。

智能手表系统概览¶

先明确模型的系统边界。本工作簿对应一款由电池供电的智能手表，其中包括 MCU、AMOLED 显示屏、振动马达，以及一个未拆分的 Other（其他）负载类别。工作簿没有给出屏幕尺寸、分辨率、亮度设置、无线架构或各个传感器的具体信息。下表中的显示电流是工作簿输入值，应视为模型假设，而不是实测工作点或特定面板的规格。Other 表示尚未单独归类的负载，不代表某一个具体器件。

按场景分析功耗¶

场景是完整的用户行为或系统事件，并非单个器件独立工作。例如，一次消息通知可能唤醒 MCU、点亮 AMOLED 显示屏、驱动振动马达，并使后台负载保持活动。源模型中每个标记为 Display（显示屏）的行均指 AMOLED 显示屏。源模型将同一场景下的器件负载归在一起，并保留按每日使用量计算出的结果；这些结果所依据的每日发生次数和时长列在本文后面的每日使用模型中。

*工作簿将该列标记为 Power-Conversion Efficiency (%)，但其公式计算的只是电压比，并非实测的稳压器效率。后文“检查工作簿中的换算假设”一节会说明这对续航估算的影响。表中每日耗电量和占比均按工作簿结果四舍五入；精确公式和数值请使用可下载的工作簿。应先根据下文的排序表确定优化优先级，需要核对某一项的电流或电压假设时，再回到本矩阵查看。

flowchart LR
    A["定义每日用户行为"] --> B["为每类负载设定电流和活动时间"]
    B --> C["汇总电池侧每日 mAh"]
    C --> D["按场景和器件类别排序"]
    D --> E["在硬件上测量主要贡献项"]
    E --> F["更新假设并重复"]
    F --> B

将场景换算为每日耗电量¶

如果负载电流已按电池侧电流给出，每日耗电量可直接计算：

daily_charge_mAh = current_mA x active_time_seconds_per_day / 3600

如果负载通过稳压器供电，应先计算电池侧电流，再乘以活动时间：

battery_current_mA = (load_voltage_V x load_current_mA) /
                     (battery_voltage_V x regulator_efficiency)

应使用目标负载电流下实测的稳压器效率。对于大部分时间处于轻载状态的手表，稳压器标称峰值效率通常没有直接参考价值。

检查工作簿中的换算假设¶

工作簿中的 Power-Conversion Efficiency (%) 列按 load voltage / battery voltage（负载电压 / 电池电压）计算。后续耗电量公式先除以该辅助值，再除以电池电压，电压项恰好抵消。因此，每日耗电量实际上就是负载电流乘以时间：它将电池电流视为与负载电流相等，并不是按理想电源转换计算。这种处理类似于忽略静态电流的线性稳压器模型，不能通用于开关稳压器。

例如，3.3 V 电源轨上的 1 mA 负载由 3.87 V 电池通过理想变换器供电时，电池电流约为 0.853 mA，而工作簿计入的是 1 mA。实际变换器的结果取决于效率和静态电流。因此，仅凭工作簿的换算假设，不能判断续航估算偏乐观还是偏保守。排序仍可用于初步检查电流和时长假设，但不能直接当作最终续航预算。用于量产功耗预算时，应以各电源轨、各负载区间的实测效率替换该辅助值，并计入静态电流；若效率测量已包含静态电流，则不要重复计入。此外，还应考虑电池保护和充电路径的损耗。

根据实际使用情况计算每日耗电量¶

同一个场景在不同的使用频率下，可能对每日耗电量的贡献很小，也可能成为主要负载。工作簿中启用了一组场景，用于模拟一天的代表性使用情况，包括基础待机、消息通知、来电提示、抬腕亮屏、心率和血氧饱和度检测、运动记录、闹钟、睡眠监测和应用同步。NFC、蓝牙（Bluetooth）通话以及两个 AOD 场景均设为零，因此 13.15 天的结果不包含这些功能。

源数据矩阵中场景列的空白并非遗漏。每个具名场景行之后，都依次列出显示屏、振动马达和 Other 负载行；这些负载沿用上方场景行的每天次数和每次时长，因此源数据只在场景行中填写一次。

场景排序比最终续航天数更能指导行动。对每日耗电量贡献最大的场景，最值得优先验证优化假设。

pie showData
    title 按已启用场景统计的每日耗电量（mAh/天）
    "抬腕亮屏" : 4.9020
    "消息通知" : 3.9996
    "睡眠监测" : 2.3040
    "运动记录" : 2.1839
    "基础待机" : 2.0679
    "来电提示" : 0.7999
    "闹钟振动" : 0.6910
    "手动血氧" : 0.3929
    "自动心率" : 0.2616
    "应用同步" : 0.0800

耗电贡献最大的两个亮屏交互场景合计约占模型每日耗电量的一半。这是可通过测量验证的结论，而不只是笼统地说“显示屏耗电”。在投入精力处理更小的负载前，应先确认真实的抬腕次数、亮屏时长、亮度、刷新方式和通知策略。

pie showData
    title 工作簿中明确列出的类别每日耗电量（mAh/天）
    "AMOLED 显示屏（9.56 mAh/天）" : 9.5595
    "MCU（4.62 mAh/天）" : 4.6163
    "振动马达（2.22 mAh/天）" : 2.2203
    "其他 / 未拆分（1.29 mAh/天）" : 1.2866

图中最后一项特意保留为 Other / unallocated（未拆分）。工作簿没有给出蓝牙、加速度计或陀螺仪各自独立的电池侧耗电量。蓝牙通话场景被禁用，并不表示蓝牙耗电为零：应用同步场景也可能使用无线链路，但工作簿没有将这部分能耗拆出。同样，传感器能耗可能包含在 Other 中，但无法根据提供的数据继续拆分为加速度计和陀螺仪。

要将图表拆分为五类——MCU、显示屏、振动马达、蓝牙，以及合并统计的加速度计与陀螺仪——应分别为蓝牙空闲和传输状态、加速度计模式与占空比、陀螺仪模式与占空比增加数据行。每项负载都应在电池输入端测量，或先按实测稳压器效率折算，再计入电池侧 mAh 总量。随后用这些测量结果替换 Other / unallocated（其他/未拆分），不要再叠加可能已计入其中的传感器或蓝牙耗电。

区分 MCU 基础负载、场景相关 MCU 工作与传感器负载¶

工作簿单独列出了 MCU 类负载，但没有单独记录图形渲染这条代码路径。因此，更稳妥的分析方式是区分基础待机 MCU 项与各使用场景中归入 MCU 的负载；工作簿并未单独列出传感器耗电。

pie showData
    title 按活动类别统计的 MCU 每日耗电量（mAh/天）
    "基础待机" : 1.4854
    "亮屏交互" : 1.3013
    "睡眠监测" : 1.6640
    "自动心率检测" : 0.1656

下面两个比较可以避免得出片面的结论：

• **基础待机 MCU 项与亮屏场景中的 MCU 项：**基础待机为 1.49 mAh/天，略高于所有亮屏交互场景合计的 1.30 mAh/天 MCU 耗电量。按这组模型数据，降低假设的基础待机电流，与减少这些亮屏场景关联的 MCU 工作至少同等重要。工作簿没有把图形突发工作单独作为一项测量。
• **基础待机 MCU 项与其他明确列出的 MCU 项：**其余 MCU 项合计为 3.13 mAh/天，是基础待机 MCU 项的 2.11 倍。睡眠监测是最大的非基础待机单项，耗电量为 1.66 mAh/天；这是按场景归类的 MCU 负载，并非 CPU 单独处于活动状态时的测量值。

工作簿没有单独的传感器类别。Other 是唯一可能包含传感器耗电的类别，但其中也可能混有 PMIC、射频、漏电或其他后台负载。该类别合计为 1.29 mAh/天（7.28%）。即使把全部 Other 都归入传感器，工作簿中明确列出的 MCU 类负载仍更高：4.62 mAh/天，而 Other 为 1.29 mAh/天，前者约为后者的 3.59 倍。这只是工作簿类别之间的比较，并非 MCU 晶粒与传感器的直接实测对比。只有将传感器电源轨从通用的 Other 项中拆出，才能计算传感器自身的实际耗电量占比。

根据排序安排设计工作¶

应从模型中贡献最大的负载开始处理，再用实测结果验证排序。对于本模型，建议按以下顺序推进：

1. **显示策略：**测量抬腕亮屏全过程的电流曲线。先减少误触发，缩短亮屏时间，降低亮度，减少全屏重绘和不必要的动画，再考虑是否有必要把 MCU 电流降低几 µA。
2. **通知策略：**在产品体验允许时合并非紧急通知，并评审每个事件是否都需要同时点亮显示屏和振动提醒。
3. **已连接待机：**确认每次事件结束后 MCU 都能进入目标睡眠状态。检查周期定时器、轮询循环、蓝牙回调，以及电源管理（PM）投票。
4. **振动模式：**通过主观感知测试调整幅度和时长。更短或更柔和的振动，可能在不降低提醒效果的前提下减少能耗。
5. **长时间运行的传感器任务：**分析睡眠监测和运动记录的完整场景，覆盖传感器占空比、数据处理、存储器访问和无线活动。

不要孤立地优化表格中的某一个数字。看似省电的改动，可能增加唤醒次数、损害体验，或延长活动时间，从而抵消预期收益。

在硬件上验证模型¶

模型经过实测结果的持续校准后才有用。对于每个主要贡献项，都应记录电池或电源电压、温度、硬件版本、固件版本、启用的无线功能、显示模式和测量量程。

让模型保持可信¶

• 场景设为零表示尚未纳入预算，不表示该功能不耗电。当前工作簿为 NFC、蓝牙通话和 AOD 场景分配的耗电量均为零。
• 将用户可见功能和后台工作拆分为独立场景，这样产品评审时才能看清取舍。
• 尽量在电池输入端测量。电源轨测量同样有价值，但在变成续航数据前，必须补入稳压器损耗和静态电流。
• 每次只改变一个假设，并比较每日耗电量（mAh），而不是只看瞬时电流。
• 显示策略、蓝牙参数、传感器采样频率、PM 策略或重大固件功能发生变化后，都应重新运行模型。

要点¶

• 续航等于有效电池容量除以每日耗电量；该模型以 232.5 mAh 可用容量和 17.68 mAh/天的已启用负载，得到 13.15 天的预计续航。
• 在提供的基线中，显示行为主导功耗预算。仅抬腕亮屏和消息通知就约占每日耗电量的一半。
• 场景排序决定优先测什么、优化什么，比单一平均电流数值更有价值。
• 在把表格预测当作量产续航结论前，必须加入真实的电源转换效率和静态电流。
• 重复这一闭环：建立真实使用模型、测量主要场景、更新假设，再进行优化。

最后更新: 2026-10-21