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

событие jQuery hashchange

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

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

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

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

2 ответа

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

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


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

- Дополнительная информация -

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

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

licensed under cc by-sa 3.0 with attribution.