对我来说，它现在看起来是最成熟的解决方案（如果我错了，请纠正我）。我真的很喜欢这个用于处理浏览器哈希的插件。在某些情况下，它大大简化了 js 代码。
我真的很想开始广泛使用它，但我有一个问题要问你。
根据源它使用循环并检查哈希锚是否每 50 毫秒更改一次。
性能呢？我可以过度使用 hashchange 吗？它会导致性能显着下降吗？如果是在哪些情况下？
问问题
1254 次
2 回答
5
与您正在运行的所有其他内容相比，每 50 毫秒检查一次简单的字符串属性的成本是微乎其微的，我不会担心这里的性能。如果您经常更改哈希并且您的回调非常非常昂贵，那么处理它（您回调），但检查本身的成本非常非常小。
还要记住，50ms 检查仅适用于没有window.onhashchange内置的浏览器，对于那些它是本机事件的浏览器（这是最现代的浏览器）。
于 2010-08-22T20:22:11.073 回答
0
性能不是问题，所有现代浏览器现在都原生支持 onhashchange 事件，因此不需要间隔检查。
- 更多信息 -
jQuery History Plugin使用 200ms 测试老一代浏览器，这些浏览器本身没有实现onhashchange事件。如果没有本地实现该事件，您必须通过使用间隔更改来解决它的功能 - 据我所知，没有其他方法。幸运的是，所有主流浏览器的最新版本现在都原生支持 onhashchange 事件，因此不再需要此检查。
让我们来看看 200 毫秒间隔检查的作用。如果它们在 IE6 或 7 上，它将检查 iframe 的状态（因为在那些浏览器中，需要 iframe 来模拟后退和前进按钮 - 而对于其他浏览器，则不需要 iframe）。如果他们使用的是另一个不是 IE 的旧浏览器，那么它可以location.getHash()在检查中使用（没有前面解释的 iframe）。这两种类型的检查都被设计为非常快速和尽可能少，将必要的开销降到几乎没有。这完全取决于浏览器实际上愿意让您做什么，并尝试使用尽可能少的密集代码来完成它。
于 2010-09-18T09:50:20.690 回答