Android M+ Doze Mode理解与测试：适配认知空白求助

嘿，很高兴你在为适配Doze模式努力——这对Android生态的健康确实很重要！我来帮你把Doze的运行机制、限制规律理得明明白白，填补你说的认知空白：

触发条件（缺一不可） #

• 设备完全静止（系统通过加速度传感器判定，轻微晃动都可能阻止触发）
• 设备处于锁屏状态（亮屏或解锁时不会进入Doze）
• 设备未充电（充电状态下Doze会被完全禁用）
• 无用户交互达到系统阈值（你实测的半小时是原生Android的默认值，部分厂商可能根据自家UI微调这个时间）

维护窗口的规律 #

你观察到的首次维护窗口是对的，进入Doze后的第一个窗口会在10-30分钟内出现。之后的窗口间隔是指数级增长的：

• 第一个窗口后，间隔约1小时
• 接下来是2小时、4小时，最长会达到6小时（不同厂商可能有小幅调整，但整体趋势一致）
• 每个维护窗口的时长通常在1-5分钟左右，期间系统会暂时解除Doze的所有限制，允许应用完成同步、网络请求、JobScheduler任务执行等操作

Doze模式下的核心限制 #

• 禁止使用唤醒锁（WakeLock），除非是在维护窗口或用户主动唤醒设备时
• 限制网络访问：只有维护窗口内、设备被唤醒（解锁/充电）时，应用才能发起网络请求
• 普通AlarmManager任务会被延迟到下一个维护窗口执行；只有setExactAndAllowWhileIdle()（关键低频次任务用）或setAlarmClock()（仅闹钟类应用建议用）能突破这个限制
• 禁止后台启动Service，除非是系统触发的高优先级场景（比如收到FCM高优先级推送）

• 用JobScheduler或WorkManager替代后台Service：这两个API会自动适配Doze，将任务调度到维护窗口执行，不用自己处理复杂的时机判断
• 尽量避免使用唤醒锁：依赖系统的调度机制，而非强制保持设备唤醒，这才是合规的做法
• 慎用setExactAndAllowWhileIdle()：这个API确实能在Doze期间执行任务，但频繁调用会严重影响电池续航，也可能被部分厂商的电池优化策略限制
• 测试时可以用adb命令快速触发Doze，不用等半小时：

  # 强制进入Doze模式
  adb shell dumpsys deviceidle force-idle
  # 退出Doze模式
  adb shell dumpsys deviceidle unforce
  

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