Android 电源管理深度解析：从 Wakelock 滥用到 Doze 模式的省电工程实践

有一次做用户反馈排查，发现某个版本上线后耗电量激增了 30%。Battery Historian 一跑，直接看到一条 Wakelock 持续了 40 分钟不释放——那是一个网络请求超时没有被正确捕获，导致 WakeLock.release() 永远没执行到。

这是 Android 电量问题最典型的入口：Wakelock 滥用。

Wakelock 的本质与正确用法

Wakelock（唤醒锁）的作用是阻止 CPU 进入睡眠状态。屏幕熄灭后系统会逐步降低 CPU 频率直到挂起，Wakelock 打破了这个过程。

PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(
    PowerManager.PARTIAL_WAKE_LOCK, 
    "MyApp:NetworkRequest"  // tag 要有意义，便于 Battery Historian 识别
);
wl.acquire(10 * 60 * 1000L); // 10 分钟超时保护，强烈建议加
try {
    doNetworkWork();
} finally {
    if (wl.isHeld()) wl.release(); // finally 块里释放，不能省
}

PARTIAL_WAKE_LOCK 是最常用的类型，只保持 CPU 运转，不影响屏幕。acquire() 带超时参数是最低安全底线——没有超时的 Wakelock，一旦 release() 因异常跳过，就是一颗定时炸弹。

在多线程场景下还有个坑：isHeld() 和 release() 之间存在竞态。如果多个线程都可能调用 release，要用引用计数模式——acquire() 可以多次调用，每次 release() 减一，计数归零才真正释放。

Doze 模式的两级机制

Android 6.0 引入 Doze，Android 7.0 扩展为两级。两级的触发条件不同，后台任务的行为也随之不同。

Doze Level 1（Deep Doze）：设备静止、屏幕关闭、不充电，持续约 30 分钟后触发。进入后系统定期开放 Maintenance Window，允许网络访问和任务执行，但窗口间隔会越来越长，最长可达数小时。

Doze Level 2（Light Doze）：屏幕关闭但设备在移动，或刚熄屏不久。限制更宽松，网络访问受限但 JobScheduler 仍可运行。

// 检测当前是否处于 Doze 模式
val pm = getSystemService(Context.POWER_SERVICE) as PowerManager
if (pm.isDeviceIdleMode) {
    // 处于深度 Doze，网络不可用，AlarmManager 不触发
    // 只有 FLAG_ALLOW_WHILE_IDLE 的 alarm 会在窗口期执行
}

Doze 对后台任务的核心限制：AlarmManager 的精确定时不生效、网络访问暂停、JobScheduler 推迟到 Maintenance Window。这意味着依赖 AlarmManager.setExact() 的后台逻辑在 Doze 下是不可靠的。

替代方案是 setExactAndAllowWhileIdle()，但这个 API 有频率限制，每个 App 每 9 分钟最多触发一次。真正需要精准定时的场景（如音乐播放、计时器），应该持有前台服务，不要押注在 Alarm 上。

App Standby 与 Bucket 分级

App Standby 从另一个维度施加限制，按使用频率把 App 分桶（Bucket）：

Active：用户正在使用，无限制
Working Set：经常使用，轻微限制
Frequent：偶尔使用，JobScheduler 频率受限
Rare：很少使用，网络配额减少，任务频率大幅降低
Restricted（Android 12+）：几乎不用，每天只有一次 Job 执行窗口

// 查询当前 App 所在的 Bucket（需要 QUERY_ALL_PACKAGES 或系统权限）
val usm = getSystemService(Context.USAGE_STATS_SERVICE) as UsageStatsManager
val bucket = usm.appStandbyBucket
// 返回值对应 UsageStatsManager.STANDBY_BUCKET_* 常量

实际项目里有个容易忽视的点：Push 通知依赖的 FCM 长连接由系统统一维护，Bucket 不影响它。但如果 App 用自建长连接做推送，在 Rare Bucket 下网络受限会导致消息延迟。很多国内 App 后台推送不稳定，根源往往就在这里——不是 FCM 的问题，是自己的长连接被系统限制了。

Battery Historian 实战诊断

Battery Historian 是谷歌提供的电量分析工具，基于 bugreport 文件生成可视化报告，本地跑一个 Docker 实例就能用：

# 抓取 bugreport（需要 ADB 连接设备）
adb bugreport bugreport.zip

# 用 Docker 跑 Battery Historian
docker run -d -p 9999:9999 gcr.io/android-battery-historian/stable:3.0 --port 9999

# 浏览器打开 http://localhost:9999，上传 bugreport.zip

报告里重点看这几条泳道：

Wakelock 泳道：每段颜色块代表一次 Wakelock 持有。块越长问题越大，结合 Tag 名称能直接定位到代码。

JobScheduler 泳道：Job 的执行时间和频率。频繁的短 Job 说明任务拆得太细，可以合并。

Sync 泳道：账户同步操作。密集的 Sync 请求要检查 ContentResolver.setSyncAutomatically 的调用逻辑。

Mobile Radio 泳道：移动网络射频激活时间。射频唤醒是高耗电操作，理想状态是请求集中发出、快速关闭，断断续续触发多次是需要修的问题。

在实际项目中我发现，Battery Historian 最有价值的用法不是发现问题，而是验证优化效果。改完代码后跑两次 bugreport 做对比——Wakelock 持有时间减少了多少、Job 执行频率是否下降，数据比主观感受更可信。

JobScheduler 的正确姿势

大部分后台任务应该用 JobScheduler，或者直接用它的上层封装 WorkManager，而不是 Service + Wakelock。系统统一调度，批量执行，本身就对省电有利。

// WorkManager 是 JobScheduler 的推荐上层 API
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresBatteryNotLow(true)  // 电量低时不执行
    .build()

val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(
    repeatInterval = 1,
    repeatIntervalTimeUnit = TimeUnit.HOURS
)
    .setConstraints(constraints)
    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.MINUTES)
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "periodic_sync",
    ExistingPeriodicWorkPolicy.KEEP,
    syncRequest
)

setRequiresBatteryNotLow() 这个约束经常被漏掉，加上它能避免在电量低时任务还在跑、雪上加霜。BackoffPolicy.EXPONENTIAL 保证失败后重试间隔指数增长，而不是无脑重试。

WorkManager 在 API 23+ 内部用 JobScheduler，低版本 fallback 到 AlarmManager，兼容性问题框架自己处理了。我的建议是直接用 WorkManager，除非有精细控制调度时机的特殊需求，否则裸用 JobScheduler 没什么收益。

几条可操作的实践建议

永远给 Wakelock 加超时。 acquire(timeoutMillis) 是保险丝，不加的话一个未捕获异常就能让 Wakelock 泄漏到设备重启。超时时间设为预期最长执行时间的 1.5 倍即可。

用 Battery Historian 做上线前回归。 把 bugreport 采集纳入 QA 流程，每次涉及后台逻辑的改动都跑一次对比。等用户反馈驱动排查，成本高十倍。

区分”需要精确时机”和”需要可靠执行”这两类任务。 前者用前台服务，后者用 WorkManager。把两者混在一起用 Service + Wakelock 实现，是大多数电量问题的根源。