Android Doze模式完整解析：状态机、维护窗口与开发者适配

1. 项目背景：为什么Doze模式值得单独开一篇

把Doze模式放到“PowerManagerService下篇”来写，是因为它跟唤醒锁、屏幕状态这些常见的PowerManager用法完全不同。唤醒锁解决的是一句话的问题：“系统你别睡，我要干活”。Doze恰恰是反过来的：“系统，你睡踏实点，把那些虚头巴脑的后台活儿都摁住”。这种反向逻辑，最容易让开发者在适配时翻车。

PowerManagerService本身是安卓系统所有电源状态的总控，但它并不负责Doze的全部实现。真正干活的还有DeviceIdleController，一个挂在SystemServer里的兄弟模块。两者配合的方式大致是：PowerManagerService管屏幕开关、唤醒状态、WakeLock统计，DeviceIdleController管状态机迁移、白名单、维护窗口的调度。Doze一旦进入深度休眠，PowerManagerService那边的大部分唤醒源都会被压住。所以你在应用层看到的“怎么又有WakeLock还是被杀”这种奇怪现象，往往不是WakeLock没生效，而是Doze阶段系统压根不买账。

这篇文章适合谁看？一种是做应用适配的开发者，你不需要知道DeviceIdleController里每一行代码，但你必须知道什么API在Doze下还能用、什么API会被延长执行，以及怎么用dumpsys验证你的判断。另一种是做系统定制或性能优化的同学，这部分的帮助更直接：整条状态机的迁移路径、维护窗口的长度、白名单位置，都能从Android开源系统源码里找到对应常量，但不同厂商改得五花八门，我这边会尽量给出可操作的经验而不是让你去背源码。

打开AndroidStudio看PowerManagerService有一种看战斗机的仪表盘一样的感觉——功能太多，但真正影响用户续航的就是几个核心阀门。Doze是这些阀门里最重的那个。你想理解电池优化，就必须理解Doze；你想理解Doze，就必须先把它的状态机和维护窗口看明白。这篇文章就围绕这两件事展开，最后落到排查手段和常见坑上。

2. Doze模式的两个阶段：浅睡与深睡

2.1 轻量Doze和深度Doze的区别

从Android 7之后，Doze实际上被拆成了两层。后来大家习惯叫Light Doze和Deep Doze，代码里对应的是device_idle_light和device_idle_full两条状态机。

轻量Doze的门槛低。设备灭屏、拔掉充电器、放置一小段时间，不管你在不在走路，它都可能进入浅睡。在浅睡阶段，系统还会给应用留活路：网络访问被允许但被批量集中，JobScheduler的任务可以从平时的几分钟推迟到十几分钟，但不会完全卡死。音乐的播放、运动数据的采集这类前台服务，在轻量Doze下基本不受影响。

深度Doze就要严格得多。除了灭屏和拔电，设备还必须处于“静止”状态，甚至不能有太大晃动。满足条件后，系统会给你一个比较长的观察窗口，比如默认可能需要半小时左右的静止时间，才会稳稳进入深度Doze。在深度Doze里，应用持有的普通网络访问会被直接掐断，AlarmManager的普通闹钟会被拖到下一个维护窗口，pending的Job如果没设对约束条件，可能等很久才轮到一次执行机会。

对普通用户来说，这两层Doze的差别没那么直观，因为续航感受是叠加的。但对开发者来说，必须搞清楚你的功能在浅睡和深睡下分别会被压成什么样。很多应用在浅睡阶段表现正常，用户把它放桌上半小时后开始丢消息，这就是进入了深度Doze的典型特征。

2.2 Doze状态机的关键节点

DeviceIdleController的状态机虽然细节多，但核心节点很好理解。我一般跟人解释时画一张这样的表：

我不太建议大家去死记默认时间常量，因为不同Android版本和不同厂商ROM调得差别很大。但状态迁移的大方向是一致的：从ACTIVE走到IDLE_PENDING需要“灭屏+静止”，从IDLE_PENDING走到IDLE需要“再来一段时间的等待”，进入IDLE之后，系统会每隔一段时间开一个维护窗口。

维护窗口是理解Doze的钥匙。系统在深度Doze里不是完全断网，而是把“网络请求”和“任务执行”攒起来，到点了统一放行。窗口很短，而且随着Doze时间拉长，窗口之间的间隔会变大。官方文档喜欢说“系统每天能把网络使用维持在15分钟以内”，这句话的意思就是维护窗口在极大程度上压缩了后台网络总时长。

2.3 维护窗口：系统在Doze里到底做了什么

维护窗口存在的原因很实际：完全掐死网络会让系统自身的云同步、安全证书更新、紧急消息推送都失效，用户没法接受这种“省电省到连消息都收不到”的结果。所以系统留了一条小缝，周期性的短窗口里允许必要的任务跑一跑，跑完继续睡。

窗口里能做什么，也是有讲究的。不是所有Job都能在维护窗口跑，JobScheduler会判断任务的约束条件和优先级。比如setRequiresCharging并且当前没插电的任务，维护窗口也帮不了你；而setRequiresDeviceIdle(true)这种任务，在维护窗口反而更可能被选中执行。到了AlarmManager这里，维护窗口同样只放行那些明确标记了“即使在Doze里也要尝试执行”的闹钟。

我经常看到有人用持久化服务去保活，以为服务起来了就能保证任务执行。在Doze面前，这种思路基本没戏。系统会通过forceStopPackage或者停止解析广播、挂起任务等手段，让没有前台可见性的应用彻底失去CPU。维护窗口不是后台服务的避难所，只是系统给自己开的稳妥通道。所以开发者真正该做的，是把任务交给JobScheduler或WorkManager这类能理解Doze窗口的组件，而不是自己注册一大堆Service。

3. 电池优化的完整拼图：Doze只是其中一块

3.1 App Standby Buckets：按使用频率分桶

Doze管的是“设备整体休眠”，App Standby则是“针对单个应用懒散程度”的管理。两者经常一起出现，因为效果叠加：设备进入Doze，同时某个应用被标记为不活跃，那它就更加没机会碰网络和CPU了。

从Android 9之后，App Standby变成了一个更精细的分桶模型。大致的桶位有活跃、常用、低频、罕见这么几档。系统根据你使用应用的频率、最近一次打开时间、有没有前台服务或通知，把一个应用扔进对应的桶里。桶位越往下，JobScheduler的任务延迟越久，网络使用也被压得越狠。

想确认某个应用落在哪个桶，各家系统命令不完全一样，但大体可以这么查：

adb shell dumpsys appstandby adb shell am get-standby-bucket com.example.someapp

实测中最容易踩的坑是：刚装完的应用，使用频率还没建立起来，系统可能先把它分到低频或罕见桶，然后你的重大任务正好被拖后。这种时候不要慌，把应用“打开一次”并保持几分钟前台使用，系统会重新评估桶位。用户那边最直观的投诉“后台消息收不到”，大多数时候跟这个分桶有直接关系。

3.2 后台执行限制与厂商加码

Doze和App Standby背后还有第三板斧,Android 8之后的后台执行限制。前台服务之外的Service，在应用被切换到后台后，系统只给你几分钟的窗口，时间到了就停掉；隐式广播除了系统豁免的那几个，基本全被禁止。这三板斧组成了一套连环拳：后台运行被限制、应用再被分到低频桶、设备再进入Doze，活生生把一个应用逼到前台。

对厂商ROM来说，这还不够。很多定制系统在AOSP基础上又做了一层“智能后台管理”，有些直接把应用杀得比原生更狠。你写一个标准的JobScheduler任务，在原生系统上等到维护窗口就能执行，在定制系统上可能连JobScheduler都被判定为“不受信任的调度器”，直接延迟到用户手动打开应用才触发。

这里特别提醒大家：不要在保活思路上死磕。系统定制层的“加码”是故意为之，普通应用靠自启动、双进程守护这些手段既不合法商业道德，现实中也很难突破。我把话放这儿：App Store审核越来越严，系统也越封越死，与其跟平台对抗，不如把功能设计成“前台可见、用户可感知”的形态。

3.3 白名单机制：坑比想象的多

Doze和App Standby都有白名单机制。应用可以引导用户去系统设置里关闭电池优化，从而获得豁免。这个机制看起来香，实际坑得很。

PowerManager提供了ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS和ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS两个Action。前者可以直接弹一个“是否允许忽略电池优化”的对话框，后者只是把你带到设置页面。要注意，ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS在应用商店政策里是很敏感的东西，如果你不是闹钟、消息推送、企业设备管理这类“用户能理解为什么需要豁免”的应用，审核时很容易被打回。

就算用户点了允许，白名单也不是万能的。我见过不少应用拿到白名单后，又在Doze的维护窗口之外疯狂拉取网络，结果设备耗电飙升，最后用户还是手动把它干掉了。白名单的本意是“允许你更早执行特定任务”，不是“允许你为所欲为”。滥用白名单的后果，比你不用白名单更严重，因为系统后续的省电策略会对你更狠，用户也会用脚投票卸载你。

4. 开发者如何正确适配Doze

4.1 任务调度：选对JobScheduler和WorkManager

后台任务首选JobScheduler，或者基于它封装的上层库。原因不是JobScheduler有多快，而是它天然理解Doze的维护窗口。你在JobScheduler里声明一个任务，系统把它塞进队列，等到网络可用、充电条件满足、甚至维护窗口打开时，它才被执行。这在Doze下反而是优势，因为你不用自己盯着网络状态。

WorkManager的上层API会把约束条件转成JobScheduler的约束，开发者写起来更省心。需要注意的一个细节：WorkManager的任务默认没有强制指定“随便什么时候跑都行”这种优先级，所以你如果在任务里加了网络约束，又恰好遇到Doze，它的执行时间就可能是个小时级别。如果业务上能接受这个延迟，不用改；如果不能接受，你得把它升级为前台服务，让用户看到你的存在。

我用一个很实际的例子说明。某开发者的应用需要每天凌晨上传一次日志，他用WorkManager加了setRequiredNetworkType(CONNECTED)。结果用户反馈日志总是少传，查到最后是因为设备经常在凌晨进入深度Doze，维护窗口又刚好短，任务一拖再拖。后来改成“充电时上传”，并且把上传动作放在应用数据变更后立即触发一次，问题才解决。这里的关键不是任务调度器选错了，而是没有理解“延迟执行是Doze的常态”。

4.2 闹钟该用什么API

很多IM和外卖应用里的“预约提醒”功能，在Doze下会莫名其妙不响，根本原因是用了AlarmManager的普通set或setExact。系统在深度Doze下可以延迟这些闹钟，甚至合并多个闹钟到一个维护窗口执行。解决办法是看你的提醒到底有多强时效性。

如果是真正的闹钟、日历事件提醒，或者用户在界面上明确设置的“到点必须提醒”的场景，用setExactAndAllowWhileIdle。这个API在Doze下允许执行，但别忘了它也有频率限制，长时间Doze期间，系统不允许你频繁地弹精确闹钟。此时setAlarmClock是优先级更高的选择，系统会为它保留闹钟槽位，甚至在Doze下帮你处理到点唤醒。很多开发者不知道的是，setAlarmClock还会让系统在状态栏显示一个闹钟图标，这既是用户预期，也是系统给你“高优先级”的依据。

我在实际项目里遇到过另一种坑：应用为了省电，把提醒任务的约束设成了“充电时执行”。用户晚上插着电睡觉，早上闹钟应该响，结果没响。排查后发现，因为设备在充电时其实不太容易进入深度Doze，但那个约定俗成的“充电时执行”被系统解读成“只有充电时才允许执行，不充电就无限挂起”，待到用户拔电那一下，系统又正好进入了Doze的窗口，闹钟被无限期挤压。后来改成“仅当插电时设置提醒，否则用setAlarmClock”，逻辑就顺了。

4.3 推送与高优先级消息在Doze下的表现

推送消息能不能秒达，是Doze下应用最揪心的问题。Doze能压住普通网络连接受限，系统也把很多推送消息延迟到维护窗口。所以单纯靠长连接收推送的应用，在Doze下大概率收消息延后，用户觉得“你是不是没用后台了”。

高优先级推送消息可以临时唤醒设备意图，但这不是无限度的。系统会把高优先级推送当成一个“短暂解锁Doze白名单”的机会，让应用有机会连接网络并处理消息。但如果你在收到推送后还要处理各种复杂任务，系统也不会一直等你，等到消息处理完，设备很快会重新睡回去。

这里给一个经验：不要在收到推送的广播里做重型任务，包括下载图片、初始化SDK、上报数据。推送到达后，先把消息存起来，让用户看到通知，真正的业务动作放到一个简短的Job里，或者干脆等用户点开通知再处理。这样既不会引起系统怀疑，也能让消息体验更顺畅。

4.4 别滥用白名单，也别把用户带到设置页乱点

适配Doze的最后一条底线是白名单。很多应用动不动就引导用户去关闭电池优化，这个交互在用户眼里等于“你让我关掉安全系统”。实际转化率低，还会让系统商店的审核人员心生警惕。

合理的使用姿势是：当你的核心功能确实因为Doze而不可用时，再引导用户去设置页。而且引导文案要说清楚为什么需要豁免，比如“消息接收可能被系统延迟，请允许应用保持后台运行”比“请允许忽略电池优化”强得多。能够的话，分两步走：先让用户理解问题，再让用户决定是否关闭优化。

如果拿不准你的应用是否属于该请求豁免的类型，我建议先自查：用户是否希望它随时在线？消息提醒是否属于刚需？如果答案是肯定的，再考虑白名单。否则老老实实适配Doze就够了。

5. 用dumpsys和日志一步一步排查Doze问题

5.1 模拟Doze状态

真机要等半小时静止太久，调试时可以手动模拟Doze。Android系统提供了两条命令，一条是把设备踢进Doze，一条是踢出来：

adb shell dumpsys deviceidle force-idle adb shell dumpsys deviceidle unforce

有的版本用cmd deviceidle代替dumpsys deviceidle效果相同。需要注意，force-idle只是让你快速看到状态变化，它不会真的模拟真实进入Doze前那一段“静止判定”。所以在force-idle之后，你看到的行为可能比真实Doze更激进，别拿它当最终结论。

更真实的模拟流程是：

1. 用adb shell dumpsys battery unplug模拟拔掉充电器；
2. 用adb shell input keyevent KEYCODE_SLEEP或者物理灭屏让设备进入灭屏；
3. 把设备放在桌上静止不动；
4. 等上几分钟后用adb shell dumpsys deviceidle查看状态；
5. 如果不想等，再手动force-idle缩短等待时间。

模拟过程中要特别关注“设备是否真的静止”这条。很多调试桌上有人走动、设备震动，会导致Doze迟迟不进入。我一般会把设备用厚书压住，并且关掉开发者选项里的“不锁定屏幕”这类干扰项。

5.2 关键dumpsys输出解读

dumpsys deviceidle的输出比较长，一开始会看到一堆白名单和配置参数，后面才是当前状态。你需要关注几个地方：

• mState=：这是Deep Doze的状态，正常情况下能看到DEVICE_IDLE_ACTIVE、DEVICE_IDLE_IDLE、DEVICE_IDLE_MAINTENANCE等值；
• mLightState=：这是Light Doze的状态；
• mIdleWhitelist=：当前被允许在Doze下不被限制的应用列表；
• mLastMaintenanceTime=：上一次维护窗口的时间，用来判断维护窗口是否触发过。

如果force-idle之后，mState变成了DEVICE_IDLE_IDLE，但应用的网络请求还是能发出，那基本上是白名单或前台服务在起作用。如果force-idle之后，应用马上被系统杀死，那要查的不只是Doze，还有后台执行限制这条线。

dumpsys power也有参考价值。看mWakefulness是不是Asleep，看mHoldingWakeLockSuspendBlocker是否为false。通常进入Doze后，WakeLock的保护会被解除，这个值会变成false。如果它一直是true，说明有某个系统服务或驱动死死拿住了suspend blocker，Doze可能进得去但醒不来，这问题要往内核底层查。

5.3 从系统日志里找到Doze触发证据

查看deviceidle的日志可以用logcat：

adb shell logcat -s DeviceIdleController

状态迁移会在关键节点打日志，比如从ACTIVE到INACTIVE、从INACTIVE到IDLE_PENDING、从IDLE_PENDING到IDLE。维护窗口的开始和结束也有对应日志。你在排查看不到日志时，先确认脚本里有没有加-v time或v threadtime，不然很难把日志跟设备行为对应上。

我曾经调试过一个“通知总是延迟”的案例，logcat里能看到应用每半小时被唤醒一次，但推送的时间老是不准。后来发现不是推送服务的问题，而是应用在Doze下依赖AlarmManager的普通闹钟定时轮询，闹钟被无限合并到了维护窗口。把轮询改成一次性高优先级推送唤醒后，通知延迟直接降到秒级。这再一次验证了，Doze问题大多数不是“没执行”，而是“执行时机没按你想的来”。

6. 常见问题速查与经验教训

6.1 一张表解决一半疑问

这张表不可能覆盖所有情况，但大部分日常开发遇到的Doze问题都能在这里找到方向。关键是先确认现象发生在哪个状态，再用dumpsys判断是不是Doze干的。

6.2 厂商设备上更容易踩的三个坑

厂商ROM是Doze问题的高发区。我总结三个高频坑。

第一，厂商比原生算法更激进。有些设备把深度Doze的进入时间从半小时压缩到十分钟，应用在原生测试没问题，一到厂商设备就各种被杀。应对办法不是跟厂商对抗，而是尽量让应用有前台可见性，比如通知栏常驻通知、前台服务。

第二，厂商的白名单入口位置经常变。原生Android的设置路径是“设置-电池-电池优化”，厂商设备可能藏在“应用管理-应用-电池”里。你给用户写引导文案时，别写死路径，给一个搜索关键字或者直接跳到目标页面的深层Intent更靠谱。

第三，自带的应用管理套件会叠加限制。很多厂商提供“自启动管理”“后台冻结”“智能限制”这类功能，它们跟Doze不冲突，但效果会叠加。用户就算关闭了电池优化，也可能被另一个开关挡住。做好用户教育，比写代码更有用。

6.3 我调试Doze时的几条土办法

第一，尽量用拔电模拟而非真实耗尽电量。dumpsys battery unplug能让你在不损失真电量的情况下还原“未充电”状态，调试完记得dumpsys battery reset，不然设备一直以为没插电，电源状态会混乱。

第二，不要只看一次dumpsys就下结论。Doze的维护窗口是有周期的，你今天看到的状态跟10分钟后可能完全不同。我习惯连续记录几次dumpsys结果，对比状态变迁的时间点，才敢判断问题到底出在哪一环。

第三，多用一个辅助应用来做对照实验。写一个什么都不干、但持有高优先级推送能力的空应用，与目标应用同时跑。如果空应用消息秒达，目标应用消息延迟，那问题大概率不在Doze而在目标应用自身的调度逻辑上。这个思路在复杂项目里非常省时间。

第四，别忽略“后台限制”这一层。很多人把Doze当成一切，其实后台执行限制也随时在生效。排查时可以先用adb shell am force-stop把应用杀了，再观察Doze状态下它是否会被自动重启。如果连重启都没有，那问题不一定是Doze，而是进程根本就没活着。

7. 收个尾：一点实在的感触

做了这么多年系统与应用调试，我对Doze的态度从最初的“烦死了”变成了“理解了”。它确实给开发者添了很多麻烦，但换个角度想，如果没有Doze，用户手机里的后台任务会无节制地消耗电池，整个安卓生态的续航口碑会比现在更糟。

真正难的不是适配Doze，而是理解“系统与你的目标并不一致”这个事实。你的应用想拼命保活，系统想拼命省电，双方博弈的结果就是用户看到的体验。高明的做法不是硬碰硬，而是顺着系统的规则重新设计你的功能：能用前台服务解决的问题就别藏后台，能交给JobScheduler的任务就别自己开线程，能等维护窗口的批量任务就别频繁唤醒设备。

最后分享一个小技巧，排查任何Doze相关问题前，先问自己一句：如果这个功能不需要网络也不需要定时，那么它在Doze下是不是真的必须运行？大部分时候你都会发现，业务方真正想要的是“用户感知到消息时能及时看到”，而不是“每一秒都要握着网络连接”。把需求想透了，技术方案自然就简单了。