JobService和Service

一、实现原理对比

◆Service
由APP侧发出请求，ActivityManagerService接收请求后进行调度，通知APP侧进行创建，开始(绑定)，停止(解绑)和销毁Service。

◆JobService
由APP侧发出请求，JobSchedulerService接收请求后，通过ActivityManagerService去调度JobService的创建，绑定和解绑。
并由JobSchedulerService自己进行JobService的开始，取消和停止等操作。

从原理上看，JobService的开始，取消和停止是由JobSchedulerService维护的，而不是由ActivityManagerService维护的。
这是他们在实现原理上的明显区别。

二、启动条件对比

◆Service
Service的启动并没有什么特定的条件设置。
如果说非要有什么具体的执行条件的话，就是APP侧自己根据业务逻辑在适当的时候调用startService()或者bindService()。

◆JobService
JobService的执行需要至少一个条件。没有条件的JobService是无法启动的，在创建JobInfo的时候会抛出异常。

三、启动时机对比

◆Service
APP侧一旦通知Context去执行startService()，APP侧的Service将得到运行。
(使用bindService()的话，Service的运行取决于ServiceConnection的onServiceConnected()的回调)

◆JobService
JobService的执行必须等待执行条件满足了才能被创建和开始。

三、执行时间对比

◆Service
onStartCommand()的回调在UI线程，不可执行耗时逻辑，否则可能造成ANR。

◆JobService
onStartJob()的回调在UI线程，不可执行耗时逻辑，否则可能造成ANR或者Job被强制销毁(超过8s)。
并且，JobService里即便新起了线程，处理的时间也不能超过10min，否则Job将被强制销毁。

四、启动角度对比

◆Service
onStartCommand()里返回START_STICKY可以告诉AMS在被停止后自动启动。

◆JobService
onStopJob()里返回true，即可在被强制停止后再度启动起来。

五、扩展性对比

◆Service
APP侧可以通过Binder创建远程Service进行IPC。

◆JobService
JobService的绑定实际上是由JobSchedulerService自己去做的。
绑定后产生的Binder用于和JobSchedulerService进行IPC，APP侧无法通过JobService扩展去实现别的IPC功能。
※Google本来的初衷也不是让JobService实现远程Service的功能。

六、实际应用上的对比

◆Service
适合需要常驻后台，立即执行，进行数据获取，功能维持的场景。
比如 音乐播放，定位，邮件收发等。

◆JobService
适合不需要常驻后台，不需要立即执行，在某种条件下触发，执行简单任务的场景。
比如 联系人信息变化后的快捷方式的更新，定期的更新电话程序的联系人信息

七、总结

简单来说:
Service适合一些优先级较高，执行任务复杂耗时的任务。
JobService适合轻量级的灵活的任务。