应用被杀死或从最近列表划除后，其Service是否会被销毁？

嘿，这几个关于Android Service的问题确实是日常开发里常碰到的，我给你拆解清楚：

1. 杀死应用时，其Service是否也会被销毁？ #

一般情况下，是的。如果你的Service和应用主进程绑定在一起（默认就是这种情况），当应用进程被用户手动杀死或者系统因资源不足回收时，属于该进程的Service也会跟着被销毁。

不过有个例外：要是你给Service通过android:process属性指定了独立进程，那只要这个独立进程没被杀死，Service就能继续存活，不受主进程的影响。

2. 从最近应用列表划除时，Service会停止吗？ #

这个得分情况看：

• 前台Service：如果你调用了startForeground()让Service以前台状态运行（会在通知栏显示一个持续的通知），那就算把应用从最近列表划掉，Service通常也会继续存活——系统对前台Service的优先级很高，不会轻易回收。
• 后台Service：在Android 8.0（API 26）及以上版本，系统对后台Service的限制非常严格，划除最近列表后，系统大概率会很快停止这个Service；而在更低版本的系统中，后台Service可能会存活一段时间，但一旦系统内存吃紧，还是会被优先回收。
  另外，如果Service是通过bindService()和Activity绑定的，当所有绑定的组件都被销毁且没有其他绑定者时，Service也会被销毁，但划除最近列表不一定直接触发绑定解除，具体还要看你绑定Service时用的模式（比如BIND_AUTO_CREATE这类）。

关于START_STICKY模式 #

当你在Service的onStartCommand()方法中返回START_STICKY时，会触发一个很实用的系统行为：

若系统在onStartCommand()执行完成后杀死了Service，只要系统资源允许，就会自动重建这个Service，并再次调用onStartCommand()。

不过有几个细节要注意：

• 重建Service时，不会重新传递最后一个启动它的Intent，除非存在待处理的Pending Intent——这种情况下系统会把这些Pending Intent传递过来，否则onStartCommand()会收到null的Intent。
• 这种模式特别适合媒体播放器（或者类似的长期运行服务）：比如用户切后台听音乐，系统因内存紧张杀了Service，之后系统会自动重建它，继续播放音乐，不用用户手动重启应用。

内容的提问来源于stack exchange，提问作者Amadeu Cavalcante Filho