Android协程自行或被系统取消的原因排查求助

• 自定义Dispatcher线程被回收：你通过Executors.newSingleThreadExecutor()创建的单线程池，当协程执行delay进入空闲状态时，线程池可能会回收空闲线程，导致Dispatcher失效，协程因此被取消。Android系统对后台线程的管理较为严格，自定义线程池没有系统级的存活保障。
• 未处理的异常导致协程终止：
  • saveDataToDB()如果抛出未捕获的异常，即使使用了SupervisorJob，当前启动的协程也会被直接取消，循环终止。
  • 协程被取消时，delay会抛出CancellationException，若未捕获该异常，协程会直接停止。
• 前台服务状态异常：虽然是前台服务，但系统在内存紧张时仍可能临时限制服务资源，或者服务因通知权限缺失（Android 12+需POST_NOTIFICATIONS权限）、通知被意外关闭等原因，被降级为后台服务，进而导致协程所在线程被终止。
• CoroutineScope的Job被意外取消：如果服务内部逻辑中存在触发saveDataScope.cancel()的操作，或者SupervisorJob的父Job被取消，都会导致整个Scope下的协程被取消。

• 替换为系统Dispatcher：放弃自定义线程池，改用Dispatchers.IO——这是Android优化后的IO调度器，线程管理由系统负责，不会轻易因空闲被回收，稳定性更高。
• 添加异常捕获逻辑：在循环内捕获所有可能的异常，避免协程意外终止：

fun saveData() {
    saveDataScope.launch(Dispatchers.IO) {
        while (true) {
            try {
                saveDataToDB()
                delay(duration)
            } catch (e: CancellationException) {
                // 协程主动取消时，可做资源清理，必须重新抛出以保证取消生效
                throw e
            } catch (e: Exception) {
                // 处理数据库操作等异常，例如短暂延迟后重试
                delay(1000)
            }
        }
    }
}

• 绑定Scope到服务生命周期：使用AndroidX提供的ServiceScope（需依赖androidx.lifecycle:lifecycle-service），它会自动绑定服务的生命周期，服务销毁时协程会被正确取消，同时避免因Scope意外失效导致的协程终止。
• 确保前台服务合规：
  • 始终保持前台通知可见，避免用户手动关闭通知导致服务降级。
  • 针对Android 12及以上版本，申请并获取POST_NOTIFICATIONS权限，保证通知能正常显示。
• 考虑使用WorkManager：如果只是周期性存储数据的需求，WorkManager是更可靠的选择。它是官方专门用于处理后台周期性任务的组件，能自动适配系统后台限制，即使应用被杀死，也能在系统允许的时间执行任务，无需手动维护协程循环。

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