前台计量法的底层逻辑——为什么「全算给前台 App」是诚实的选择
两种思路的根本分歧
Android 系统的电池统计和 AccuBattery 走了两条完全不同的路：
| 维度 | Android 系统 | AccuBattery |
|---|---|---|
| 测量什么 | 只测整机 | 只测整机 |
| 分配策略 | 按 profile 比例估算给各 App | 全算给当前前台 App |
| 精度 | profile 预设值 ≠ 真实 | 有交叉干扰但基于实测 |
| 诚实度 | 看上去精确但不可靠 | 看上去粗但可复核 |
为什么 Android 不能精确分配
Android 系统架构决定了它无法精确测量 App 级耗电：
- 硬件层面只有一个电池计量器：整机的电池电流是从电池流出的一个值，硬件层面没法拆分到 CPU 哪个核心、哪个传感器、哪个 App
- 内核层面没有 App 级能耗 meter：CPU 有
Power_Supply，但那只能看到整机功耗 - Android 的 BatteryStats 是事件驱动：它不读实时电流，而是记录每个 App 的运行时长、唤醒次数、GPS 使用时长等事件，再乘预设系数
AccuBattery 的方法反而简单粗暴：
当你打开 App A 让它在前台运行时，整台手机从电池里流出去的每 mA 电，都记在 App A 头上。
误差分析
AccuBattery 团队公开承认的两种误差：
误差 1：前台 App 为后台活动背锅
时钟 App 在前台，但微信后台在同步数据 → 同步的耗电被算到时钟头上。
团队的判断：
"大部分耗电来自屏幕和前台 App 的 CPU。后台 App 的独立 wake 在灭屏时发生，不分配给前台 App；亮屏时后台活动的耗电远小于前台自身。这个误差在日常使用场景下不影响排行榜排序。"
误差 2：overlay / 悬浮窗场景
Premium 版的悬浮窗、录屏、某些输入法有系统级 overlay——这些 App 没有「前台 App」的常规概念。AccuBattery 在屏幕关闭时会正确归零。
和 Android 系统方法的对比实验
假设一个场景：
- 亮屏，中等亮度（约 300mA 耗电）
- 打开某 App（额外 CPU 负载 200mA）
- 后台有 App 在同步数据（额外 50mA）
| 方法 | 测到的前台 App 耗电 | 注释 |
|---|---|---|
| 真实值（理想） | 500 mA | 屏幕 300 + CPU 200 |
| AccuBattery 前台计量 | 550 mA | 包含了后台同步的 50mA |
| Android profile 估算 | 可能 350 mA 或 650 mA | 取决于 profile 里对屏幕/CPU活动的权重 |
AccuBattery 的误差是 +10%（50mA / 550mA），但 Android 的 profile 误差可能随意飘——因为屏幕亮度、CPU 频率、网络信号都在变，profile 预设值很难覆盖所有场景。
这就是 AccuBattery 的选择
"团队宁可给你一个有交叉干扰但基于真实电流测量的数字，也不想给你一个看起来精确到小数点后第二位但完全靠猜的数字。"
这个产品理念贯穿了 AccuBattery 的全部设计——真实测量优先于漂亮数据。
回到组首页：放电 Tab 全貌