START_STICKY和START_REDELIVER_INTENT之间的区别？

Question

我正在为我的Android应用程序创建服务，通过Intents向服务提供数据。问题是，当系统销毁服务时，提供给它的意图数据无法恢复，导致我的应用程序崩溃。

我听说只要有足够的内存可用于恢复提供给服务的意图数据，START_REDELIVER_INTENT将重启我的服务，而START_STICKY将无法恢复意图数据。

我是对的吗？还是有什么我不知道的？

此外，我的服务在系统销毁之后将永远重启。

Answer 1

START_STICKY - 在保留状态并从低内存中恢复后，它会告诉系统创建服务的最新副本，当可用内存足够时。在这个过程中，我们将丢失之前可能计算过的结果。

START_REDELIVER_INTENT - 它会告诉系统重新启动并在崩溃后重新获得服务，并重新发送崩溃时出现的意图。

除此之外，我们还可以提供一些关于START_NOT_STICKY

的说明

START_NOT_STICKY - 即使有足够的可用内存，它也会告诉系统不要担心并重新启动服务。

请访问以获取更多信息

http://developer.android.com/reference/android/app/Service.html

Answer 2

如果要覆盖onstartCommand（）方法，则有责任在不需要时通过调用stopSelf（）或stopService（）命令来停止它。

Answer 3

START_NOT_STICKY：

如果onStartCommand（）返回后系统终止了该服务，则除非有待交付的意向，否则不要重新创建该服务。这是最安全的选择，可以避免在不必要时以及应用程序可以简单地重新启动任何未完成的作业时运行服务。

START_STICKY：

如果onStartCommand（）返回后系统终止了该服务，请重新创建该服务并调用onStartCommand（），但不要重新传递最后一个意图。取而代之的是，系统将以空意图调用onStartCommand（），除非有未决的意图来启动服务。在这种情况下，这些意图就可以实现。这适用于没有执行命令但正在无限期运行并等待任务的媒体播放器（或类似服务）。

START_REDELIVER_INTENT：

如果onStartCommand（）返回后系统终止了该服务，请重新创建该服务，并使用传递给该服务的最后一个意图调用onStartCommand（）。任何待处理的意图都会依次传递。这适用于正在积极执行应立即恢复工作的服务，例如下载文件。