Service自动被销毁？

1 简介

Service的几种应用场景中，你是否考虑过Service是否真正被销毁了？本篇将针对各种场景下，Service如何被自动销毁以及重建做个简单的介绍。

2 使用场景

2.1 同一应用内使用Service

• 使用startService启动服务

1.直接关闭应用，用户通过back键返回关闭应用时，应用可能并没有真正意义的退出，当点击任务栏快捷键查看时该应用可能还存在，这种情况下应用并没有完全退出，所以Service没有被销毁。

2.直接关闭应用，应用确实被杀死了。通过任务栏，查看应用列表，已无该应用。这种情况下需要参考onStartCommand的返回参数，来判断Servcie的状态。

onStartComand使用时，返回的是一个(int)整形。

这个整形可以有四个返回值：START_STICKY、START_NO_STUCKY、START_REDELIVER_INTENT、START_STICKY_COMPATIBILITY。

它们的含义分别是：

1):START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。

2):START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务

3):START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。

4):START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。

• 使用bindService绑定服务
  应用退出以后，service会自动被销毁。
• 使用startServcie启动服务，然后使用bindService绑定服务
  应用退出后，如果onStartCommand返回的是粘性服务，Service会被重建，且onStartCommand会被执行，即Service会正常运行；如果返回非粘性服务，Servcie会被重建，但是onStartCommand并不会被执行，即Service被重建，但是并没有在运行状态。
• 使用bindService绑定服务，然后使用startService启动服务
  该种场景与第三种场景一样。

2.2 不同应用之间使用Service

• 使用startService启动服务
  关闭服务所在应用的情况可以参考同一应用中的情况；关闭启动服务的进程，对service无影响，故不会销毁服务。
• 使用bindService绑定服务
  需要多个客户端都与service断开连接才会销毁服务。
• 使用startServcie启动服务，然后使用bindService绑定服务
  1)关闭服务所在应用的情况:
  如果onStartComand，返回的是粘性服务，客户端退出以后，服务会被重建且onBind，conStartCommand会被重新执行；如果返回的是非粘性服务，服务会被重建，onBind方法会重新执行。
  2)关闭启动服务者的进程：
  如果使用startService启动的，服务不会被销毁；
  如果使用bindService绑定服务的，多个客户端如果全部退出，服务会被解绑；否则，对服务没有影响。
• 使用bindService绑定服务，然后使用startService启动服务
  可以参考第三种场景。