后台标签页可能会对浏览器性能产生明显的负面影响,尤其是对电池续航时间。为了缓解此问题,过去几年来,Chrome 对后台标签页施加了各种限制。近期,开发者们付出了很多努力,可以做出进一步改进。本文档简要介绍了 Chrome 政策。本文档重点介绍了 Chrome 57 中的当前政策。 如需查看长期策略和后续计划,请参阅此文档。
针对后台优化应用
Web 开发者应注意,用户经常会在后台打开大量标签页,这可能会严重影响耗电量和电池续航时间。应尽量减少后台工作,除非这是提供特定用户体验的绝对必要条件。您应使用网页可见性 API 来检测网页何时在后台运行,并暂停所有不必要的工作(例如视觉更新)。
对于某些网站,这种简单的优化可以减少高达 75% 的 CPU 使用量:
var doVisualUpdates = true;
document.addEventListener('visibilitychange', function(){
doVisualUpdates = !document.hidden;
});
function update() {
if (!doVisualUpdates) {
return;
}
doStuff();
}
政策
requestAnimationFrame()
根据相关文档,当网页位于后台时,Chrome 不会调用 requestAnimationFrame()
。这种行为从 2011 年起就开始了。
后台计时器对齐
从 Chrome 11 开始,每个独立计时器的运行频率不会超过每秒一次。Chrome 会批量运行这些计时器(每秒运行一次),从而确保尽可能减少进程唤醒次数。播放可听音频的网页被视为用户可见,并不受后台计时器节流的影响。豁免在音频停止播放后持续几秒钟,以便应用将下一个音轨加入队列。
请注意,当且仅当 Chrome 显示音频图标时,音频才会被视为可听。 静默音频流不会获得豁免。
基于预算的后台计时器节流
基于预算的计时器节流是 Chrome 57 中推出的,是对计时器对齐机制的进一步扩展,对后台计时器的 CPU 使用率设定了额外的限制。其运行方式如下:
- 每个后台标签页都有一个用于在后台运行计时器的时间预算(以秒为单位)。
- 网页在后台运行 10 秒后就会受到时间预算限制。
- 仅当时间预算为非负数时,计时器任务才能运行。
- 当计时器执行完毕后,就会从预算中减去其运行时间。
- 预算会随时间不断重新生成(目前设置为每秒 0.01 秒的速率)。请注意,随着 Chrome 收集更多有关节流行为的数据,您可以调整此预算重新生成率。
多种自动豁免应用不受此限制的影响:
- 播放音频的应用被视为前台,且不会受到限制。
- 具有实时连接(WebSocket 和 WebRTC)的应用,以避免因超时关闭这些连接。在这些情况下,仍然应用运行计时器一次规则。
请注意,他的机制使用实际用时,而不是 CPU 时间。它非常接近 CPU 时间,并且可通过降低长时间阻塞主线程进行惩罚。
最后请注意,如果您在后台使用耗时较长的任务,您的应用可能会在很长一段时间(最长为任务时长的 100 倍)内受到限制。根据性能准则,将工作拆分为多个时长为 50 毫秒或更短的块,并使用 visibilityChange
监听器以避免在后台执行不必要的工作。
拒绝联系
Chrome 为运行测试套件和其他由用户批准的密集型计算等用例提供了 --disable-background-timer-throttling
标志。