Производительность JavaScript .hashchange. Может ли это привести к замедлению?
Для меня это выглядит как наиболее зрелое решение прямо сейчас (пожалуйста, поправьте меня, если я ошибаюсь). Мне очень нравится этот плагин для манипулирования хешами браузеров. В некоторых случаях это сильно упрощает JS-код.
Я действительно хочу начать использовать это широко, но у меня есть вопрос к вам.
В соответствии с источником он использует цикл и проверяет, менялась ли хэш-привязка каждые 50 мс.
Как насчет производительности? Могу ли я злоупотреблять hashchange? Может ли это привести к значительному снижению производительности? Если да, то в каких случаях?
2 ответа
Проверка простого строкового свойства каждые 50 мс - это бесконечно малая стоимость по сравнению, вероятно, со всем, что вы используете, я не буду беспокоиться о производительности здесь. Если вы часто меняете хеш, и ваш обратный вызов очень, очень дорогой, то справьтесь с этим (обратный вызов), но сама проверка стоит очень, очень маленькой стоимости.
Также имейте в виду, что проверка 50 мс только для браузеров, которые не имеют window.onhashchange встроенный, для тех, кто это родной событие (и это большинство современных браузеров).
Производительность не является проблемой, все современные браузеры теперь поддерживают событие onhashchange изначально и, следовательно, не требуют проверки интервала.
-- Больше информации --
Плагин jQuery History использует тест 200 мс для браузеров старого поколения, которые не реализуют onhashchange Событие изначально. Без этого события, реализованного изначально, вы должны обойти его функциональность, используя изменение интервала - просто нет другого пути, насколько мне известно. К счастью, последние версии всех основных браузеров теперь поддерживают событие onhashchange, поэтому эта проверка больше не нужна.
Давайте рассмотрим, что делает проверка с интервалом 200 мс. Если они работают в IE6 или 7, он будет проверять состояние iframe (как в этих браузерах iframe требуется для эмуляции кнопок "назад" и "вперед" - где для других браузеров iframe не требуется). Если они используют другой старый браузер, который не является IE, то он может просто использовать location.getHash() в чеке (без фрейма, как описано выше). Оба типа проверок спроектированы так, чтобы быть чрезвычайно быстрыми и минимально возможными, сводя к минимуму необходимые накладные расходы. Все дело в том, что браузер на самом деле хочет вам позволить, и пытается сделать это с использованием наименее интенсивного кода.