在 Android 开发中Service 的 onStartCommand() 方法返回START_REDELIVER_INTENT或START_STICKY，哪一个更适用？

在 Android 开发中，Service 的 onStartCommand() 方法返回不同的值会影响服务在被系统终止后的行为。具体的返回值有多种选择，其中包括 START_REDELIVER_INTENT 和 START_STICKY。让我们来详细比较这两者的区别，并看看哪一个更适合你的场景。

1. START_STICKY

• 行为：如果服务被系统终止，系统会在资源允许的情况下自动重新创建服务，但不会重新传递原来的 Intent。这意味着服务会被重新启动，但你不会得到之前传递给 onStartCommand() 的 Intent。
• 场景：适合那些不依赖传递的 Intent 参数的服务，比如后台任务、定时服务等。服务被重新创建后，可以自行恢复某些状态，而不需要依赖之前的启动参数。

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    // 服务被终止后，系统会重新启动服务
    return START_STICKY;
}

• 适用场景：START_STICKY 适用于那些 即使没有原始 Intent，也需要长期运行的服务，如音乐播放、后台监控、定时任务等。服务被杀死后，可以自行恢复某些状态，继续运行。

2. START_REDELIVER_INTENT

• 行为：如果服务被系统终止，系统不仅会重新创建服务，还会重新传递最后一个 Intent 给 onStartCommand()。这意味着你可以继续处理之前没有完成的工作，服务重新启动时会获得与之前相同的启动参数。
• 场景：适合那些依赖启动参数的服务，例如下载任务或处理请求的服务。系统会自动重新传递之前的 Intent，这样你可以继续处理之前未完成的任务。

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    // 服务被终止后，系统会重新启动服务，并重新传递最后一个Intent
    return START_REDELIVER_INTENT;
}

• 适用场景：START_REDELIVER_INTENT 适用于那些 需要完成特定任务且依赖 Intent 参数的服务，如文件上传、下载任务等。如果服务意外终止，你需要重新获取之前传递的 Intent 来继续未完成的任务。

选择哪一个更适用？

• 选择 START_STICKY 的场景：

  • 如果你的服务在后台监控某些状态，并且服务本身不需要依赖传递的 Intent 数据来恢复之前的状态，比如播放音乐、后台监控服务等场景，使用 START_STICKY 会更合适。
  • 适合那些任务是持续性的，不需要处理某个特定的 Intent 参数。

• 选择 START_REDELIVER_INTENT 的场景：

  • 如果你的服务需要完成某个特定的任务，并且这个任务依赖于传递的 Intent 参数（如文件下载或上传），使用 START_REDELIVER_INTENT 更合适。这样在服务被终止并重新启动时，你仍然可以继续处理之前的 Intent。
  • 适合需要重新获取原始 Intent 参数来恢复工作的服务，比如正在下载文件的服务，下载任务意外中断后，需要重新恢复下载进度。

在你的场景中（后台监控服务）：

如果你的服务主要用于 长期监控后台状态，而不需要依赖于每次 Intent 的数据，可以使用 START_STICKY。这种情况下，服务即使被杀掉，系统也会在条件允许时重新启动服务，确保监控任务的持续运行，而你不需要原始 Intent 来恢复状态。

总结：

• START_STICKY：适合长期运行的服务（如后台监控），即使没有原始的 Intent，服务也应该继续运行。
• START_REDELIVER_INTENT：适合依赖 Intent 的服务，比如下载任务。系统重新启动服务时会重新传递之前的 Intent。