关于START_REDELIVER_INTENT场景下Intent为null的可能性技术问询

嘿，我来帮你把这两个关于Android Service和START_REDELIVER_INTENT的问题讲清楚：

问题1：当使用START_REDELIVER_INTENT时，是否存在Intent为null的情况？ #

答案是肯定会存在，主要有两种场景：

• 服务首次启动时，如果调用startService()传入的Intent本身就是null，那onStartCommand自然会收到null；
• 当服务因系统资源不足被杀死后重启时，如果之前最后一次交付给服务的Intent是null，或者系统在恢复过程中遇到了无法恢复Intent的异常（比如序列化数据损坏），重启后的onStartCommand也会拿到null。

问题2：若最后交付的Intent不为null，重写onStartCommand返回START_REDELIVER_INTENT时，仍会获取到null吗？ #

这种情况非常罕见，但并非完全不可能：

• 正常情况下，只要最后一次交付的Intent是非null的，且Intent中携带的所有数据都能正常序列化/反序列化（比如实现了Parcelable或Serializable接口），系统重启服务后会准确传递这个Intent给onStartCommand；
• 极端例外：如果Intent里包含的对象没有正确实现序列化接口，或者序列化的数据在系统存储过程中损坏，系统无法恢复原本的Intent，这时就会传递null过来。

小建议 #

不管哪种场景，都建议在onStartCommand里先对Intent做非空判断，避免空指针异常，这是Android服务开发的基础好习惯。示例代码如下：

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    if (intent == null) {
        // 处理空Intent的逻辑，比如打日志、停止服务或重新触发启动
        Log.w(TAG, "Received null intent in onStartCommand");
        return START_NOT_STICKY;
    }
    // 处理正常的业务逻辑
    // ...
    return START_REDELIVER_INTENT;
}

内容的提问来源于stack exchange，提问作者R. Hanza