START_STICKY和START_NOT_STICKY

Question

在安卓上实现服务时，START_STICKY和START_NOT_STICKY有什么区别？谁能指出一些标准的例子..？

Answer 1

这两个代码仅在手机内存耗尽并在完成执行之前终止服务时才相关。START_STICKY告诉操作系统在它有足够的内存后重新创建服务，并使用空意图再次调用onStartCommand()。START_NOT_STICKY告诉操作系统不要再费心重新创建服务了。还有第三个代码START_REDELIVER_INTENT，它告诉OS重新创建服务，并将相同的意图重新传递给onStartCommand()。

Dianne Hackborn的这篇文章比官方文档更好地解释了这一背景。

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

这里的关键部分是函数返回的新结果代码，它告诉系统，如果服务的进程在运行时被终止，它应该如何处理服务：

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

START_NOT_STICKY说，从onStartCreated()返回后，如果进程被终止，没有剩余的启动命令可供交付，那么服务将停止，而不是重新启动。对于那些只打算在执行发送给它们的命令时运行的服务来说，这更有意义。例如，服务可以从警报开始每15分钟启动一次，以轮询某些网络状态。如果它在执行该工作时被杀死，最好是让它停止，并在下一次警报触发时启动。

START_REDELIVER_INTENT类似于START_NOT_STICKY，除非服务的进程在为给定的意图调用stopSelf()之前被终止，那么该意图将被重新传递给它，直到它完成(除非在多次尝试之后它仍然无法完成，此时系统放弃了)。对于正在接收要做的工作的命令，并希望确保它们最终完成发送的每个命令的工作的服务来说，这很有用。

Answer 2

KISS应答

区别：

START_STICKY

系统将在终止服务后尝试重新创建该服务

START_NOT_STICKY

在您的服务被终止后，系统将不会尝试重新创建该服务

标准示例：

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    return START_STICKY;
}

Answer 3

START_STICKY和START_NOT_STICKY的文档非常简单。

START_STICKY:

如果此服务的进程在启动时被终止(从onStartCommand(Intent, int, int))返回后，则将其保留在已启动状态，但不保留此提交的意图。稍后，系统将尝试重新创建服务。由于处于started状态，创建新的服务实例后会保证调用onStartCommand(Intent, int, int)；如果没有任何挂起的启动命令要下发给服务，则会使用空的intent对象进行调用，因此一定要注意检查。

此模式适用于将显式启动和停止以运行任意时间段的内容，例如执行背景音乐回放的服务。

示例：Local Service Sample

START_NOT_STICKY:

如果此服务的进程在启动时被终止(在从onStartCommand(Intent, int, int))返回后，并且没有新的启动意图要传递给它)，则使服务脱离已启动状态，并在将来显式调用Context.startService(Intent)之前不重新创建。该服务将不会接收带有null意图的onStartCommand(Intent, int, int)调用，因为如果没有要传递的挂起意图，则不会重新启动该服务。

这种模式对于那些由于启动而想要做一些工作的事情是有意义的，但在内存紧张时可以停止，并且稍后将显式地重新启动以做更多的工作。此类服务的一个示例是从服务器轮询数据的服务:它可以通过让警报启动其服务来安排警报每隔N分钟轮询一次。当从警报中调用它的onStartCommand(Intent, int, int)时，它会在N分钟后调度一个新的警报，并产生一个线程来进行联网。如果它的进程在执行该检查时被终止，该服务将不会重新启动，直到警报响起。

示例：ServiceStartArguments.java