visibilitychange事件需主动监听并兼容旧浏览器,页面隐藏时应手动清理setInterval、requestAnimationFrame等,恢复时需防重复启动。
能省,但只在你主动响应 visibilitychange 事件时才生效;浏览器不会自动停掉 setInterval、requestAnimationFrame 或网络请求——这些都得你自己清。
早期 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)
visibilitychange
不是所有后台行为都值得停,重点盯住「用户看不见却还在高频执行」的逻辑:
setInterval / setTimeout 轮询(如每 3s fetch 新消息)→ 必须 clearInterval,否则 CPU 持续占用requestAnimationFrame 动画循环 → 必须配对调用 cancelAnimationFrame,否则 Canvas 或 CSS 动画照常渲染video.pause(),但别直接 video.currentTime = 0,避免丢失进度render() 调用,GPU 占用会立刻下降visible 状态再批量发,减少小包请求看似简单,实际线上容易翻车:
立即学习“前端免费学习笔记(深入)”;
visibilitychange 不保证实时:快速切两次标签,事件可能被合并或延迟几毫秒,不能依赖它做精确计时document.hidden 是只读的,设成 true 没效果,也别试图用它“模拟隐藏”来测试逻辑hidden 状态 ≠ 页面卸载:pagehide 或 beforeunload 才更接近“即将离开”,visibilitychange 只管“是否可见”visible
最常被漏掉的是轮播图、粒子动画、实时图表重绘这类视觉密集型操作。它们在后台跑着不卡界面,但内存和 GPU 消耗真实存在,一不留神就多占 30% 内存。只要页面有持续运行的 JS 逻辑,就值得加一层 visibilityState 判断。