START_STICKY和START_NOT_STICKY

START_STICKY和START_NOT_STICKY

这两个代码仅在手机内存不足并在执行结束之前终止服务时才相关。

START_STICKY

告诉 *** 作系统在具有足够的内存后重新创建服务，onStartCommand()然后以空意图再次调用。

TART_NOT_STICKY

告诉 *** 作系统不要再重新创建服务。还有第三条代码

START_REDELIVER_INTENT

告诉 *** 作系统重新创建服务并重新发送相同的意图

onStartCommand()

。

戴安娜·哈克伯恩（Dianne Hackborn）的这篇文章比官方文档更好地解释了其背景。

来源：http : //android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

这里的关键部分是该函数返回的新结果代码，告诉系统如果在运行过​​程中其进程被杀死，该服务应该如何处理：

START_STICKY与以前的行为基本相同，在该行为中，服务保持“启动”状态，稍后将由系统重新启动。与该平台先前版本的唯一区别在于，如果由于其进程被终止而重新启动该平台，则将在服务的下一个实例中使用空Intent调用onStartCommand（）而不是根本不调用它。使用此模式的服务应始终检查这种情况并进行适当处理。

START_NOT_STICKY说，从onStartCreated（）返回后，如果进程被杀死而没有剩余的启动命令要传递，则该服务将停止而不是重新启动。对于仅在执行发送给它们的命令时才运行的服务，这更有意义。例如，可以每15分钟从警报启动一项服务以轮询某些网络状态。如果在执行此 *** 作时将其杀死，最好只是将其停止并在下一次警报响起时启动。

START_REDELIVER_INTENT类似于START_NOT_STICKY，除了服务的进程在为给定意图调用stopSelf（）之前被杀死之前，该意图将重新交付给它，直到完成为止（除非经过多次尝试仍无法完成，此时系统会放弃）。这对于正在接收要执行的工作命令的服务非常有用，并且要确保它们最终能够为发送的每个命令完成工作。