Android Service中Kotlin协程delay息屏省电场景下触发不准确问题咨询

核心是Android系统的低功耗管控机制导致：

• Android 6.0及以上版本引入了Doze模式、应用待机模式，Android 7.0之后进一步收紧了管控规则。当设备息屏、使用电池供电、无用户操作静置一段时间后，系统会进入深度低功耗状态，冻结所有非系统白名单应用的普通后台任务调度，以此减少耗电。
• Kotlin协程的delay函数在Android平台默认基于Handler实现，和Handler.postDelayed本质相同，都依赖应用进程的Looper消息队列调度。Doze模式下应用进程的非高优先级消息会被系统暂停处理，直到设备被点亮唤醒才会恢复调度，因此会出现你观察到的「息屏时delay暂停计时，亮屏后继续走完剩余时间」的现象。
• 你之前尝试的方案都不生效的原因：
  • Handler和协程delay属于同一类调度逻辑，同样受Doze限制
  • 前台服务仅能提升应用进程的存活优先级，无法豁免系统对普通任务调度的冻结规则
  • Wifi锁仅能维持Wifi连接状态，不影响CPU的休眠调度逻辑
  • 进程是否独立和该问题无关，只要是当前应用的进程，都受系统省电策略管控
• 亮屏、插电源、连接ADB时调度正常，是因为这几种场景下系统不会触发Doze模式的限制规则。

根据你的业务对延迟精度的要求，可以选择不同的方案：

1. 高精度触发场景：使用AlarmManager实现精确延迟 #

这是最稳定的解决方案，AlarmManager的setExactAndAllowWhileIdle接口可以在Doze模式下也能正常唤醒设备执行任务，不受进程调度冻结影响。

适配要求 #

• Android 12及以上版本需要在Manifest中声明SCHEDULE_EXACT_ALARM权限，触发延迟前需要检查用户是否授予了该权限
• 可以配合suspendCancellableCoroutine封装和delay用法一致的精确延迟接口，最小程度修改原有协程代码

示例代码 #

首先在Manifest中声明所需权限：

<uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" />
<uses-permission android:name="android.permission.WAKE_LOCK" />

封装精确延迟的suspend函数：

private const val ACTION_DELAY_TRIGGER = "com.your.package.DELAY_TRIGGER"
private const val REQUEST_CODE = 1001

suspend fun exactDelay(millis: Long) = suspendCancellableCoroutine<Unit> { cont ->
    val alarmManager = getSystemService(Context.ALARM_SERVICE) as AlarmManager
    val pendingIntent = PendingIntent.getBroadcast(
        this,
        REQUEST_CODE,
        Intent(ACTION_DELAY_TRIGGER).setPackage(packageName),
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
    )
    // 设置RTC_WAKEUP类型闹钟，休眠状态下也能唤醒触发
    alarmManager.setExactAndAllowWhileIdle(
        AlarmManager.RTC_WAKEUP,
        System.currentTimeMillis() + millis,
        pendingIntent
    )
    // 注册广播接收闹钟触发事件
    val receiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context?, intent: Intent?) {
            unregisterReceiver(this)
            cont.resume(Unit)
        }
    }
    registerReceiver(receiver, IntentFilter(ACTION_DELAY_TRIGGER))
    // 协程取消时同步取消闹钟和广播
    cont.invokeOnCancellation {
        unregisterReceiver(receiver)
        alarmManager.cancel(pendingIntent)
    }
}

替换原有代码中的delay即可：

delayedJob = CoroutineScope(serviceScope).launch {
    exactDelay(WAIT_TIME_MILLIS)
    doDelayedWork()
}

2. 申请电池优化豁免 #

引导用户将你的应用加入系统电池优化白名单，可大幅降低Doze模式对应用的管控力度，普通的delay和Handler调度就可以正常执行。

注意事项 #

• 该方案需要主动提示用户跳转系统设置页手动开启，无法静默获取权限
• Google Play对该权限的使用有严格限制，仅允许有后台运行刚需的应用申请，不符合要求的应用可能会被下架
• 国内厂商定制ROM（小米、华为、OPPO等）大多有独立的省电管控规则，即使申请了系统级电池豁免，还需要引导用户开启对应厂商的后台运行权限、自启动权限等

3. 低精度场景：使用WorkManager #

如果你的业务对延迟触发的时间精度要求不高（允许有几分钟到十几分钟的误差），可以使用Jetpack WorkManager的一次性延迟任务，WorkManager会自动适配Doze模式，在系统的维护窗口中执行任务，无需额外适配权限。

4. 特殊场景：持有CPU唤醒锁 #

如果你的应用是系统内置应用、或者面向root设备开发，可以持有PARTIAL_WAKE_LOCK锁，强制CPU保持运行状态，不会进入深度休眠，原有协程delay逻辑无需修改即可正常运行。该方案耗电极高，普通应用不推荐使用。

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