如何运用 Page Lifecycle API 管理移动端网页在后台冻结时的状态保存

监听 freeze 事件是保存状态的第一道防线，移动端浏览器在网页进入后台且内存紧张时触发该事件，此时 JS 执行暂停但 DOM 和内存保留，需立即同步保存关键状态并标记 frozen = true。

监听 freeze 事件是保存状态的第一道防线

移动端浏览器（如 Chrome Android、Safari iOS）在网页进入后台且内存紧张时，会触发 freeze 事件——这不是“页面卸载”，而是“暂停执行”，JS 定时器、fetch、requestAnimationFrame 全部停摆，但 DOM 和 JS 内存仍保留。此时必须立刻保存关键状态，否则用户切回时看到的是过期或错乱的 UI。

实操建议：

• 在 freeze 回调中调用你的状态序列化函数，例如 saveState()，并设置一个标记 frozen = true 防止重复保存
• 不要依赖 beforeunload 或 pagehide 单独处理：它们可能不触发（比如系统直接冻结），或触发太晚（JS 已被挂起）
• 避免在 freeze 中做异步操作（如 await localStorage.setItem()）——它可能被中断，改用同步写法或降级为 sessionStorage

pagehide + event.persisted 是补漏关键

有些浏览器（尤其是 Safari）不触发 freeze，而是走 pagehide 并把 event.persisted 设为 true，表示页面将被缓存而非销毁。如果你只监听 freeze，这部分用户的状态就丢了。

实操建议：

• 在 pagehide 中检查 event.persisted === true，再判断 frozen !== true，满足两者才执行一次 saveState()
• 加一层防抖：用 performance.now() 记录上次保存时间，200ms 内不再重复写入，避免 freeze 和 pagehide 连续触发导致冗余操作
• 别在 pagehide 里读取 DOM 状态——此时页面可能已不可见，某些元素的 offsetHeight 或 getBoundingClientRect() 返回 0

状态序列化要避开 DOM 引用和函数

saveState() 如果直接 JSON.stringify(this.state)，而 state 里存了 document.querySelector(...) 或事件处理器，会报错或序列化为空对象。移动端冻结后恢复时，这些引用早已失效。

实操建议：

• 只保存可序列化的原始值：字符串、数字、布尔、纯对象、数组；剔除 Node、EventTarget、Function 类型字段
• 对表单控件状态，优先读 input.value、textarea.value、select.selectedIndex，而不是绑定到整个 DOM 节点
• 滚动位置用 window.scrollX / window.scrollY，别存 element.scrollTop —— 元素可能被重建

恢复逻辑不能只靠 visibilitychange

很多人以为页面切回前台时监听 visibilitychange 就能恢复状态，但问题在于：这个事件触发时，JS 可能还没完全“解冻”，或者 DOM 尚未重绘，setState() 后 UI 不更新。

实操建议：

• 在 resume 事件（如果支持）或 visibilitychange 后加一个 setTimeout(() => { restoreState() }, 0)，让恢复逻辑进下一轮事件循环
• 恢复前先校验 document.visibilityState === 'visible' 且 document.hasFocus() === true，避免误恢复
• 滚动位置恢复要用 window.scrollTo({ left, top, behavior: 'auto' }) —— behavior: 'smooth' 在冻结恢复初期可能被忽略

状态保存真正难的不是“怎么存”，而是“什么时候算存对了”：freeze 和 pagehide 的触发时机因浏览器而异，DOM 生命周期和 JS 执行挂起边界模糊，稍有疏忽就会出现“看起来存了，切回来却没恢复”的情况。务必在真机上用 Chrome DevTools 的 Rendering → Paint Flashing + Background throttling 模拟验证。