能耗与电池
耗电投诉来的时候没有时间点、没有复现路径，通常也没法把你的 App 和同时醒着的另外六个区分开。这个模块就是把投诉变成一张图的地方。
两个不同的问题
Section titled “两个不同的问题”“这个 App 现在耗多少？” 是实时问题 —— 采一段会话，把能耗曲线和 CPU、GPU、网络放在一起读。见性能监控。
“昨晚的电是谁耗的？” 是历史问题，实时计数器答不了，因为当时没人在看。那是使用记录，它读的是设备自己记下来的东西。
能耗数字的含义
Section titled “能耗数字的含义”这是从“App 让哪些部件忙起来了”推导出的影响值，不是毫安时测量。请把它当相对量用：
- 这一版对上一版，同一段交互。
- 你的 App 对做同一件事的竞品。
- 同一个页面，某个特性开与关。
孤立的一个绝对值，不构成结论。
常见的耗电大户
Section titled “常见的耗电大户”| 行为 | 为什么贵 |
|---|---|
| 持续定位 | 连续 GPS 是手机能做的最贵的事之一。“移动时才精确”比“始终精确”便宜太多。 |
| 让屏幕常亮 | 显示屏往往是最大的单一消耗方。一个禁用自动锁屏的页面，比任何计算都贵。 |
| 后台刷新 | 一次很便宜，每十五分钟一次就很贵。 |
| 啰嗦的网络请求 | 射频最贵的是唤醒那一下。同样的字节数，十次批量请求远好过一百次零散请求。 |
| 不停的定时器 | 反复触发的定时器让 CPU 根本进不了低功耗状态。 |
| 视频与动画 | 持续的 GPU 工作，外加满亮度的屏幕。 |
一套能产出证据的做法
Section titled “一套能产出证据的做法”- 把设备充到一个已知电量，拔掉充电线。
- 采集一段固定交互 —— 目标页面五分钟。
- 把怀疑的原因去掉，再采一次。
- 对比两条能耗曲线，以及下面的 CPU / 网络 / 定位活动。
- 如果是“过了一夜”这类问题，第二天回来读使用记录。
两份采集一起附到工单上。用两条曲线回复的投诉，就不再是一场争论。
和设备自带数据交叉验证
Section titled “和设备自带数据交叉验证”设备自己的 设置 → 电池 会给出 24 小时或 10 天内的分应用百分比。它很粗，但用户提投诉时看的就是这个页面，所以值得看同一个页面。
克魔的历史能回溯得更远，并且会把同一时段按“每个 App 让哪些硬件保持唤醒”拆开。
免费档的边界
Section titled “免费档的边界”数据分析模块 —— 电池与充电、应用与耗电、无线、传感器等等 —— 是付费功能，见价格。