Android中JobService的onCreate为何每次执行onStartJob前都会启动？

嘿，这个问题我之前做JobScheduler相关开发时也踩过一模一样的坑！咱们得先把JobService和普通Service的本质区别掰扯清楚，就能明白为啥日志和你想的完全不同了。

1. JobService根本不是“长期驻留”的Service！ #

你之前的认知是把普通Service的逻辑套到JobService上了——普通Service调用startService()后会常驻系统，除非你主动stopService()或者系统极度缺资源才会杀它。但JobService是系统调度的「短期任务容器」：

• 系统只会在需要执行你调度的Job任务时，才临时拉起JobService的实例；
• 任务执行完毕（或者系统觉得该回收资源了），会立刻销毁这个实例，不会留着它驻留后台。

所以每次Job触发时，系统都会新建一个JobService对象，自然每次都会先调用onCreate()，再执行onStartJob()，任务结束后直接销毁实例——这就是你看到日志里每次Starting前都有OnCreate的原因。

2. onStopJob不是“一定会被调用”的方法！ #

onStopJob()的触发场景非常有限，只有两种情况才会走这个方法：

• 你在onStartJob()里调用了jobFinished(params, true)（表示任务需要重试），但系统在重试之前取消了这个任务；
• 系统在你的Job执行过程中，因为资源紧张或者其他系统规则，强制中断了正在运行的Job。

而你遇到的“快速销毁时没调用onStopJob”，大概率是这两种情况：

• 你的Job任务执行得太快，系统认为任务已经完成，直接销毁JobService实例，不会触发onStopJob()；
• 系统销毁JobService时是直接杀掉进程级别的回收，不会走组件的生命周期回调，自然也不会调用onStopJob()。

给你几个实用的小建议 #

如果你的需求是长期驻留后台，那JobService完全不适合，应该用普通Service配合前台通知（Android 8.0之后必须走前台，否则会被系统限制）；
如果是周期性任务，记住JobScheduler的“周期”是两次任务触发的间隔，每次触发都是全新的JobService实例，不要指望复用同一个对象；
如果需要在任务结束时做清理逻辑，尽量把清理代码放在onStartJob()的末尾，调用jobFinished()之前完成，不要依赖onStopJob()来做收尾——它真的不是每次都会被调用的。

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