2. Doze模式的核心原理：状态机模型、空闲状态检测、省电策略
各位同学，今天我们来啃Doze模式最核心的骨头。说白了，Doze就是一套让手机在你不碰它的时候，偷偷省电的机制。我当年刚接触这个模块时，第一反应是——这不就是个定时器吗？后来深入源码才发现，事情远没那么简单。
2.1 状态机模型：Doze的骨架
Doze模式本质上是一个有限状态机。它一共就四个状态，但每个状态之间的切换逻辑，才是真正的精髓。
核心状态一览：
- ACTIVE：正常活跃状态，啥都不限制
- IDLE_PENDING：即将进入空闲，系统开始做准备工作
- IDLE：深度空闲，省电大招全开
- IDLE_MAINTENANCE：维护窗口，给App一点喘息时间
我习惯把状态机想象成一个漏斗。用户在使用时，水是畅通的；一旦屏幕关闭，漏斗开始收窄；进入IDLE后，基本就只剩一条缝了。但系统也不能完全堵死，所以每隔一段时间，会打开一个维护窗口，让紧急消息通过。
嗯，这里要注意：从IDLE_MAINTENANCE出来，有两个去向。如果维护窗口内用户没碰手机，就回到IDLE继续省电；如果用户解锁了屏幕，直接跳回ACTIVE。我见过不少开发者在测试时，发现手机进了IDLE就出不来，其实就是没处理好这个回退逻辑。
2.2 空闲状态检测：系统怎么知道你睡着了？
Doze不会因为你关了屏幕就立刻进入省电模式。它有一套严格的检测机制。我个人觉得，这套机制的设计思路非常值得学习——宁可漏判，不可误判。
检测条件清单：
- 屏幕关闭（最基础的条件）
- 设备处于静止状态（通过加速度传感器判断）
- 未连接充电器
- 未处于通话中
- 未播放音乐或视频
- 未开启热点或投屏
为什么说宁可漏判？你想啊，如果系统误判你睡着了，把微信的网络给断了，结果你正等着收验证码呢——那用户体验就崩了。所以Google的策略是：条件必须全部满足，才进入IDLE_PENDING。
我曾经在项目中遇到过一个问题：某款平板电脑，屏幕关了之后死活不进Doze。查了两天，最后发现是陀螺仪一直有微小漂移，系统认为设备在移动。后来加了一个死区阈值，问题解决。这种坑，你不踩一次真的记不住。
2.3 省电策略：Doze到底干了什么？
进入IDLE状态后，系统会做三件大事。我习惯把它们称为「三板斧」。
| 策略 | 具体行为 | 影响范围 |
|---|---|---|
| 网络限制 | 禁止App访问网络，Wi-Fi和移动数据均受限 | 所有App（除白名单） |
| 闹钟延迟 | 将AlarmManager的闹钟合并到维护窗口执行 | set()和setInexactRepeating() |
| WakeLock忽略 | App申请的WakeLock不再有效 | 部分WakeLock类型 |
说白了，Doze就是告诉App们：「你们先歇会儿，等维护窗口到了再干活。」但这里有个关键点——白名单机制。系统会保留一小部分高优先级App的权限，比如闹钟、短信、电话等。这个白名单，用户可以在设置里手动添加。
避坑指南：我曾经见过一个即时通讯App，为了绕过Doze限制，每隔几分钟就申请一个PARTIAL_WAKE_LOCK。结果呢？手机电量哗哗地掉，用户直接给了一星差评。正确的做法是使用高优先级Firebase Cloud Messaging（FCM），让系统来调度推送。
2.4 维护窗口：唯一的透气口
Doze不是把App完全憋死。每隔一段时间，系统会打开一个维护窗口。这个窗口的时长和频率，由系统动态计算。
我记得Android 6.0刚推出时，维护窗口是固定的——每30分钟一次，每次30秒。后来发现这个策略太死板了。到了Android 7.0，改成了动态调整：如果设备长时间不动，维护间隔会越来越长，从30分钟逐渐拉长到2小时甚至更久。
// 伪代码：维护窗口调度逻辑
if (deviceInIdle) {
// 初始间隔30分钟
long maintenanceInterval = 30 * 60 * 1000;
// 每次维护后，间隔增加1.5倍
maintenanceInterval *= 1.5;
// 上限2小时
maintenanceInterval = Math.min(maintenanceInterval, 2 * 60 * 60 * 1000);
scheduleNextMaintenance(maintenanceInterval);
}这个设计很聪明。你想想看，如果你把手机放在桌上睡觉，前半小时可能还有消息进来，所以维护频繁一点。到了凌晨三点，基本没人找你了，那就少醒几次，多省点电。
2.5 状态切换的触发时机
最后，我们来梳理一下状态切换的完整流程。我习惯用时间线来理解：
- 第0秒：用户按下电源键，屏幕关闭。系统进入IDLE_PENDING。
- 第30秒：系统检查所有条件（静止、未充电等），满足则进入IDLE。
- 第30分钟：第一个维护窗口打开，App可以处理网络请求和闹钟。
- 第30分钟+30秒：维护窗口关闭，回到IDLE。
- 第75分钟：第二个维护窗口（间隔已拉长）。
- 任意时刻：用户拿起手机，屏幕亮起，瞬间回到ACTIVE。
嗯，这里有个细节容易被忽略：从IDLE_PENDING到IDLE的等待时间，不是固定的30秒。系统会根据设备的使用习惯动态调整。如果系统发现你经常在关屏后很快又亮屏，它会延长这个等待时间，避免频繁进出IDLE造成功耗浪费。
好了，Doze的核心原理就讲到这里。下一节我们会深入源码，看看这些状态切换在代码层面是怎么实现的。到时候我会带大家一行一行地读DeviceIdleController.java，那才是真正过瘾的地方。