用于播放音乐的Android服务：为什么启动\u STICKY？

Question

我正在开发一个Android应用程序来播放音乐。

到目前为止，我已经从负责播放音乐的服务的onStartCommand返回了START\u STICKY，因为在Eclipse状态下使用工具提示：“此模式对[…]有意义播放背景音乐的服务”。

该方法所做的第一件事是查看意图，它应该做什么（播放、停止、下一首歌……）。

最近，当我在播放音乐时关闭应用程序（通过在最近的应用程序概述中将其从屏幕上拖出）时，应用程序崩溃。查看日志文件，我发现在尝试访问onStartCommand中的意图时引发了NullPointerException（在调用了应用程序和服务的onCreate方法之后）。

因此，我的第一个反射是在onStartCommand方法的开头插入：

if (intent == null){
    stopSelf();
    return START_NOT_STICKY;
}

但是在阅读了《开始粘性》（START\u STICKY）和《开始不粘性》（START\u NOT\u STICKY）的描述之后，我又想知道：为什么会推荐音乐播放器使用《开始粘性》（START\u STICKY）？

我的理解是，二者之间的区别在于，如果使用START\u STICKY启动的服务被终止，它将重新启动（然后使用intent=null）。使用START\u NOT\u STICKY服务将不会重新启动（除非用户请求），因此它将始终被有意调用，我不需要检查它是否为null。

当用户终止应用程序时，我很明显不应该重新启动该服务。

我能想到的另一种可能重新启动服务的情况是，如果服务由于缺乏资源而被系统杀死。在这种情况下，我也不认为用户会希望音乐意外地开始播放音乐，只是因为一些资源变得可用。

以下两个答案意味着返回代码除了在进程被终止时是否应重新启动服务之外没有其他意义：

• 什么是START\u STICKY、START\u NOT\u STICKY和START\u REDELIVER\u INTENT Service
• START\u STICKY和START\u NOT\u STICKY

为什么建议音乐播放器使用“START\u STICKY”（启动粘性）？

Answer 1

intSTART_STICKY：从onStartCommand（Intent， int， int）返回的常量：如果这个服务的进程在启动时被杀死（从onStartCommand（Intent， int， int）返回后），那么让它处于启动状态，但不要保留这个传递的意图。稍后系统会尝试重新创建服务。因为它处于启动状态，所以它会保证在创建新的服务实例后调用onStartCommand（Intent， int， int）；如果没有任何挂起的启动命令要传递给服务，它将被调用一个空意图对象，所以你必须小心检查这一点。此模式适用于将显式启动和停止以运行任意时间段的事物，例如执行背景音乐播放的服务。

因此，这是自我解释，请参考此粘性服务

Answer 2

START\u STICKY如果服务因内存不足而停止，则在有足够内存可用时，在服务从内存不足恢复后，会重新创建服务。在这里，您将丢失以前可能计算过的结果。

START\u NOT\u STICKY-如果服务停止，则系统不必重新启动服务，即使它有足够的内存。

此外，当用户杀死应用程序时，服务不会停止，除非您使用一些任务杀手停止进程。有关服务的更多信息，请查看此链接。

http://www.vogella.com/tutorials/AndroidServices/article.html