Activity的onDestroy()方法未被调用时如何更新远程数据库状态

首先明确底层限制：安卓系统没有提供可覆盖所有进程销毁场景的回调机制，当应用被系统强制停止、低内存优先级查杀、用户在设置页强行停止时，所有应用层代码都没有执行机会，不存在100%能触发状态同步的方案，以下方案可覆盖绝大多数常规场景，最大程度提升同步成功率。

方案1：本地标记+延迟补同步（实现成本最低，覆盖95%以上场景） #

• 在onPause()生命周期中先向本地持久化存储（SharedPreferences/Room）写入待同步标记，记录当前Activity需要更新为销毁状态
• 若Activity正常触发onDestroy()，直接调用远程接口更新状态，更新成功后删除本地的待同步标记
• 每次应用冷启动时，优先检查本地是否存在未同步的标记，如果有就先执行远程状态更新，成功后清除标记

该方案不受进程意外杀死的影响，哪怕中途进程终止，下次应用启动时会自动补同步，是优先推荐的通用方案。

方案2：前台服务托管（适配需要实时同步的场景） #

• 将状态同步逻辑放到前台服务中执行，安卓8.0及以上版本需要绑定常驻通知栏才能启动前台服务
• 重写前台服务的onTaskRemoved()方法，用户从最近任务列表划掉应用时会触发该回调，可在回调中执行远程状态更新
• 前台服务的进程优先级远高于普通Activity和后台服务，被系统低内存查杀的概率大幅降低

注意：用户主动在设置中强行停止应用时，onTaskRemoved()不会触发，仍需配合方案1的补同步逻辑兜底。

方案3：服务端心跳兜底（对状态准确性要求极高的场景适用） #

• 服务端新增心跳检测逻辑，客户端在Activity存活期间每间隔固定时长（建议15~30s）向服务端上报一次存活状态
• 服务端如果连续2~3个周期没有收到对应客户端的心跳包，自动将关联的Activity状态更新为销毁状态
• 该方案完全不依赖客户端生命周期回调，可靠性最高，无需处理客户端进程被杀死的异常场景。

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