最近项目开发中遇到一个怪象：在设置中将app已获取的location权限关闭后，app进程被杀死，通过守护进程重新启动app主进程并同时启动后台服务Service，此时app进程很快就启动，但是Service只是执行了onCreat没有进一步执行onStartCommand。且在启动Service时偶现ANR。针对该象限做一下研究分析：
关闭location权限关闭后，app进程被杀
- Android已授权的app，手动在设置中取消某个授权，该app主进程会被杀死，这是Android系统机制。
Service启动只执行onCreat没有执行onStartCommand
- 出现该现象原因是：在守护保活进程中启动Service时，由于出现ANR而将启动执行放到Thread中执行导致的。将执行逻辑从Thread中移出来即可解决该现象。【但是经验证单纯将Service启动放到Thread中执行是正常的】虽然问题已解决但是这里还没有定位到到底是什么导致该现象，有大侠知道烦请留言告知，谢谢
Service与Thread的区别
对Service了解后，会发现它实现的大部分功能使用Thread也可以解决，并且Thread使用起来比Service方便的多，那么为什么还需要使用Service呢，下面来详细解释一下。
首先，Thread是程序执行的最小单元，它是分配系统资源的基本单位，主要用于执行一些异步的操作。而Service是Android的一种机制，当它使用bindService()被绑定的时候，是运行在宿主主进程的主线程上的，当使用startService()启动服务的时候，是独立运行在独立进程的主线程上的，因此它们的核心没有任何关系。
其次，对于Thread而言，它是独立于启动它的组件的，如使用一个Activity启动了一个Thread，当这个Activity被销毁前，没有主动停止Thread或者Thread的run()方法没有执行完毕的话，Thread也会一直执行下去，这样就很容易导致一些问题，当这个Activity被销毁之后，将不再持有这个Thread的引用，也就是说，无法再在另外一个Activity中对同一个Thread进行控制。而Service不同，在Android系统中，无论启动或绑定几次，只会创建一个对应的Service实例，所以只要这个Service在运行，就可以在能获取到Context对象的地方控制它，这些特点是Thread无法做到的。
JobService与Service
| 对比角度 | Service | JobService | 补充 |
|---|---|---|---|
| 实现原理 | 由APP侧发出请求，ActivityManagerService接收请求后进行调度，通知APP侧进行创建，开始(绑定)，停止(解绑)和销毁Service。 | 由APP侧发出请求，JobSchedulerService接收请求后，通过ActivityManagerService去调度JobService的创建，绑定和解绑。并由JobSchedulerService自己进行JobService的开始，取消和停止等操作。 从原理上看，JobService的开始，取消和停止是由JobSchedulerService维护的，而不是由ActivityManagerService维护的。这是他们在实现原理上的明显区别。即JobService是由系统负责调用和维护 | |
| 启动条件 | Service的启动并没有什么特定的条件设置。如果说非要有什么具体的执行条件的话，就是APP侧自己根据业务逻辑在适当的时候调用startService()或者bindService()。 | JobService的执行需要至少一个条件。没有条件的JobService是无法启动的，在创建JobInfo的时候会抛出异常。 | |
| 运行时间 | onStartCommand()的回调在UI线程，不可执行耗时逻辑，否则可能造成ANR。 | onStartJob()的回调在UI线程，不可执行耗时逻辑，否则可能造成ANR或者Job被强制销毁(超过8s)。并且，JobService里即便新起了线程，处理的时间也不能超过10min，否则Job将被强制销毁。 | |
| 启动角度 | onStartCommand()里返回START_STICKY可以告诉AMS在被停止后自动启动。 | onStopJob()里返回true，即可在被强制停止后再度启动起来。 | |
| 扩展性 | APP侧可以通过Binder创建远程Service进行IPC。 | JobService的绑定实际上是由JobSchedulerService自己去做的。绑定后产生的Binder用于和JobSchedulerService进行IPC，APP侧无法通过JobService扩展去实现别的IPC功能。 | Google本来的初衷也不是让JobService实现远程Service的功能。 |
| 实际应用上 | 适合需要常驻后台，立即执行，进行数据获取，功能维持的场景。比如 音乐播放，定位，邮件收发等。 | 适合不需要常驻后台，不需要立即执行，在某种条件下触发，执行简单任务的场景。比如 联系人信息变化后的快捷方式的更新，定期的更新电话程序的联系人信息，壁纸更改后去从壁纸提取颜色的后台任务。 |
简单来讲，Service适合一些优先级较高，执行任务复杂耗时的任务。JobService适合轻量级的灵活的任务。
参考内容：
https://www.catbro.cn/detail/5c394d0584063683a872a591.html
