HTML中如何使用Page Visibility API节省后台资源
能省吗？答案是肯定的，但有个关键前提：它只在你主动响应 visibilitychange 事件时才生效。浏览器可不会那么“贴心”，自动帮你停掉那些后台的 setInterval、requestAnimationFrame 或是网络请求——这些资源清理工作，都得开发者自己动手。
监听 visibilitychange 事件要兼容旧版浏览器
说起来，这个API的标准化之路还有点小波折。早期的Chrome、IE和Firefox都曾使用带前缀的事件名，比如 webkitvisibilitychange、msvisibilitychange。好在现代浏览器已经统一支持标准事件名 visibilitychange。不过，如果你的项目还需要顾及IE10或Android 4.4 WebView这类“老前辈”，那就得做点兼容处理了：
- 首先，检查
document.hidden属性是否存在，如果不存在，基本可以判定浏览器不支持，直接跳过即可。 - 接着，可以用一个小技巧来探测当前可用的前缀：
['', 'webkit', 'ms', 'moz'].find(prefix => (prefix + 'Hidden') in document)。 - 注册事件时，使用动态拼接的事件名：
document.addEventListener(prefix + 'visibilitychange', handler)。 - 值得注意的是，Safari 13.1+ 以及所有现代版本的 Chrome、Firefox、Edge 都已完全支持无前缀版本，直接使用
visibilitychange就行。
document.visibilityState === 'hidden' 时该停哪些东西
当然，也不是所有后台行为都需要“一刀切”地暂停。我们的核心目标，是盯住那些“用户看不见却还在后台高频执行”的逻辑。哪些是重点目标呢？
setInterval/setTimeout轮询：比如每3秒拉取一次新消息的fetch请求。这类定时器必须用clearInterval清理，否则CPU占用会持续存在。requestAnimationFrame动画循环：无论是Canvas动画还是CSS动画，只要涉及持续渲染，就必须配对调用cancelAnimationFrame来停止。- 视频/音频播放：调用
video.pause()暂停即可。但要避免直接重置video.currentTime = 0，否则用户的播放进度就丢失了。 - WebGL渲染帧：停掉
render()函数的调用，GPU的占用率会立刻降下来。 - 非关键日志或埋点上报：这类请求可以暂时攒在一个数组里，等页面状态恢复为
visible时，再批量发送出去，能有效减少零碎的网络小包。
容易忽略的边界情况和坑
原理看似简单，但在实际线上环境中，稍不留神就容易踩坑。下面这些情况，值得你多看一眼：
立即学习“前端免费学习笔记（深入）”；
visibilitychange事件不保证实时：如果用户快速切换两次浏览器标签页，事件可能会被浏览器合并或延迟几毫秒触发。因此，不能依赖它来做精确的计时逻辑。document.hidden是只读属性：试图将它设为true来模拟隐藏状态是无效的，也别用这种方式来测试你的暂停逻辑。hidden状态不等于页面卸载：真正表示“页面即将离开”的事件是pagehide或beforeunload。而visibilitychange只管“页面是否可见”这一件事。- WebView环境需谨慎：在微信内嵌页、Android App内置WebView等场景下，需要确认宿主环境是否启用了Page Visibility API支持。部分老版本WebView可能始终返回
visible。 - 暂停后恢复时，需防重复启动：页面重新可见时，别急着盲目重启所有定时器。先检查一下它们是否已经被手动清除，避免造成重复启动，导致逻辑错乱。
话说回来，最容易被漏掉的往往是那些视觉密集型操作：轮播图、粒子动画、实时图表的重绘……它们在后台运行时，用户可能感觉不到界面卡顿，但内存和GPU的消耗却是真实存在的，一不留神就可能多占用30%的内存。所以，一个实用的经验法则是：只要页面中存在持续运行的Ja vaScript逻辑，就值得考虑加一层 visibilityState 的判断。这不仅是优化，更是一种对用户设备资源的负责态度。
