WakeLock究竟可阻止哪些系统行为？API31+ PARTIAL_WAKE_LOCK相关疑问

核心误解是把两个不同层级的“休眠”概念混为一谈了：wake lock相关文档里提到的“设备进入休眠”，并不是指Android 6.0才新增的Doze模式——wake lock这套机制从Android早期版本就已存在，远早于Doze的推出。

两个“休眠”的本质区别 #

• 传统浅休眠：屏幕熄灭后经过短时间无操作，系统会降低CPU运行频率、暂停未持锁进程的后台调度，减少无意义耗电。PARTIAL_WAKE_LOCK的原始作用就是在这个阶段生效，阻止CPU进入挂起状态，哪怕屏幕是灭的，也能保证持锁进程拿到CPU资源跑完任务，这就是官方文档表述的本来含义。
• Doze模式：是后来新增的更高优先级的深度电源优化策略，只有设备灭屏、静置、未插电，且持续较长时间无操作（AOSP原生逻辑是分阶段递进，从初始浅Doze到最终深度Doze最长需要1小时左右）才会进入，这套策略的调度优先级比普通wake lock高得多。

API 31及以上版本PARTIAL_WAKE_LOCK的明确生效边界 #

“非白名单应用的wake lock完全失效”是错误认知，它的生效规则非常清晰：

• 非Doze场景下100%生效：包括屏幕点亮使用时、灭屏后尚未进入Doze的时间段、设备插电充电时，不管应用有没有进电池优化白名单，持有的PARTIAL_WAKE_LOCK都能正常阻止CPU休眠，保障任务运行。唯一的原生限制是从Android 12开始，后台应用单次持锁最长不能超过10分钟，超时系统会强制释放锁，和应用是否在前台无关。
• 深度Doze场景下非白名单应用的锁会被临时屏蔽：一旦系统进入深度Doze状态，会直接忽略所有非豁免应用持有的wake lock，按Doze规则统一挂起进程、限制CPU访问，只有在Doze定期开放的短暂维护窗口内，锁的效果才会临时恢复，窗口关闭后会再次被屏蔽。这也是“持有PARTIAL_WAKE_LOCK无法阻止Doze触发”的真实意思——wake lock的权限层级低于Doze这个系统级电源策略，根本没有权限阻止Doze启动。
• 电池优化白名单应用不受Doze限制：加入白名单的应用属于官方明确的部分豁免场景，哪怕在深度Doze状态下，持有的PARTIAL_WAKE_LOCK也能正常生效，同时保留网络访问权限，和Doze standby文档的表述完全对应。

额外适配提醒 #

国产定制ROM大多会在AOSP原生规则基础上做更激进的后台限制，不少厂商会在灭屏后远早于原生默认时间点，就强制屏蔽非自启白名单应用的wake lock、甚至直接杀后台，这属于厂商自定义修改，和Android原生API的预期行为无关，做落地适配的时候需要单独针对厂商规则做处理。

内容的提问来源于stack exchange，提问作者user19309143