什么是START_STICKY,START_NOT_STICKY和START_REDELIVER_INTENT服务

Question

我无法理解

1. START_STICKY,
2. START_NOT_STICKY和
3. START_REDELIVER_INTENT

任何人都可以用例子清楚解释.

我经历了这个链接,但无法清楚地理解它.

Answer 1

这些与服务有关.我们都知道服务在后台继续运行,它们也会占用一些内存来执行.

因此,随着更多的应用程序在Android设备上运行,设备内存不断变低,当时间到来时,当设备内存严重不足时,android系统开始终止进程​​,从而释放进程占用的内存.

但是您可能正在使用服务执行一些重要任务,这些服务也可能在服务停止时终止.所以这些概念是告诉Android系统当设备内存稳定并准备好重新启动服务时你想要执行什么操作.

这些最简单的解释可能是,

START_STICKY-告诉系统在有足够的内存可用时,从低内存中恢复后,创建一个新的服务副本.在这里,您将丢失之前可能计算过的结果.

START_NOT_STICKY- 告诉系统即使有足够的内存也不要费心重启服务.

START_REDELIVER_INTENT- 告诉系统在崩溃后重新启动服务,并重新发送崩溃时存在的意图.

Answer 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() 之前被终止，该意图将被重新传递给它直到完成（除非在多次尝试后它仍然无法完成，此时系统放弃）。这对于接收要执行的工作命令并希望确保它们最终完成发送的每个命令的工作的服务非常有用。

Answer 3

好吧，我阅读了您链接中的线程，并说明了一切。

如果您的服务由于内存不足而被Android杀死，而Android清除了部分内存，则...

1. STICKY：... Android将重新启动您的服务，因为已设置了该特定标志。
2. NOT_STICKY：... Android不会在意再次启动，因为该标志告诉Android不应打扰。
3. REDELIVER_INTENT：... Android将重新启动该服务onStartCommand()，并再次向该服务传递相同的意图，因为同样是该标志。