|
|
|||||
Сущность слушателя события
Всем привет. А что есть слушатель события на самом деле? Как часто он прослушивает нужное ему событие и когда именно? Почему не рекомендуется делать много слушателей у однотипных объектов и по возможности делать один слушатель у их контейнера? Чем грозят склеенные приемники событий у слушателя одного объекта?
Один вопрос - одна тема, но вопросы однотипные, объединенные одной и довольно конкретной темой.
__________________
тут я |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
1. То что ты пишешь вторым параметром в addEventListener. Функция, принимающая параметром объект данного события.
2. Не понял вопроса. Когда возникает событие, функция-обработчик вызывается и ей отдается событие. 3. Зависит от контекста, в котором это советовалось. 4. Что это - "склеенные приемники событий"?
__________________
Reality.getBounds(this); |
|
|||||
Цитата:
2. Как часто флеш плеер проверяет, не наступило ли то или иное событие? 3. Скажем, пули добавляются в контейнер с пулями, пуль несколько десятков. Советовали делать один слушатель на весь контейнер и двигать эти пули в нем, а не вешать каждый слушатель на каждую пулю. 4. А вот здесь придется немного расписать: Имеем класс А, в нем к stage присобачивается слушатель события enterFrame a() Имеем класс B, в нем к тому же stage присоединяется слушатель того же события b() Я правильно понимаю, что эти слушатели суммируются? Таких слушателей на stage, ловящих одно и то же событие, может быть больше, чем два. Чем это грозит?
__________________
тут я |
|
|||||
2. Сразу, когда происходит dispatchEvent
3. ENTER_FRAME бросается из каждого отображаемого объекта, но если вы добавите обработчик в контейнер, у вас вызовется одна функция, если к каждой пуле, то вызовов будет столько, сколько пуль. Т.е. производительность хуже. 4. Грозит тем, что у вас не будет полной уверенности в том, какой обработчик вызовется раньше. |
|
|||||
2. Это и так понятно. Я хочу узнать конкретнее. Скажем, как часто ФП проверяет, нажали ли мы на кнопку? Раз в кадр? Или 100 раз в секунду?
3. А, ну я догадывался, что так оно и происходит. 4. Только это? Тогда нужно так проектировать код, чтобы не было зависимости двух методов-приемников.
__________________
тут я |
|
|||||
2. По-сути все равно, можно принять: раз в кадр, ввиду того, что код выполняется раз в кадр, чаще вы его поймать не сможете.
4. Можно выставить приоритет, это даст некоторую гарантию последовательности. |
|
|||||
Цитата:
Цитата:
__________________
...вселенская грусть |
|
|||||
alatar по-своему прав. Весь код выполняется раз в кадр. Думаю, все диспатчи событий в этом кадре тут же ловятся слушателями и обрабатываются в этом же кадре. Продолжаю думать дальше: ФП нет смысла проверять очень часто, был ли диспатч того или иного события. Ибо он может произойти только раз в секунду/FPS. Но как быть тогда с таймерами? Они разве настолько сильно привязаны к кадрам, что код метода их "тика" выполняется только синхронно с другим кодом? Хотя, там, наверно, выполнение метода по таймеру может варьироваться в очереди выполнения всего кода.
Логично же, нет? Цитата:
__________________
тут я |
|
|||||
Цитата:
Событий за кадр можно отправить сколько угодно. Пока все обработчики не отработают, мы на следующий кадр не попадем. Именно поэтому fps может падать при большой нагрузке - т.к. рендер привязан к коду (что, ИМХО, не всегда есть хорошо) Вы поймите, что dispatchEvent практически ничем не отличается от прямого вызова всех слушателей (или, если хотите, прямого вызова функций). С той лишь разницей, что при dispatchEvent мы, в принципе, не всегда знаем, что будет вызвано ЗЫ То есть тут вообще никто ничего не проверяет, а просто выполняются нужные методы
__________________
...вселенская грусть |
Часовой пояс GMT +4, время: 20:41. |
|
« Предыдущая тема | Следующая тема » |
Теги |
слушатель событий |
|
|