jquery unbinding увеличивает скорость событий - PullRequest
1 голос
/ 19 марта 2009

У меня есть большая слайд-шоу с содержимым, которую я создаю, которая начинает использовать много триггеров событий. Также около половины из них используют плагин livequery.

Увижу ли я увеличение скорости, выгружая эти события между слайдами, чтобы только активный слайд имел связанные события?

Кроме того, встроенный livequery значительно быстрее, чем плагин livequery? (Потому что он, безусловно, менее функционален)

Также было бы что-то вроде этого: http://dev.jquery.com/attachment/ticket/2698/unload.js

также отменить привязку событий livequery?

Мне просто нужно знать, сколько времени требуется, чтобы выгрузить / загрузить прослушиватель событий против того, сколько циклов они действительно съедают, если я оставлю их запущенными. Также любая информация о живых событиях была бы потрясающей.

Ответы [ 3 ]

7 голосов
/ 19 марта 2009

Мне нужно больше деталей, чтобы предложить реальный код, но вы можете посмотреть Делегирование событий :

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

Быстрый базовый пример:

Скажем, у вас есть DIV с изображениями, например:

<div id="container">
    <img src="happy.jpg">
    <img src="sad.jpg">
    <img src="laugh.jpg">
    <img src="boring.jpg">
</div>

Но вместо 4 изображений у вас есть 100 или 200. Вы хотите связать событие щелчка с изображениями, чтобы действие X выполнялось, когда пользователь нажимает на него. Первый код большинства людей может выглядеть так:

$('#container img').click(function() {
    performAction(this);
});

Это будет связывать дерьмо с обработчиками событий, которые снизят производительность вашей страницы. С делегированием событий вы можете сделать что-то вроде этого:

$('#container').click(function(e) {
    if($(e.target)[0].nodeName.toUpperCase() == 'IMG') {
        performAction(e.target);
    }
});

Это будет привязывать только 1 событие к фактическому контейнеру, затем вы сможете выяснить, что было нажато, используя свойство target события и соответствующим образом делегировать. Это по-прежнему немного болезненно, и вы можете добиться значительного улучшения производительности, не делая всего этого, используя функцию jQuery live:

$('#container img').live('click', function() {
     performAction(this);
});

Надеюсь, это поможет.

3 голосов
/ 20 марта 2009

Если под "нативным liveQuery" вы подразумеваете live(), то да, live() значительно быстрее, чем liveQuery(). Последний использует setInterval для периодического запроса всего дерева документа о новых элементах, в то время как первый использует делегирование события .

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

Что касается вашего второго вопроса, похоже, что вы привязываетесь к элементам каждого слайда и хотите знать, является ли повторное связывание и связывание снова эффективным? Я бы сказал, WRT памяти, да. WRT ЦП, №

Для ясности, при подходе liveQuery() ЦП никогда не будет спать.

1 голос
/ 23 мая 2009

За что это стоит. Мы только что провели несколько тестов по этому вопросу. Мы создали страницу с элементом div, содержащим несколько элементов div, каждый из которых должен иметь обработчик onclick, отображающий диалоговое окно с отображением их идентификатора.

В одном случае мы использовали регистрацию событий DOM Level 0 и определили обработчик событий для каждого непосредственно в html для каждого: onclick = "_ do_click (this);". В другом случае мы использовали распространение события DOM уровня 2 и определили один обработчик события для содержащего элемента div.

То, что мы обнаружили, при 100 000 содержащихся div, было незначительной разницей во времени загрузки в FireFox. Это заняло много времени. В Safari мы обнаружили, что уровень 0 DOM брал в два раза больше времени, чем уровень 2 DOM, но все равно был в четыре раза быстрее, чем любой случай FireFox.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...