为什么 history.js 使用 setInterval(.., 250)？答案

【问题标题】：Why history.js uses setInterval(.., 250)?为什么 history.js 使用 setInterval(.., 250)？
【发布时间】：2013-07-15 20:07:48
【问题描述】：

据我了解，History.js 是 HTML5 History/State APIs 的 polyfill。因此，在现代浏览器上，它应该简单地使用popstate 来监听 URL 变化。那么，为什么在最新的 Chrome 上我可以看到计时器每 250 毫秒触发一次？这似乎很浪费，每隔几秒就会触发一次垃圾收集器。

看看这个官方History.js demo。

【问题讨论】：

为什么不用原生JS？
@RomanGorbatko 我们需要支持IE9 and older android browsers。因此，需要使用 polyfill（不是吗？）。
我在 chrome 最新版本中没有收到任何 Timer Fired Records
@NavaRajan 我已经在 OSX 和 Windows 上的 Canary 和 Stable 上对其进行了测试。请确保您已单击时间线选项卡上的“记录”。
据我所知，这与负责刷新任务队列的History.busy 有关。我从未使用或处理过history.js，所以我不确定为什么这是必要的（或者如果有必要不断地运行）。您可以将 History.options.busyDelay 更改为更高的毫秒值以减慢间隔，但您应该进行广泛的跨浏览器测试以查看是否有任何问题。

标签： javascript performance setinterval history.js html5-history

【解决方案1】：

我不知道 History.js 代码，但通读一遍，我相信 @apsillers 是正确的。

配置为队列项之间的间隔为 250 毫秒。该队列中的一些排队功能需要获取历史状态。这些项目通过将其称为忙来强制刷新暂停。

至于为什么会在 HTML5 浏览器中发生这种情况，在我看来，History.JS 不只是切换开关（如果它是 HTML5）然后什么也不做。在他们的github 上，它声明了他们的目标之一：

为所有 HTML5 浏览器提供交叉兼容的体验（它们都实现 HTML5 History API 的方式略有不同，导致不同的行为，有时还会出现错误 - History.js 修复了这个问题，确保体验在整个HTML5 浏览器）

如果 History.js 仍在做一些涉及排队的工作，我猜他们会使用忙超时。

【讨论】：