我无法理解
任何人都可以用例子清楚解释。
我浏览了this链接，但无法理解。
答案 0 :(得分：102)
这些与服务有关。我们都知道服务在后台继续运行，它们也会消耗一些内存来执行。
因此，随着更多应用程序在Android设备上运行，设备内存不断变低，当时间到来时，当设备内存严重不足时，android系统开始终止进程，从而释放占用的内存通过这些过程。
但是您可能正在使用服务执行一些重要任务，这些服务也可能在服务停止时终止。 所以这些概念告诉Android系统当设备内存稳定并准备好重新启动服务时你想要执行什么操作。
对这些的最简单的解释可能是，
START_STICKY-告诉系统在有足够的内存可用时，从低内存中恢复后，创建该服务的新副本。在这里，您将丢失之前可能计算过的结果。
START_NOT_STICKY-告诉系统即使有足够的内存也不要费心重启服务。
START_REDELIVER_INTENT-告诉系统在崩溃后重新启动服务，并重新发送崩溃时存在的意图。
答案 1 :(得分：4)
好吧，我读了你链接中的帖子，它说明了一切。
如果您的服务由于内存不足而被Android杀死，Android会清除一些内存，那么......
onStartCommand()，因为该标志也是如此。答案 2 :(得分：2)
这两个代码仅在手机内存不足时才会生效，并在完成执行之前终止服务。 START_STICKY告诉操作系统在有足够内存后重新创建服务，并再次使用null意图调用onStartCommand（）。 START_NOT_STICKY告诉操作系统不要再次重新创建服务。还有第三个代码START_REDELIVER_INTENT告诉操作系统重新创建服务并将相同的意图重新传递给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分钟轮询一些网络状态。如果它得到 在做这项工作时被杀，最好是让它成为现实 下次报警发生时停止并开始运行。
START_REDELIVER_INTENT就像START_NOT_STICKY，除非是 服务的进程在调用给定的stopSelf（）之前被终止 意图，该意图将在完成之前重新发送给它 （除非经过多次尝试后仍无法完成，否则 系统放弃了哪一点）。这对于那些服务很有用 接收要做的工作命令，并希望确保他们这样做 最终完成发送的每个命令的工作。