DeviceIdleController的启动与状态转换
各位同学，今天我们来啃一块硬骨头——DeviceIdleController的启动流程和状态机。说实话，这块代码我前前后后看了不下五遍，每次都有新收获。你想想看，Doze模式是整个Android电源管理的核心，而DeviceIdleController就是它的心脏。心脏怎么跳动的，咱们得搞清楚。
一、启动流程：从SystemServer到DeviceIdleController
DeviceIdleController是在SystemServer启动时被创建的。我记得第一次跟这个流程时，在SystemServer.java里找了半天才找到它的身影。
启动路径大致是这样的：
- SystemServer的main()方法启动
- 调用startOtherServices()
- 在其中创建DeviceIdleController实例
- 调用其onStart()方法
- 注册到ServiceManager
- 发布系统服务
来看核心代码，在SystemServer.java中：
// SystemServer.java - startOtherServices()
try {
Slog.i(TAG, "启动DeviceIdleController");
deviceIdleCtrl = new DeviceIdleController(context);
ServiceManager.addService(Context.DEVICE_IDLE_CONTROLLER, deviceIdleCtrl);
} catch (Throwable e) {
reportWtf("启动DeviceIdleController失败", e);
}
嗯，这里要注意。DeviceIdleController的构造函数里做了很多初始化工作。我个人习惯在阅读源码时，先看构造函数，因为它决定了这个对象的初始状态。
关键点：DeviceIdleController在构造时，会读取系统配置的doze参数，比如空闲检测时间、预测超时时间等。这些参数定义在config.xml中。
二、状态机：五个核心状态
DeviceIdleController内部维护了一个状态机。说白了，就是根据设备的使用情况，在不同状态间切换。我曾经在项目中遇到过一个问题，设备死活不进Doze，最后发现是状态机卡在了某个中间状态。
五个核心状态如下：
| 状态 | 含义 | 触发条件 |
|---|---|---|
| ACTIVE | 活跃状态 | 设备正在被使用 |
| INACTIVE | 非活跃状态 | 屏幕关闭且无交互 |
| IDLE_PENDING | 即将进入空闲 | 非活跃状态持续一段时间 |
| SENSING | 传感器检测 | 检测设备是否静止 |
| IDLE | 深度空闲 | 满足所有条件后进入 |
为什么需要这么多状态？你想想看，如果直接从ACTIVE跳到IDLE，那用户体验得多差。系统需要一步步确认设备真的空闲了，才能进入省电模式。
三、状态转换的核心逻辑
状态转换的核心方法在DeviceIdleController.java中，叫stepIdleStateLocked()。这个方法每次被调用时，都会根据当前状态决定下一步动作。
我给大家画个流程图，这样更直观：
看到这个图，你应该能理解状态转换的大致脉络了。从ACTIVE到IDLE，中间要经过INACTIVE、IDLE_PENDING，有时候还要经过SENSING。每一步都有超时控制，超时时间由系统配置决定。
四、关键代码解析：stepIdleStateLocked()
这个方法我建议你重点看。它就像一个状态机调度器，每次被调用时都会检查当前状态，然后决定下一步。
// DeviceIdleController.java - stepIdleStateLocked()
void stepIdleStateLocked() {
switch (mState) {
case STATE_ACTIVE:
// 屏幕关闭后，进入INACTIVE
scheduleAlarmLocked(mInactiveTimeout, false);
mState = STATE_INACTIVE;
break;
case STATE_INACTIVE:
// 等待一段时间后，进入IDLE_PENDING
scheduleAlarmLocked(mIdlePendingTimeout, false);
mState = STATE_IDLE_PENDING;
break;
case STATE_IDLE_PENDING:
// 准备进入IDLE，先检查传感器
scheduleAlarmLocked(mSensingTimeout, false);
mState = STATE_SENSING;
break;
case STATE_SENSING:
// 传感器确认静止后，进入IDLE
mState = STATE_IDLE;
// 通知其他组件进入Doze
becomeIdleLocked();
break;
}
}
个人经验：我曾经在调试一个平板设备时，发现它总是卡在SENSING状态。后来定位到是加速度传感器驱动有问题，一直返回非静止状态。所以如果你遇到设备不进Doze，先检查传感器数据是否正常。
五、避坑指南：状态转换中的常见问题
在实际开发中，状态转换这块容易出问题的地方不少。我给大家总结几个：
- 超时时间配置不合理：有些厂商把mInactiveTimeout设得太短，导致设备频繁进出Doze，反而更耗电。
- 传感器异常：就像我刚才说的，传感器数据异常会导致状态卡住。
- 闹钟唤醒冲突：AlarmManager的闹钟可能会打断状态转换流程。
- 多用户场景：在多用户模式下，状态管理会更复杂，需要额外处理。
注意：千万不要在状态转换的回调中做耗时操作。我见过有开发者在becomeIdleLocked()里做网络请求，结果导致ANR。状态转换的回调应该只做轻量级操作。
六、总结
DeviceIdleController的启动和状态转换，说白了就是一套精心设计的省电策略。系统通过状态机来逐步确认设备是否真的空闲，然后才进入深度省电模式。这个设计思路很巧妙，既保证了省电效果，又不会影响用户体验。
我个人觉得，理解这套状态机是掌握Doze模式的关键。你只要把五个状态和它们之间的转换条件搞清楚了，后续的代码分析就会轻松很多。
好了，这一章的内容就到这里。记住，多看源码，多动手调试，才能真正吃透这套机制。
公众号:蓝海资料掘金营，微信deep3321