JobService完结篇 JobService和Service的多角度对比

JobService的使用，特性和一些流程的源码探究都讲完了。


那我们回过头来思考下这个在Android L时候加入的JobService和元老Service到底有何异同，各有什么优势？


在需要使用Service的时候，对于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适合轻量级的灵活的任务。


大家在实际开发的时候可以根据需要进行选择，只不过要注意两者的特性，恰当地使用。