什么是START_STICKY，START_NOT_STICKY和START_REDELIVER_INTENT服务
我无法理解
- START_STICKY，
- START_NOT_STICKY和
- START_REDELIVER_INTENT
可以用任何一个例子来清楚地解释。
我通过这个链接，但无法清楚地理解。
提前致谢。
这些与服务有关。 我们都知道服务在后台继续运行，并且还消耗一些内存来执行。
因此，随着更多的应用程序运行在Android设备上，设备内存不断下降，当时间到了，当设备内存严重不足时，Android系统启动终止进程，以释放进程占用的内存。
但是你可能正在做一些与服务有关的重要任务，也可能在服务停止时被终止。 所以这些概念是告诉android系统当设备内存变得稳定以及准备重新启动服务时要执行的操作。
这些最简单的解释可能是，
START_STICKY-指示系统在有足够的内存可用时从低内存恢复后创build新的服务副本。 在这里你将失去以前可能计算的结果。
START_NOT_STICKY-告诉系统即使有足够的内存，也不要去重新启动服务。
START_REDELIVER_INTENT-告诉系统在崩溃之后重新启动服务，并重新传送在崩溃时出现的意图。
那么，我读了你的链接中的线程，它说明了一切。
如果您的服务由于内存不足而被Android杀死，并且Android清除了一些内存，那么…
- STICKY：… Android将重新启动您的服务，因为该特定的标志设置。
- NOT_STICKY：… Android不会在意再次启动，因为该标志告诉Android它不应该打扰。
- REDELIVER_INTENT：… Android将重新启动服务，并重新传递同样的意图到服务的
onStartCommand()，因为再次的标志。
这两个代码只有在手机内存不足并在完成执行之前终止服务时才适用。 START_STICKY告诉操作系统在有足够的内存后重新创build服务，并以空目的再次调用onStartCommand（）。 START_NOT_STICKY告诉操作系统不要再次重新创build服务。 还有第三个代码START_REDELIVER_INTENT告诉操作系统重新创build服务，并将同样的意图重新传递给onStartCommand（）。
这篇由Dianne Hackborn撰写的文章解释了这个比官方文档更好的背景。
资料来源： http : //android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html
这里的关键部分是由函数返回的一个新的结果代码，告诉系统如果它的进程在运行时被终止，它应该如何处理这个服务：
START_STICKY与之前的行为基本相同，在这种行为中，服务保持“启动”状态，稍后将由系统重新启动。 与以前版本的平台唯一的区别是，如果它因为进程被终止而重新启动，那么onStartCommand（）将会在下一个具有null Intent的服务实例上被调用，而不是被调用。 使用这种模式的服务应该总是检查这种情况并适当地处理它。
START_NOT_STICKY表示，从onStartCreated（）返回后，如果进程被终止而没有剩余的启动命令要交付，那么服务将被停止而不是重新启动。 这对于只在执行发送给它们的命令时才运行的服务更有意义。 例如，可以每15分钟从一个警报开始一个服务来轮询一些networking状态。 如果在做这件事的时候死了，最好是让它停下来，并在下一次闹铃起火时开始。
START_REDELIVER_INTENT与START_NOT_STICKY类似，除非服务进程在针对给定意图调用stopSelf（）之前被终止，意图将被重新传递给它，直到它完成（除非经过多次尝试仍然无法完成，系统放弃）。 这对于接收工作命令的服务是有用的，并且要确保它们最终完成每个发送的命令的工作。
