JobScheduler：应用被杀死后周期性任务的行为如何？

嘿，针对你的问题，我来梳理下JobScheduler的行为以及是否适合你的需求：

JobScheduler在应用被杀死后的表现 #

• 当用户主动终止应用（比如从最近任务栏划掉、在设置里强制停止）：绝大多数情况下，你通过JobScheduler调度的任务会被系统直接取消，不会再触发。不过要提一句，部分国内厂商的定制ROM有特殊的后台管控逻辑，少数场景下可能有例外，但主流Android系统的行为都是任务随应用进程终止而失效。
• 当应用被系统因内存不足杀死：如果你的Job任务配置了重试规则（比如setBackoffCriteria()），当系统资源恢复后，JobScheduler可能会重新调度这些任务——因为系统会持久化存储未完成的Job，等满足执行条件时尝试重启。

你的需求是否适合用JobScheduler？ #

你的目标是让任务仅在应用前台/后台存活时运行，应用被杀后立刻停止，JobScheduler其实并不完全匹配这个场景：

• 如上面所说，系统回收进程后，JobScheduler可能会在后续自动重启任务，这和你「应用被杀就停止」的要求冲突。
• 再对比你提到的AlarmManager：AlarmManager的高优先级闹钟（比如setExactAndAllowWhileIdle）会完全无视应用进程状态，到点就唤醒应用执行任务，哪怕应用已经被杀死，这显然更不符合你的需求。

更适合的实现方案 #

如果要严格满足你的需求，推荐这两种方式：

• 进程内调度+前台服务：用Handler配合postDelayed()实现周期性任务，这种任务完全依附于应用进程，进程一死任务就停。如果需要后台稳定运行不被系统限制，可以把任务放在前台服务里执行——前台服务优先级高，不容易被系统回收，而且应用进程终止时，前台服务也会跟着停止，任务自然终止。
• 生命周期监听+JobScheduler：如果你一定要用JobScheduler，可以通过ProcessLifecycleOwner监听应用的整体生命周期，当检测到应用即将进入销毁状态（比如所有Activity都已销毁且无后台服务运行）时，主动调用JobScheduler.cancelAll()取消所有任务。不过这种方式有局限性，因为系统不一定会触发应用的销毁回调，无法保证100%取消任务。

总的来说，如果你的核心要求是「应用被杀后任务必须停止」，优先选第一种方案；如果能接受系统回收进程后偶尔重启任务的情况，JobScheduler也可以用，但要额外做生命周期的监听处理。

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