Android稳定性-44-Android 功耗与温升异常：batterystats、wakelock、降频和后台行为

功耗和温升问题在 Android 稳定性测试里很特殊。它们不一定马上表现为 Crash、ANR 或重启，却会持续侵蚀用户体验：待机一夜掉电过快，视频会议二十分钟后机身烫手，导航过程中亮度下降，游戏或相机预览越来越卡，后台放着不动也频繁唤醒。很多版本评审只盯崩溃率和长稳通过率，功耗温升如果没有被写成清楚的风险，就容易被当成“体验优化”延后处理。

这类问题也很容易争议。测试说发热，研发会问环境温度、亮度、网络、信号、后台账号、SIM 卡、是否插电、是否刚刷机、是否同步数据；测试说掉电快，研发会问电池健康、充电截止电量、静置时长、设备差异、统计口径。争议本身不是坏事，它说明功耗温升必须比普通功能缺陷更重视实验条件和数据口径。

本文从稳定性测试角度梳理功耗与温升异常：如何建立基线，如何看 batterystats 和 wakelock，如何把温度、频率、掉电、后台行为放在同一条时间线上，如何处理降频带来的连锁卡顿。文章包含完整案例、命令、表格、误判、检查清单和输出物模板，重点是让问题能进入版本决策，而不是停留在一句“设备比较热”。

一、功耗温升要先统一测试口径

功耗测试最怕条件不一致。同一个版本，在 Wi-Fi 强信号和弱蜂窝信号下，待机掉电可能完全不同；同一台设备，刚刷机后的媒体扫描、云同步、应用恢复会让后台活动明显增加；同一个视频场景，屏幕亮度、音量、分辨率、环境温度、保护壳都会改变温升曲线。如果这些条件没有写清楚，后面的数字很难被复核。

稳定性团队至少要固定五类条件。第一是设备状态：型号、内存存储配置、电池健康、是否插 SIM、是否登录账号、是否恢复出厂。第二是环境：室温、是否风冷、设备摆放方式、屏幕亮度、音量、网络类型和信号强度。第三是版本：系统版本、基带版本、内核版本、应用版本、是否打开调试日志。第四是场景：亮屏、灭屏、视频、相机、导航、通话、游戏、长稳遍历。第五是采集方式：电量读数来源、温度来源、采样间隔、起止时间。

只有口径固定，数据才有比较意义。比如“待机 8 小时掉电 12%”本身没有结论，只有和同设备基线、竞品或前一版本对比后才有意义。如果前一版本同条件掉电 4%，新版本掉电 12%，并且 batterystats 指向某个后台服务持有 wakelock，那么它就是版本风险；如果两台设备电池健康差异很大，环境温度差 8 摄氏度，就不能直接下结论。

功耗温升专项最好在报告开头放一张条件表，而不是把条件散落在正文里。这样评审时所有人先对实验边界达成一致，再讨论结果是否异常。

二、功耗、温升、性能是连在一起的

很多测试报告把功耗、温升和卡顿分开写，实际设备上它们经常互相影响。后台频繁唤醒会增加功耗，功耗增加会推高温度，温度升高触发 thermal 策略，CPU/GPU 降频后前台场景变卡，用户感知就从“掉电快”变成“发热并且卡”。如果只看最后的卡顿，可能会误判为渲染问题；如果只看掉电，又可能漏掉降频后的体验退化。

温升也不一定来自 CPU。相机、屏幕、基带、Wi-Fi、GPS、NPU、充电管理、音频、传感器都可能贡献热量。比如弱网直播时，基带功耗升高、编码器持续工作、屏幕常亮、应用还在写日志，最终温度上升并触发降频。此时 CPU top 可能没有异常高负载，但整机仍然发热。

稳定性测试要做的是把链路串起来：哪个业务动作或后台行为增加了唤醒，唤醒带来了哪些硬件活动，硬件活动怎样改变电量和温度，thermal 策略何时介入，介入后帧率、响应或任务耗时发生了什么变化。这个链路越清楚，越容易判断问题归属。

如果只需要做准入判断，也至少要回答：新版本是否比基线更耗电，温升是否更快或峰值更高，是否触发降频，降频是否影响关键场景，异常是否能通过配置、关闭后台任务或修复日志策略消除。

三、基础命令：batterystats、thermal、频率和唤醒

功耗温升现场采集要分成开始前、运行中、结束后三段。开始前清空统计或记录基线，运行中按固定间隔采样，结束后导出完整证据。下面是一组常用命令。

adb shell dumpsys battery
adb shell dumpsys batterystats --reset
adb shell cmd battery unplug
adb shell settings get system screen_brightness
adb shell dumpsys power
adb shell dumpsys deviceidle
adb shell dumpsys alarm
adb shell dumpsys jobscheduler
adb shell dumpsys batterystats > batterystats.txt
adb bugreport bugreport-power.zip

温度和频率路径在不同芯片平台上差异较大，测试脚本要做兼容。下面命令适合先探索设备节点，再选择稳定可读的指标。

adb shell ls /sys/class/thermal
adb shell "for z in /sys/class/thermal/thermal_zone*/temp; do echo $z=$(cat $z); done"
adb shell "for z in /sys/class/thermal/thermal_zone*/type; do echo $z=$(cat $z); done"
adb shell "for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq; do echo $c=$(cat $c 2>/dev/null); done"
adb shell dumpsys thermalservice
adb shell dumpsys SurfaceFlinger --latency-clear 2>/dev/null

如果怀疑 wakelock 或后台唤醒，重点看 dumpsys batterystats 里的 partial wakelock、wakeups、jobs、alarms、network、wifi、mobile radio、sensor 使用情况。Android 版本不同，输出格式会变，但核心思路不变：找出谁让设备睡不下去，谁让硬件持续工作，谁在用户没有感知的情况下消耗资源。

命令采集要避免插电状态混乱。很多设备插 USB 后会影响充电状态、温控策略和统计口径。如果必须通过 ADB 采集，至少要在报告里写明供电方式，并保持基线和问题版本一致。

四、数据表：把曲线变成结论

功耗温升报告要少写形容词，多写对比数据。下面这张表适合放在专项报告的结果页。

项目	基线版本	问题版本	差异	结论
灭屏待机 8h 掉电	4%	12%	+8%	明显退化
partial wakelock 总时长	18 min	3 h 42 min	+3 h 24 min	后台持锁异常
每小时 wakeup 次数	120	980	+716%	Alarm 过密
亮屏视频 30 min 温升	+7.2°C	+13.8°C	+6.6°C	温升过快
CPU 大核最低稳定频率	1.8 GHz	998 MHz	降频明显	影响前台流畅度
相机预览 P95 帧间隔	22 ms	48 ms	+26 ms	用户可感知卡顿

表格只是摘要，后面还要说明口径。例如电量来自系统电量百分比还是外接电源仪，温度取 battery、skin、cpu 还是板级传感器，采样间隔是 1 秒还是 30 秒。不要让一个看似漂亮的表格变成无法复测的数据孤岛。

趋势图也很重要。待机掉电看斜率，温升看上升速度和平台期，频率看 thermal 介入前后的变化，wakelock 看是否集中在某个应用或服务。报告里如果只能放一张图，优先放“温度、电量、频率、场景阶段”合在一起的时间线。

五、batterystats 该怎么看

batterystats 的输出很长，第一次看很容易迷失。稳定性测试不需要逐字段背完，但要知道从哪里找线索。灭屏待机重点看 wake lock、wakeups、alarms、jobs、network、sensor、wifi scan、mobile radio。亮屏场景还要看 screen、camera、audio、video、cpu running 和应用前后台状态。

partial wakelock 是常见入口。如果某个服务在灭屏后仍持锁几个小时，就要看它是否有合理业务理由。比如音乐播放、导航、通话有合理性；普通同步、日志上传、埋点重试、保活心跳则要看频率和退出条件。不要看到 wakelock 就直接判错，也不要因为应用声明“业务需要”就放过长时间持锁。

Alarm 和 JobScheduler 也要结合看。有些问题不是单个 wakelock 很长，而是每隔几十秒唤醒一次，设备反复从低功耗状态出来，累计掉电明显。还有些模块在网络失败时指数退避没做好，弱网环境下不断重试，导致 radio 和 CPU 都下不去。

分析时可以用文本提取辅助，但最后要回到场景。比如灭屏 8 小时里某包唤醒 900 次，先问它是否应该在灭屏工作；如果应该，再问频率是否合理；如果不应该，就要给出触发条件和复现方式。否则研发只能拿到一个排行榜，很难修。

六、完整案例：后台同步持锁导致待机掉电

某海外版本在灰度前做 8 小时灭屏待机测试，10 台设备里有 6 台掉电超过 10%，基线版本同条件通常在 3% 到 5%。测试条件固定为 Wi-Fi 连接、插 SIM 但关闭移动数据、亮度自动、登录同一测试账号、刷机后静置 2 小时再开始。开始前执行 batterystats --reset，结束后导出 bugreport 和温度采样。

第一轮数据只显示掉电偏高，没有 Crash、ANR 或明显 CPU 高负载。继续看 batterystats，发现某云同步服务在灭屏期间 partial wakelock 总时长超过 4 小时，每小时 alarm wakeup 接近 700 次。脚本日志显示设备在灭屏后仍持续上传本地诊断文件，网络失败时没有按预期退避，导致服务反复唤醒、扫描目录、尝试上传。

温度曲线也提供了旁证。虽然设备灭屏，battery 温度仍从 30°C 缓慢上升到 36°C，CPU 小核频率间歇性抬高。dumpsys jobscheduler 里能看到同一个 job 反复执行失败，下一次调度间隔只有几十秒。关闭该同步开关后，复测 8 小时掉电回落到 4%，wakelock 总时长低于 20 分钟。

最终修复是三部分：同步服务只在充电或 Wi-Fi 良好且满足用户设置时运行；失败重试改成指数退避并设置每日上限；诊断文件上传增加大小限制和批处理。测试侧把“灭屏待机 wakelock 总时长”和“每小时 wakeup 次数”加入灰度准入表，不再只看最终电量。

这个案例说明，功耗问题不能等同于“某进程耗电排名高”。真正的证据链是：待机掉电退化，后台服务持锁和唤醒异常，重试策略与网络失败相关，关闭开关后可恢复，修复后同条件复测达标。

七、温升和降频要一起记录

温升本身影响用户感知，但在系统稳定性里，更大的风险是 thermal 策略介入后引发连锁问题。CPU 降频会让启动、滑动、数据库、解码变慢；GPU 降频会影响动画和游戏；屏幕亮度限制会影响户外可用性；相机可能因为温度过高降帧甚至停止录像。报告如果只写最高温度，无法说明影响范围。

温升测试要记录三个点：起始温度、到达关键阈值的时间、进入平台期后的性能。比如视频会议 30 分钟，问题版本 12 分钟触发大核降频，18 分钟后相机预览 P95 帧间隔超过 45 ms；基线版本 30 分钟内未触发同等级降频。这样的描述比“温度高 5 度”更能支持版本判断。

降频判断也不能只看单次频率读数。频率会随负载波动，应该结合场景阶段、温度、thermal status、帧率或任务耗时。若有 Perfetto，可以把 CPU freq、sched、SurfaceFlinger、应用线程放在同一视图；没有 Perfetto，也可以用脚本每秒采样温度、频率和前台动作耗时，形成 CSV。

示例采样命令：

adb shell "while true; do date +%s; cat /sys/class/thermal/thermal_zone*/temp 2>/dev/null | head -n 8; sleep 1; done" > temp_sample.txt
adb shell "while true; do cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 2>/dev/null; sleep 1; done" > cpu0_freq.txt
adb shell dumpsys thermalservice > thermalservice.txt

不同平台 thermal zone 名称差异很大，正式脚本要先映射传感器类型。不要把未知 zone 的数字直接写成“CPU 温度”，这会造成复盘时的数据争议。

八、后台行为审计

功耗问题里最常见的后台行为包括：频繁定位、Wi-Fi 扫描、蓝牙扫描、传感器采样、网络心跳、日志上传、数据库清理、媒体扫描、账号同步、保活拉起。每一项都可能有业务理由，但稳定性测试要看它是否尊重系统状态和用户场景。

审计后台行为时，不要只问“有没有运行”，而要问“何时运行、运行多久、失败后怎么退、灭屏是否停止、低电量是否停止、弱网是否降频、温度高时是否让路”。这几个问题比单纯抓一个进程耗电排名更有价值。

可以把后台行为整理成表：

行为	触发条件	灭屏策略	失败重试	证据	结论
诊断日志上传	每小时或异常后	问题版本未停止	固定 30 秒重试	alarm、wakelock、网络日志	需修复
定位刷新	地图前台	退后台 3 分钟停止	无重试	app log、batterystats sensor	符合预期
Wi-Fi 扫描	配网页	页面退出停止	无	dumpsys wifi	符合预期
媒体扫描	新文件写入	可后台短时运行	系统控制	logcat、media provider	观察

这张表能帮助评审区分合理消耗和异常消耗。功耗不是要求所有后台行为归零，而是要求行为与场景匹配、频率可控、退出条件明确。

九、常见误判

误判	问题	建议
只看最终掉电百分比	电池健康和初始状态可能干扰	固定条件并与基线同台对比
看到发热就归 CPU	基带、屏幕、相机、充电都可能发热	同时看硬件活动和场景
wakelock 排名高就判错	前台播放、导航等场景可能合理	结合用户场景和持锁时长
没有 Crash 就认为不阻断	功耗温升会引发降频和体验退化	把性能影响写进风险结论
插 USB 采集不说明	供电影响电量和温控	报告中固定并说明供电方式
只测一次	温度和电量受环境波动影响	至少做多机或多轮确认

功耗温升问题的可信度来自可复测。只要条件固定、基线明确、证据成链，结论就不需要依赖“手感热不热”。

十、检查清单

• 是否写明环境温度、亮度、音量、网络、SIM、账号和供电方式。
• 是否使用同台或同批设备做基线对比。
• 是否在测试前重置或记录 batterystats 起点。
• 是否采集 wakelock、alarm、job、network、sensor、thermal 数据。
• 是否记录温度、频率、帧率或任务耗时的时间线。
• 是否区分亮屏功耗、灭屏待机、后台同步和专项业务场景。
• 是否分析降频后的用户影响，而不是只写最高温度。
• 是否排查刷机后同步、媒体扫描、日志级别等干扰项。
• 是否验证关闭可疑后台行为后的恢复效果。
• 是否给出准入、灰度或遗留建议。

这份清单可以作为日报和准入报告的附件。对于高风险版本，建议把灭屏待机、视频温升、相机温升、弱网后台重试至少选两项加入每日监控。

十一、输出物模板

问题标题：
  [Power][Standby] V2026.03.29 灭屏待机 8 小时掉电从 4% 退化到 12%

测试条件：
  设备：X1 8+256G，10 台
  环境：25°C，Wi-Fi，插 SIM，移动数据关闭，亮度自动
  状态：刷机后静置 2 小时，登录测试账号，开始前 batterystats reset

结果摘要：
  基线版本：8 小时掉电 3% 到 5%
  问题版本：8 小时掉电 10% 到 13%，6/10 台超阈值
  温度：battery 最高 36°C，灭屏期间缓慢上升

关键证据：
  1. com.example.sync partial wakelock 总时长 4h12m。
  2. 每小时 alarm wakeup 约 700 次，网络失败后固定间隔重试。
  3. 关闭诊断上传后，8 小时掉电回落到 4%。

根因判断：
  后台诊断上传在灭屏弱网下没有退避，持续持锁并唤醒设备。

修复要求：
  增加充电/Wi-Fi/低电量/温度条件，失败重试改为指数退避，限制每日上传量。

版本建议：
  当前版本不建议灰度扩大；修复后需完成 3 轮 8 小时待机和 30 分钟亮屏温升复测。

十二、小结

十三、复测要覆盖冷机、热机和长时间后台

功耗温升修复后的复测不能只跑一轮短场景。很多策略在冷机时看起来正常，设备热起来以后才暴露降频；很多后台行为在刚刷机时没有数据，账号同步几小时后才开始高频运行；很多上传任务在网络正常时没有问题，弱网失败后才暴露重试策略。复测至少要覆盖冷机启动、热机连续运行、灭屏后台和失败重试几个状态。

建议把复测拆成三组。第一组是同条件回归，完全复制发现问题时的环境和账号，验证掉电、温升和 wakelock 是否回到基线。第二组是边界场景，加入弱网、低电量、低温或高温、长时间灭屏、充电和非充电切换，确认修复策略不会只在理想条件下生效。第三组是副作用验证，比如限制后台同步后，用户打开应用是否还能及时看到数据，诊断日志延后上传是否影响问题定位。

复测结论里要写清楚“恢复到什么程度”。例如待机 8 小时从 12% 回落到 4%，partial wakelock 从 4 小时降到 18 分钟，wakeups 从每小时 700 次降到 120 次，亮屏视频 30 分钟不再触发大核长期降频。只写“功耗正常”不够，因为下一轮版本如果再次退化，团队需要这些数字作为基线。

十四、和发布策略的关系

功耗温升问题的发布策略通常比 Crash 更难定。Crash 是非黑即白的中断，功耗则有程度差异。是否阻断，要看退化幅度、用户路径、可规避性和线上监控能力。灭屏待机掉电大幅退化，通常比某个低频页面温升略高更严重；相机、导航、视频会议这类长时间前台场景发热降频，也比一次性短操作更接近发布风险。

如果风险允许灰度，日报和灰度方案里要写清楚观察指标。比如灰度用户待机掉电分布、后台 wakelock 排名、温度上报、前台场景帧率、低电量投诉、回滚阈值。不能把“灰度观察”写成没有指标的等待。对于无法线上监控的温升问题，线下样本就要更充分，尤其要覆盖高温环境和弱信号环境。

发布建议可以分三档：阻断，表示退化明显且影响高频或核心场景；条件通过，表示修复已合入但样本时长不足，需要限制灰度比例和监控；普通遗留，表示影响轻、路径低频、已有规避，且下一版本有明确计划。稳定性测试报告要说明为什么落在这一档，而不是只把数据交给项目自己猜。

十五、专项平台可以沉淀哪些能力

功耗温升分析如果每次都靠人工翻 batterystats，效率会很低。测试平台可以先沉淀四类能力。第一是条件记录，自动保存环境温度、亮度、网络、SIM、账号、供电方式和版本信息。第二是趋势采样，统一采集电量、温度、频率、前台场景阶段和设备状态。第三是行为摘要，从 batterystats 中提取 wakelock、alarm、job、sensor、network 的 Top 列表。第四是阈值告警，当待机掉电、温升速度、wakeup 次数或降频时长超过基线时自动标红。

平台能力不需要一次做完。最小可用版本可以先生成一份 CSV 和一张趋势图，让日报不再手工抄数字。后续再加入基线对比、问题单关联、修复前后对照和灰度指标映射。功耗温升问题最怕口径漂移，平台的意义就是让每次测试在同一套口径下比较。

十六、亮屏业务场景的专项设计

亮屏功耗和灭屏待机的分析方法不同。灭屏看设备能不能睡下去，亮屏看硬件能力是否被合理使用。相机、视频会议、导航、游戏、短视频、热点共享，这些场景都可能让多个硬件单元同时工作。测试时不能只看系统电量下降，还要看帧率、编码、网络、定位、屏幕亮度、音频和温度策略。

以视频会议为例，测试条件至少要固定会议时长、参会人数、前后摄、分辨率、弱网档位、扬声器音量、屏幕亮度和是否佩戴耳机。采集时不仅记录电量和温度，还要记录音视频卡顿、CPU/GPU 频率、编码器状态、网络重传、应用日志和 thermal status。如果问题版本 20 分钟后温度到达阈值并限制频率，随后音频断续或视频降帧，报告里要把这三件事连起来。

导航场景则要重点看定位、屏幕常亮、移动网络、语音播报和后台保活。弱信号下基带功耗上升很常见，如果应用还在高频上传轨迹、频繁刷新地图瓦片、持续写日志，温升会进一步放大。测试报告里要区分“业务必要消耗”和“异常重复消耗”：导航前台持续定位合理，但灭屏后仍保持高频定位就需要解释。

这些亮屏场景适合建立“场景画像”。画像不是一张图，而是一组基准：30 分钟电量下降、最高 skin 温度、触发降频时间、P95 帧耗时、网络流量、主要 wakelock、主要 job/alarm。下一次版本改动后，只要画像里某个指标明显偏离，就能快速发现退化。

十七、弱网和低电量会放大功耗问题

功耗问题经常在理想网络下不复现，在弱网下明显放大。原因很直接：请求失败会重试，上传下载会拉长，radio 活跃时间增加，业务线程等待更久，日志也可能变多。如果重试策略没有退避，设备会在用户没有感知的后台行为里反复醒来。弱网功耗测试不能只看请求成功率，还要看失败后的资源行为。

低电量也是重要边界。系统和应用在低电量时应该降低非关键任务频率，推迟上传、减少扫描、停止部分后台同步。如果低电量下仍然保持高频任务，不只是续航问题，也可能让用户在最需要省电的时候更快关机。报告里可以把普通电量和低电量对照：同样灭屏 2 小时，后台同步次数、wakelock、网络流量是否下降。

弱网与低电量叠加时，问题更容易暴露。比如诊断上传失败后固定间隔重试，低电量策略没有拦截，设备每 30 秒醒一次；或者地图在弱网下不断请求瓦片，低电量时仍不降频。测试设计时可以先用短时探索找出高风险行为，再决定是否加入准入门禁。

这类边界场景不一定每个版本都全量跑，但一旦某个模块修改了后台同步、网络重试、定位、日志上传或推送保活，就应该触发专项回归。功耗测试不能只作为发布前的固定动作，还要和代码变更类型联动。

十八、问题关闭标准

功耗温升问题关闭时，建议同时满足四个条件。第一，同条件指标恢复到基线阈值内。第二，关键后台行为有明确策略变化，并通过日志或 batterystats 证明生效。第三，前台用户体验没有因为省电策略产生明显副作用。第四，灰度或长稳日报里有后续观察指标。

例如后台同步持锁问题，关闭标准可以写成：灭屏 8 小时掉电不超过基线 2 个百分点；partial wakelock 总时长低于 30 分钟；失败重试间隔符合退避策略；用户打开应用后数据同步延迟不超过产品可接受范围；灰度期间监控 wakeup 和同步失败率。这样关闭问题时，研发、测试和产品都知道边界。

温升问题也类似。关闭不是最高温度降低一点就结束，而是关键场景不再触发不可接受的降频或功能限制，用户路径指标恢复，异常温度上报下降。对于相机、视频会议、导航这类核心场景，最好保留长时间复测视频和采样 CSV，避免下一轮版本重新争论。

还有一个经常被忽略的关闭条件：修复策略要能解释线上差异。实验室里网络、温度、账号都可控，线上用户环境更复杂。如果修复只在实验室账号生效，或者只在 Wi-Fi 下退避，灰度后仍可能复发。因此关闭前要确认策略绑定的是系统状态和业务状态，而不是测试环境里的偶然条件。

功耗与温升异常不是单纯的性能优化项，它们会影响续航、握持体验、前台流畅度和版本口碑。稳定性测试要把条件、基线、行为、资源和用户影响写清楚，让评审能判断这是不是版本风险。

一份合格的功耗温升分析，应该能说明：同条件下退化多少，退化来自哪些后台或硬件活动，温度和频率如何变化，是否影响关键场景，修复或关闭可疑行为后是否恢复。做到这些，功耗问题就能从“感觉耗电”变成可复测、可关闭的工程问题。