Page Lifecycle API 的 state 属性无法在系统杀后台时固化业务状态，因其依赖浏览器环境，而Android/iOS系统级杀进程会直接终止WebView与JS执行环境；应通过原生回调（如onTrimMemory）、前台服务、WorkManager及JSBridge同步等方案实现状态落盘。
Page Lifecycle API 的 state 属性本身**不能用于在系统杀掉后台进程前固化业务状态**，因为它仅适用于浏览器环境（WebView 或 PWA），而移动端系统级“杀后台”行为发生在原生 Android/iOS 进程层面，此时 WebView 已被强制终止，JavaScript 执行环境彻底消失，API 无从响应。
为什么 state 属性在杀后台场景中失效
Page Lifecycle API（如 document.onvisibilitychange、document.onfreeze、document.onresume）依赖浏览器内核调度，其生命周期事件触发前提是：Web 页面仍驻留在内存中且 JS 线程未被回收。但 Android 6.0+ 系统（尤其华为、小米、OPPO 等厂商 ROM）在锁屏/低内存时会直接销毁整个 App 进程，包括 WebView 实例与所有 JS 上下文——此时页面早已不复存在，state 值无法读取，事件也无法触发。
真正有效的状态固化路径
要应对系统级进程被杀，必须绕过 Web 层，借助原生能力在进程终止前完成关键数据落盘：
-
监听系统级生命周期回调：在 Android 中，通过
Application.onTrimMemory(level)捕获TRIM_MEMORY_UI_HIDDEN（界面不可见）或TRIM_MEMORY_RUNNING_MODERATE（内存压力初现），此时进程尚存，可立即序列化状态到 SharedPreferences 或 Room 数据库； - 绑定前台服务保活窗口：在用户离开前启动前台服务（需声明 Notification），延长系统清理延迟窗口（通常多出 1–3 分钟），争取时间完成异步写入；
- 利用 WorkManager 做兜底同步：将待固化状态标记为“待提交”，即使进程被杀，WorkManager 可在下次系统空闲时拉起独立进程执行持久化任务；
-
避免依赖 onPageHide / onFreeze：这些事件在多数国产定制系统中被严重阉割或延迟触发，实测华为 EMUI、小米 MIUI 下
freeze事件几乎不触发，不可作为主逻辑依赖。
WebView 场景下的务实建议
若应用基于 WebView（如混合开发），应主动放弃用 Page Lifecycle API 做保活判断，转而：
- 在 JS 层每次关键操作（如表单输入、播放进度、地图位置）后，通过
JSBridge同步调用原生接口写入本地存储； - 在 Activity 的
onPause()中强制触发一次全量状态快照（比依赖页面事件更可靠）； - 对重要业务状态（如订单填写、音视频播放点）启用自动保存机制，不等待“即将被杀”的信号，而是持续轻量更新。
本质上，对抗系统杀进程不是前端能单独解决的问题，必须由原生层主导状态管理。Page Lifecycle API 适合优化 Web 页面自身的资源释放，而非抵御系统级进程回收。
