Android中START_STICKY与START_REDELIVER_INTENT的实用场景及疑问

这个场景选得太准了！音乐播放器的后台播放绝对是START_REDELIVER_INTENT的典型适用场景，我来把这个逻辑拆解清楚，顺便补上资料里反复提到的那些关键注意点：

• 当你的音乐播放服务因为系统低内存被强制杀死时，系统会在资源充足后自动重启服务，而START_REDELIVER_INTENT会原样重发启动服务时的Intent——这正好戳中了需求：Intent里携带的曲目ID/路径是恢复播放的核心信息，不用额外存到SharedPreferences或者数据库做临时存储，省心又可靠。
• 对比START_STICKY，它重启时只会发一个空Intent，完全满足不了恢复播放的需求，所以这个场景下START_REDELIVER_INTENT是最优解。

• 重发次数有上限：系统不会无限次重发Intent，如果服务重启后又很快崩溃，几次尝试后系统就会放弃重启。所以你得确保服务重启后的初始化逻辑足够健壮，比如先检查曲目ID是否有效、音频文件是否还存在本地。
• Intent数据必须可序列化：Intent里携带的所有数据（比如曲目ID、路径）必须是可序列化的（用Parcelable或者Serializable），不然重启时Intent无法被正确解析，恢复播放直接失败。
• 必须正确返回返回值：一定要在服务的onStartCommand方法里明确返回START_REDELIVER_INTENT，而不是其他返回值，否则系统不会触发Intent重发逻辑。举个简单的代码示例：

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    // 提取并保存曲目信息
    String currentTrackPath = intent.getStringExtra("TRACK_PATH");
    this.currentPlayer = initMediaPlayer(currentTrackPath);
    this.currentPlayer.start();
    // 关键：返回START_REDELIVER_INTENT
    return START_REDELIVER_INTENT;
}

• 重启时清理旧资源：重启服务时记得清理之前的资源，比如旧的MediaPlayer实例、未关闭的音频流，不然很容易引发新的内存泄漏问题，导致服务再次被系统杀死。

内容的提问来源于stack exchange，提问作者mili