3. 电量消耗的度量与分析工具

在 Wear OS 上做电量优化，第一步不是“改代码”，而是“拿到可信的耗电证据”。手表电池容量通常只有 300～400mAh，一颗常驻传感器或一次高频唤醒就可能让续航从两天掉到一天。因此，本节围绕四类工具展开：Battery Historian 负责系统级电量归因，Systrace 负责 CPU 调度与唤醒时序，Perfetto 负责统一采集与跨进程追踪，Wear OS 专用功耗分析工具（如 Wear OS 上的 Battery Historian 变体、Android Studio Energy Profiler、以及厂商提供的功耗日志）负责把表端数据落到具体应用。理解它们各自“看什么、怎么采、怎么读”，比记住命令更重要。

一、Battery Historian：把电量拆成“谁用了多少”

Battery Historian 的核心价值是把一段时间的 batterystats 日志解析成时间轴和归因表。采集方式通常为：

adb shell dumpsys batterystats --reset
# 复现耗电场景，例如持续心率监测 30 分钟
adb shell dumpsys batterystats > batterystats.txt
adb shell dumpsys batterystats --history > batterystats_history.txt
# 或直接抓取 bugreport
adb bugreport bugreport.zip

把 bugreport.zip 上传到 Battery Historian 后，重点看三块：时间轴、设备状态、应用归因。时间轴上会叠加屏幕、Wi-Fi、GPS、传感器、唤醒锁、JobScheduler 等条带。若某应用在屏幕关闭后仍频繁出现 Wake lock 或 Sensor 条带，就说明它没有正确释放资源。归因表中 Estimated power use 会按 mAh 给出排名，但要注意：这是系统估算值，不是硬件实测值，适合做相对比较，不适合当作绝对功耗。

解读时抓住三个指标：唤醒次数、唤醒总时长、GPS/传感器使用时长。例如某表盘应用在 30 分钟内唤醒 120 次、累计持锁 18 分钟，而屏幕仅亮 2 分钟，这基本可以判定为后台唤醒失控。此时应结合 dumpsys alarm 和 dumpsys jobscheduler 查看具体触发源。

二、Systrace：看 CPU 调度与唤醒时序

Systrace 适合回答“谁在什么时候占用了 CPU、为什么设备没睡下去”。在 Wear OS 上采集：

python systrace.py -t 10 -o trace.html \
  sched freq idle am wm gfx view binder_driver \
  hal res sync power

生成的 HTML 中，每个 CPU 核是一条泳道，上方是进程/线程活动。重点观察：CPU 是否频繁从 idle 被拉起、是否有长时间高频率运行、SurfaceFlinger 与应用的帧调度是否对齐。如果看到某应用线程每 200ms 就唤醒一次，而业务上只需要 1 分钟一次，那就是典型的定时器过密。Systrace 的局限是采集窗口短、系统开销大，适合定位“瞬时抖动”，不适合长时间续航评估。

三、Perfetto：统一采集与跨进程追踪

Perfetto 是 Android 10 之后推荐的系统级追踪平台，支持长时间采集、SQL 查询和自定义 trace point。在 Wear OS 上可通过 record_android_trace 或设备端 perfetto 命令采集：

adb shell perfetto -o /data/misc/perfetto-traces/trace.pftrace -t 60s \
  -b 32mb sched freq idle am wm gfx view binder_driver hal res memory
adb pull /data/misc/perfetto-traces/trace.pftrace

Perfetto UI 中，除了看 CPU 和唤醒，还可以用 SQL 统计“每个进程的唤醒次数”和“传感器采样间隔”。例如查询 slice 表中 name LIKE '%sensor%' 的记录，能快速定位传感器采样频率。Perfetto 的优势在于：采集时间长、数据可查询、支持自定义 atrace 类别，适合把“电量问题”转化为可量化的时序数据。

四、Wear OS 专用功耗分析工具

Wear OS 与手机不同：屏幕常亮（AOD）、传感器常驻、蓝牙与 Wi-Fi 切换频繁。Android Studio 的 Energy Profiler 可以连接手表，实时查看 CPU、网络、GPS 和传感器的能耗曲线。它适合在开发阶段快速验证“某个功能是否异常耗电”。此外，部分厂商（如三星、出门问问）提供表端功耗日志，能给出更细的传感器采样与屏幕状态记录。使用这类工具时，建议固定场景：例如“关闭 AOD、开启心率、每 5 分钟同步一次数据”，采集 30 分钟，对比优化前后的曲线。

五、组合使用与判断依据

实际排障中，推荐顺序是：Battery Historian 先定位应用，Systrace/Perfetto 再定位时序，专用工具做实时验证。判断优化是否有效，不要只看“感觉”，而要看三个量化指标：同一场景下唤醒次数、传感器持有时长、估算 mAh。若唤醒次数下降 50% 以上、估算功耗下降 20% 以上，通常可认为优化有效。最后提醒：所有工具数据都受系统版本、厂商定制和采集开销影响，务必在相同条件下对比，避免把“采集本身的开销”误判为应用耗电。