JavaScript .hashchange 性能。它能带来任何放缓吗？
对我来说，它看起来是目前最成熟的解决方案（请纠正我）如果我错了）。 我真的很喜欢这个用于操作浏览器哈希的插件。在某些情况下它大大简化了js代码。
我真的很想开始广泛使用它，但我有一个问题要问你。
根据来源，它使用循环并检查哈希锚是否每 50 毫秒更改一次。
性能怎么样？我可以过度使用 hashchange 吗？它会导致性能显着下降吗？如果是的话在什么情况下？
For me it looks like most mature solution right now(please correct me if I'm wrong).
I really like this plugin for manipulating with browsers hashes. It simplifies js code a lot in some cases.
I really want to start use it extensively but I have a question for you.
Accordingly to the source it uses loop and check whether hash anchor was changed every 50 ms.
What about performance? Can I overuse hashchange? Can it lead to some significant slowdown in performance? If so in which cases?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与您正在运行的所有其他内容相比，每 50 毫秒检查一个简单的字符串属性的成本是微乎其微的，我不会担心这里的性能。如果您经常更改哈希值并且您的回调非常非常昂贵，那么就处理它（您回调），但检查本身的成本非常非常小。
另请记住，50 毫秒检查仅适用于没有内置
window.onhashchange的浏览器，对于那些浏览器来说，它是本机事件（而且是大多数现代浏览器）。Checking a simple string property every 50ms is an infinitesimal cost compared to probably everything else you're running, I wouldn't be concerned about performance here. If you're changing the hash often and your callback is very, very expensive then deal with that (you callback), but the check itself is a very, very small cost.
Also keep in mind that 50ms check is only for browsers that don't have
window.onhashchangebuilt-in, for those it's a native event (and that's most modern browsers).性能不是问题，所有现代浏览器现在都原生支持 onhashchange 事件，因此不需要间隔检查。
-- 更多信息 --
jQuery 历史记录插件 使用 200 毫秒测试 老一代浏览器本身不实现
onhashchange事件。如果没有本地实现该事件，您必须通过使用间隔更改来解决它的功能 - 据我所知，没有任何其他方法。幸运的是，所有主要浏览器的最新版本现在都原生支持 onhashchange 事件，因此不再需要此检查。让我们来看看 200 毫秒间隔检查的作用是什么。如果它们在 IE6 或 7 上，它将检查 iframe 的状态（因为在这些浏览器中需要 iframe 来模拟后退和前进按钮 - 对于其他浏览器则不需要 iframe）。如果他们使用的是不是 IE 的其他旧版浏览器，那么它可以在检查中使用
location.getHash()（没有前面解释的 iframe）。这两种类型的检查都被设计得极其快速且尽可能最小，从而将必要的开销降至几乎为零。这完全取决于浏览器实际上愿意让您做什么，并尝试使用尽可能最少的代码来完成它。Performance is not an issue, all modern browsers now support the onhashchange event natively and thus do not require a interval check.
-- More Info --
The jQuery History Plugin uses a 200ms test for older generation browsers which do not implement the
onhashchangeevent natively. Without that event implemented natively, you have to workaround it's functionality by using a interval change - there just isn't any other way to my knowledge. Fortunately the latest versions of all the major browsers now support the onhashchange event natively, so this check is no longer needed.Let's go into what what that 200ms interval check does. If they are on IE6 or 7, it will check the state of an iframe (as in those browsers a iframe is required to emulate the back and forward buttons - where for other browsers a iframe is not required). If they are using another older browser which is not IE then it can just use
location.getHash()in the check (without an iframe as explained before). Both types of checks are designed to be extremely fast and as minimal as possible, bringing the necessary overhead down to next to nothing. It's all about what the browser is actually willing to let you do, and trying to do it using the least intensive code possible.