电源管理策略：Doze模式与App Standby
说到Android的电源管理，Doze模式和App Standby绝对是绕不开的两个核心机制。我最早接触Doze模式是在Android 6.0刚发布那会儿，当时我们团队有个App在后台频繁唤醒屏幕，结果被用户投诉说手机待机一晚上掉电30%。嗯，从那以后我就开始认真研究这两个东西了。
Doze模式的工作原理
说白了，Doze模式就是系统在检测到设备长时间静止且屏幕关闭时，主动限制App的后台活动。你想想看，手机放在桌上不动，屏幕也黑了，这时候还让App们乱跑，那不是浪费电吗？
Doze模式分两个阶段：
- 轻度Doze：设备静止30分钟后进入，网络访问受限，但App还能偶尔醒一醒
- 深度Doze：设备静止更长时间后进入，几乎完全切断后台网络和任务
我个人习惯把Doze模式想象成一个严格的保安——平时让你自由进出，但到了深夜（深度Doze），连门都不让你出。
App Standby的机制
App Standby和Doze模式是两回事，但经常被混为一谈。App Standby针对的是那些用户很久没打开的App。系统会判断：这个App用户最近没用过，那它的后台活动就该被限制。
判断标准很简单：
- App没有前台Activity运行
- 没有正在运行的前台服务
- 用户没有主动点击通知或图标
我在项目中遇到过一个问题：某个App明明用户每天都会打开，但系统还是把它标记成了Standby状态。后来发现是因为App在后台频繁使用唤醒锁，系统认为它在“偷电”，就把它关进了小黑屋。
核心区别：Doze模式针对的是设备状态（静止+灭屏），App Standby针对的是App使用频率（用户很久没打开）。两者可以同时生效。
唤醒锁在Doze模式下的限制
唤醒锁在Doze模式下会受到严格限制。我记得有个同事问我：“我明明持有了唤醒锁，为什么App还是被休眠了？”
答案是：在Doze模式下，系统会忽略部分唤醒锁的请求。具体来说：
- PARTIAL_WAKE_LOCK：在Doze模式下会被系统忽略，除非App在白名单中
- FULL_WAKE_LOCK：同样受限，而且Android 7.0以后基本废弃了
- SCREEN_DIM_WAKE_LOCK：Doze模式下屏幕都关了，这个锁自然也没用
为什么会这样？因为Doze模式的设计初衷就是“强制省电”，如果唤醒锁还能随意使用，那Doze模式就形同虚设了。
避坑指南：我曾经在Doze模式下尝试用唤醒锁保持网络连接，结果发现App在深度Doze阶段完全断网。后来改用高优先级Firebase Cloud Messaging（FCM）才解决问题。记住：Doze模式下不要依赖唤醒锁做关键任务。
AlarmManager与唤醒锁
AlarmManager是Doze模式下少数能“叫醒”系统的机制之一。但要注意，从Android 6.0开始，AlarmManager的行为也变了。
set() vs setAndAllowWhileIdle()
传统的set()方法在Doze模式下会被延迟执行。系统会把多个闹钟合并到一起，在下一个“维护窗口”统一触发。这个维护窗口大概每几分钟出现一次。
而setAndAllowWhileIdle()则允许闹钟在Doze模式下仍然触发，但频率有限制：
- 每个App每分钟最多触发一次
- 每个App每小时最多触发几次（具体取决于系统版本）
我建议用setExactAndAllowWhileIdle()来做精确闹钟，但别滥用。曾经有个App每30秒设一个闹钟，结果被系统直接拉黑了所有闹钟请求。
AlarmManager与唤醒锁的配合
AlarmManager触发时，系统会自动持有一个唤醒锁，保证你的onReceive()方法能执行完。但这个唤醒锁只持续几秒钟。如果你的任务需要更长时间，需要自己申请唤醒锁。
// 在BroadcastReceiver中处理AlarmManager回调
public class MyAlarmReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
// 系统自动持有唤醒锁，但时间很短
PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyAlarm:WakeLock");
wl.acquire(10000); // 自己申请10秒的唤醒锁
// 执行耗时任务
doHeavyWork();
// 记得释放
if (wl.isHeld()) {
wl.release();
}
}
}个人经验：我习惯在AlarmManager回调中先申请一个短时间的唤醒锁（5-10秒），然后启动一个IntentService来处理实际任务。这样既不会阻塞主线程，又能保证任务完成。
知识体系图
实际项目中的避坑指南
我在多个项目中踩过Doze模式和唤醒锁的坑，总结了几条经验：
- 不要假设唤醒锁永远有效：在Doze模式下，唤醒锁可能被系统忽略。关键任务要用AlarmManager或FCM。
- AlarmManager的setExact()在Doze模式下不精确：系统会合并闹钟，误差可能达到几分钟。如果需要精确触发，用
setAlarmClock()。 - App Standby的检测周期是动态的：系统会根据用户使用习惯调整判断周期。不要依赖固定的时间窗口。
- 白名单不是万能药：虽然可以引导用户把App加入电池优化白名单，但Google Play审核时会限制这种做法。
一句话总结：Doze模式和App Standby是Android系统为了省电而设计的“强制休眠”机制。唤醒锁在Doze模式下会被限制，AlarmManager是少数能突破限制的工具，但也要合理使用。记住：系统省电是第一优先级，你的App任务只能排在第二位。
嗯，这些内容基本覆盖了Doze模式、App Standby、唤醒锁限制和AlarmManager的核心要点。实际开发中，我建议你多看看系统日志（dumpsys deviceidle和dumpsys alarm），能帮你快速定位问题。