Web Worker 是否会限制 setTimeout()/setInteval()?

问题描述

我在 前台 选项卡上有一个启动(专用)网络工作者的脚本.现在我看到该网络工作者中的 setTimeout(xxx, 100) 被限制为每秒触发不超过一次，而不是根据需要每秒触发 10 次.我在谷歌上搜索了非活动选项卡的这种限制，但是否有任何文档对 Web Workers 说同样的话?我已经在 Chrome 和 Firefox 中检查过了.

解决方案

没有关于这种限制行为的真正规范，即使 他们确实允许:

1. (可选)等待实现定义的进一步时间长度.

这旨在允许用户代理根据需要填充超时以优化设备的电源使用.例如，一些处理器具有低功耗模式，在这种模式下，定时器的粒度会降低；在此类平台上，用户代理可以减慢计时器以适应此计划，而不是要求处理器使用更准确的模式及其相关的更高功耗.

Chrome 有 此文档 来自 2017 年他们公开他们计划如何处理背景标签.

从那里我们可以看到 计划部分网络工作者:

限制网络工作者(~2018 年)

我们目前正在对网络工作者进行检测，以更好地了解他们的 CPU 使用情况和电源影响.我们也考虑限制网络工作者，考虑尽量减少损坏的内容.

所以这被安排在 2018 年，这是跟踪其部署的问题.

还应该注意的是，目前正在积极讨论 WICG 以实施 页面-生命周期 API.此 API 将公开一些事件，并提供一个新的冻结"事件.状态，对于我们感兴趣的，也应该暂停工人的执行.

I have a script on foreground tab that starts (dedicated) web worker. Now I see that setTimeout(xxx, 100) in that web worker is limited to be triggered not more often than once per second instead of 10 times per second as required. I've googled such a limitation for inactive tabs but are there any docs that say the same about Web Workers? I've checked this in Chrome and Firefox.

解决方案

There is no real specs about that throttling behavior, even though they do allow it:

Chrome has this document from 2017 where they expose how they planned to handle background tabs.

From there we can see a plan section about Web Workers:

So that was scheduled for 2018, and here is the issue tracking it's deployment.

Should also be noted that there is currently an active discussion going on on the WICG to implement the Page-Lifecycle API. This API will expose a few events, and a new "frozen" state, which for what we are interested, should also pause Workers' execution.

这篇关于Web Worker 是否会限制 setTimeout()/setInteval()?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！