如何使用 dom.min_background_timeout_value 严格限制 Firefox 中的后台标签

如何使用 dom.min_background_timeout_value 严格限制 Firefox 中的后台标签

哪些设置正确,可以有效限制 Firefox 中的后台标签?

几年前我偶然发现这个帖子解释了 Firefox 中用于限制后台(和前台)标签的各种about:config设置,但我始终无法理解它们的含义。例如,不清楚每个选项的单位是什么(秒还是毫秒?),以及增加值是否会更多地限制标签或减少标签的限制。

dom.min_background_timeout_value
dom.timeout.background_budget_regeneration_rate
dom.timeout.background_throttling_max_budget
dom.timeout.budget_throttling_max_delay
dom.timeout.foreground_budget_regeneration_rate
dom.timeout.foreground_throttling_max_budget
dom.timeout.throttling_delay

具体来说,让我们采取一种非常激进的限制策略:我想让后台标签每 30 分钟仅获得 1ms 的执行时间。我希望此策略在标签页不再处于前台后 1 毫秒生效。也就是说,在我将标签页留在后台后 30 分钟内,标签页的 CPU 使用率不得超过 0.00%。

为了实现这种积极的限制行为,这些 Firefox 设置的值应该是多少?

答案1

当我将标签页留在后台 30 分钟内时,标签页的 CPU 使用率绝不会超过 0.00%。

可以通过在以下位置设置以下条目来实现about:config

dom.min_background_timeout_value 1,800,000
dom.min_tracking_background_timeout_value 1,800,000
dom.timeout.throttling_delay 1

根据Mozilla 文档中有关 window.setTimeout 的“非活动标签页”部分

为了减少后台标签的负载(以及相关的电池使用量),非活动标签的超时触发频率被限制为每秒不超过一次(1,000 毫秒)。

Firefox 从版本 5 开始实现了此行为(请参阅错误 633421,可以通过 dom.min_background_timeout_value 首选项调整 1000ms 常量)。Chrome 从版本 11 开始实现了此行为(crbug.com/66078)。

自 Firefox 14 中的 bug 736602 以来,Android 版 Firefox 对后台标签的超时值为 15 分钟,并且后台标签也可以完全卸载。

因此,Firefox 上的默认值为dom.min_background_timeout_value15 分钟(实际上设置为900,000,因为单位是毫秒),这对于试图节省电池和稀缺 RAM/CPU 资源的设备来说是有意义的。将该值加倍以达到 30 分钟 = 1,800,000

about:config请注意,在限制跟踪脚本( )中有一个不同的条目dom.min_tracking_background_timeout_value,它也应该增加到相同的1,800,000ms 值。

默认情况下,标签页不是当标签页被置于后台时,会立即受到限制。为了改变这种情况,我们将其设置dom.timeout.throttling_delay1ms,以便在标签页被移至后台时几乎立即开始限制它们。

我不知道其他条目的大多数about:config内容是做什么的。这些budget条目特别令人困惑,欢迎进一步澄清。

答案2

对于比简单的“大量限制所有计时器”更复杂的工作负载:即,如果计时器很短,则让它们更频繁地运行,Firefox 中还有一个计时器预算机制。此预算机制仅允许计时器在有“预算”的情况下运行,该预算会减少给定选项卡中计时器运行的时间量,并增加缓慢的再生时间。当它为负数时,计时器将被阻止运行。请注意,计时器似乎是每个选项卡的:功能原理强烈暗示,对计时器“礼貌”的选项卡会得到奖励,而没有礼貌的选项卡会受到惩罚。

about:config 中的以下选项可用于调整此功能:

dom.timeout.background_budget_regeneration_rate降低计时器运行时间的速率。它以实时毫秒数为单位,在选项卡中后台选项卡计时器的预算增加一毫秒之前必须经过该时间。

dom.timeout.background_throttling_max_budget设置预算中可以存储的最大毫秒数。一旦预算达到该大小,它就会停止增加。

dom.timeout.budget_throttling_max_delay设置给定选项卡中定时器可强制等待的最大毫秒数。它可覆盖预算机制的其余部分。

因此,如果 regeneration_rate 设置为 60,max_budget 设置为 3000,那么选项卡将为每分钟实际时间增加一秒的执行时间。如果在这种情况下将 max_budget 设置为 3000,那么三分钟后预算将保留 3 秒的执行时间,并将停止增加:因此六分钟后,它仍将保留三秒。假设 max_delay 设置为 1000(即预算最多只能保留一秒钟的计时器)。请注意,这些设置远非最佳。

如果上述选项卡中的计时器随后花费 5 秒钟执行(这种情况不太可能发生),则预算将为 -2000 毫秒。如果该选项卡中的另一个计时器立即过去,则将被迫等待 2 分钟,直到预算重新生成为正值。但是,由于 max_delay 非常低(1 秒),因此无论如何在触发计时器之前只会经过 1 秒。

我不知道这与 Michael 描述的更传统的超时机制如何相互作用。请参阅此邮件列表帖子了解有关该机制的更多详细信息。

相关内容