用于播放音乐的 Android 服务 : why START_STICKY?

Question

我正在开发一款播放音乐的 Android 应用。

到目前为止，我已经从负责播放音乐的服务的 onStartCommand 返回了 START_STICKY，因为 Eclipse 中的工具提示指出:“此模式对[...] 执行背景音乐播放的服务”。

此方法做的第一件事是查看它应该做什么(播放、停止、下一首歌曲...)的 Intent 。

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

因此，我的第一 react 是在 onStartCommand 方法的开头插入:

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

但在再次阅读了START_STICKY 和START_NOT_STICKY 的描述后，我想知道:为什么将START_STICKY 推荐用于音乐播放器？

我的理解是，两者之间的区别在于，如果以 START_STICKY 启动的服务被终止，它将重新启动(然后使用 intent=null)。使用 START_NOT_STICKY 时，服务将不会重新启动(除非用户请求)，因此它将始终以 Intent 调用，我不需要检查它是否为 null。

当用户终止应用程序时，对我来说显然不应该重新启动该服务。

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

以下两个答案暗示返回码没有其他含义，只是如果进程被杀死，是否应该重新启动服务:

• What is START_STICKY,START_NOT_STICKY and START_REDELIVER_INTENTService
• START_STICKY and START_NOT_STICKY

为什么 START_STICKY 被推荐用于音乐播放器？

Answer 1

START_STICKY - 如果服务因内存不足而停止，则在从内存不足中恢复后，当有足够的内存可用时会重新创建服务。在这里您将丢失之前可能已经计算出的结果。

START_NOT_STICKY- 如果服务停止，系统不会费心重新启动服务，即使它有足够的内存。

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

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