Производительность JavaScript .hashchange. Может ли это привести к замедлению?

Question

jQuery hashchange event

Для меня это выглядит как наиболее зрелое решение сейчас (пожалуйста, поправьте меня, если я ошибаюсь).Мне очень нравится этот плагин для манипулирования хешами браузеров.В некоторых случаях он значительно упрощает js-код.

Я действительно хочу начать использовать его широко, но у меня есть к вам вопрос.

В соответствии с источником он использует цикл и проверяет, есть ли хэш-привязкаменялся каждые 50 мс.

А как насчет производительности?Могу ли я злоупотреблять hashchange?Может ли это привести к значительному снижению производительности?Если да, то в каких случаях?

Answer 1

Проверка простого строкового свойства каждые 50 мс - это бесконечно малая стоимость по сравнению с, вероятно, всем , в противном случае вы работаете, я не буду беспокоиться о производительности здесь. Если вы часто меняете хеш, и ваш обратный вызов очень, очень дорогой, тогда справьтесь с этим (вы перезвоните), но сам чек очень, очень небольшая стоимость.

Также имейте в виду, что проверка 50 мс предназначена только для браузеров, которые не имеют встроенного window.onhashchange, для тех, кто является нативным событием (и это большинство современных браузеров).

Answer 2

Производительность не является проблемой, все современные браузеры теперь поддерживают событие onhashchange изначально и поэтому не требуют проверки интервала.

- Подробнее -

Плагин jQuery History использует тест 200 мс для браузеров старшего поколения , которые не реализуют событие onhashchange изначально. Без этого события, реализованного изначально, вы должны обойти его функциональность с помощью изменения интервала - просто нет другого пути, насколько мне известно. К счастью, последние версии всех основных браузеров теперь изначально поддерживают событие onhashchange, поэтому эта проверка больше не нужна.

Давайте рассмотрим, что делает эта проверка с интервалом 200 мс. Если они работают в IE6 или 7, он будет проверять состояние iframe (так как в этих браузерах iframe требуется для эмуляции кнопок «назад» и «вперед» - где для других браузеров iframe не требуется). Если они используют другой более старый браузер, который не является IE, тогда он может просто использовать location.getHash() в чеке (без iframe, как описано выше). Оба типа проверок спроектированы так, чтобы быть чрезвычайно быстрыми и минимально возможными, сводя к минимуму необходимые накладные расходы. Все дело в том, что браузер на самом деле хочет вам позволить, и пытается сделать это с использованием как можно менее интенсивного кода.