如何利用 Page Lifecycle API 管理页面冻结状态并实现静默式的业务状态存盘

如何利用 Page Lifecycle API 管理页面冻结状态并实现静默式的业务状态存盘

移动端页面退到后台后被冻结，freeze 事件是唯一能**同步写入、不被中断**的状态存盘时机；依赖 visibilitychange 或 beforeunload 必丢数据，尤其在 iOS Safari 和国产安卓浏览器上几乎无效。

为什么 freeze 是唯一可靠的静默存盘入口

系统冻结页面时，JS 执行会被硬性挂起——定时器停摆、异步任务中断、DOM 不可读。但 freeze 事件是在冻结前**最后一个可同步执行 JS 的钩子**，此时 localStorage.setItem() 还能成功落盘，且不会被中断。

• 常见错误现象：visibilitychange 触发后刚调用 JSON.stringify()，JS 就被挂起，状态根本没存上。
• 不要尝试在 freeze 中做 await fetch() 或 indexedDB.put()：这些异步操作大概率被截断，且无回调机会。
• 必须加 { once: true }：避免重复绑定导致多次触发，尤其和 pagehide 兜底逻辑共存时。
• 注意兼容性：iOS Safari 直到 16.4+ 才稳定支持 freeze，旧版本会静默忽略，所以不能只靠它。

pagehide + persisted 是 freeze 的必要补漏

pagehide 本身不表示冻结，但当 event.persisted === true 时，说明浏览器打算缓存或冻结该页面——这是 Android Chrome 和部分 Safari 版本的“替代路径”，错过就等于放弃这部分用户。

• 必须配合防重机制：用闭包变量（如 frozen = false）标记是否已存盘，防止 freeze 和 pagehide 连续触发两次。
• 别在 pagehide 回调里读取 element.scrollHeight 或 getBoundingClientRect()：此时元素可能已脱离布局流，返回 0。
• 节流很重要：用 performance.now() 记录上次保存时间，200ms 内不再触发第二次写入，避免冗余 I/O。

状态序列化必须轻量、可 JSON 化、无副作用

冻结前存的数据，恢复时要能原样解析并安全使用。任何不可序列化字段（如函数、DOM 节点、undefined）都会让 JSON.stringify() 抛错，直接退出事件处理器，导致存盘失败。

• 只保留原始值：window.scrollY、input.value、select.selectedIndex、new Date().toISOString()。
• 剔除敏感字段：token、临时密钥、未加密的用户身份信息——resume 时应走服务端校验，而非本地还原。
• 优先用 sessionStorage：比 localStorage 更贴合单页会话生命周期，避免跨会话污染。
• 必须包 try/catch：捕获 JSON.stringify() 失败或 setItem() 配额超限，catch 块里不要 throw，否则阻断冻结流程。

resume 事件里只能做轻量校验与补救

resume 不是页面重启，而是“时钟恢复”：所有定时器 ID、未 resolve 的 Promise、事件监听器都还在，只是时间暂停了。把它当初始化入口，必然引发重复请求、双重绑定、UI 状态错乱。

• 先校验再动：检查 document.visibilityState === 'visible' && document.hasFocus()，确认用户真正在前台。
• 只重置失效逻辑：比如重新 setTimeout 轮询、检查 fetch 是否超时、手动设置 window.scrollTo()。
• 别在 resume 中批量读取 localStorage 并立即渲染：可能触发 layout thrashing，尤其 DOM 还没 fully ready 时。
• 恢复后立即 removeItem()：避免下次打开页面（非 resume 场景）又误恢复旧状态。

话说回来，真正难的不是写对这四个事件，而是接受一个事实：你无法阻止系统杀进程。freeze 和 resume 只在浏览器还给你留着内存时才存在；一旦 Android 厂商 ROM 直接销毁 WebView 进程，所有 JS 生命周期事件都归零——这时候得靠原生层保活或 JSBridge 同步，而不是在网页里反复加固 freeze 回调。