![]() |
Необходимость удаления обработчиков событий
Такой пример, создаем мувик, ему добавляем обработку события ENTER_FRAME, по которому просто делаем trace и добавляем возможность по клику удалить этот мувик. Примерно так:
Код:
package {Собственно если внимательно прочитать Help по addEventListener, там об этом четко говорится. Цитата:
Подобное положение дел, лично меня совсем не радует. Т.е. в каждом классе, который обрабатывает любые события, нужно добавлять две функции open() для инициализации обработчков событий и close() для их удаления, которую нужно вызывать перед удалением этого класса. Т.е. просто removeChild уже не достаточно. Или же в каждом классе самому следить за событием removed, по которому удалять все обработчики за собой. Примерно так: Код:
package {У функции addEventListener последним параметром идет Цитата:
Код:
addEventListener(Event.ENTER_FRAME, doEnterFrame, false,0,true);Собственно вот, подскажите где я что неправильно понял... |
removeChild не удаляет экземпляр класса DisplayObject или его наследника, а просто убирает его из контейнера. клип все еще существует, и события все еще работают.
|
Да с этим я тоже не разобрался... А ещё если в объекте использовать setInterval. То после удаления объекта, "интервал" продолжает вызывать функцию. И ругается что не может её найти, потому что объета не сущетсвует.
Приходится каждый раз писать обработчик события removed, что бы убить все интервалы и листенеры. |
Верно. И если после removeChild на клип не осталось других ссылок, то клип удаляется полностью (теоретически, как это проверить не знаю).
Но если у клипа были добавлены какие-либо события, то он не удалится, пока их не освободит. |
Ваще пипец...
Кнопка (клип типа Button) при изменении состояний Up-Over-Down (мышку над ней провели) генерит событие Event.REMOVED, которое могут ловят все ее родители :) |
аксиома ас1-2 :не используйте кнопки юзайте мувиклипы, в ас3 претерпела совсем немного изменений : не юзайте кнопки юзайте спрайты
|
По поводу garbage collector-а... Как он коллектит гарбадж - только ему самому известно. Но то, что он его коллектит - это факт.
По моим наблюдениям убивание ссылок на объект, не приводит к мгновеному физическому уничтожению объекта из памяти - то же касается обработчиков с WeakReference, но через некоторое время объект все-таки удаляется. В частности после удаления последней ссылки обработчик onEnterFrame может еще сработать до 2000 раз, после чего останавливается. Из чего можно сделать вывод, что garbage collector чистит память либо с некоторым периодом, либо с некоторой задержкой. По поводу setInerval - не рекомендуется использовать по соображениям стиля программирования. Эта процедура, скажем так, не вполне объектно-ориентированная, со всеми вытекающими последствиями. |
Цитата:
Код:
package { |
A *very* important thing to understand about the Garbage Collector in FP9 is that it's operations are deferred. Your objects will not be removed immediately when all active references are deleted, instead they will be removed at some indeterminate time in the future (from a developer standpoint). The GC uses a set of heuristics that look at RAM allocation and the size of the memory stack (among other things) to determine when to run. As a developer, you must accept that fact that you will have no way of knowing when (or even if) your inactive objects will get deallocated. You must also be aware that inactive objects will continue to execute indefinitely (until the GC deallocates it), so code will keep running (ex. enterFrames), sounds will keep playing, loads will keep happening, events will keep firing, etc.
It's very important to remember that you have no control over when your objects will be deallocated, so you must make them as inert as possible when you are finished with them. вот |
Unsupported Way to Force GC
There is a trick that will let you force the Flash player to carry out a full GC pass. This trick can be really handy for exploring Garbage Collection, and testing your applications during development, but it should never be deployed in production code because it can wreak havoc with processor load. It is also officially unsupported, so you cannot rely on it to work in updated versions of the player. To force an immediate GC mark/sweep, all you have to do is call connect() on two LocalConnections with the same name. This will throw an error, so you'll have to wrap it in a try/catch block. Код:
try { |
artcraft, спасибо... и очень хорошо бы с русским переводом, т.к. там важно буквально каждое слово.
Похоже GC срабатывает, когда происходит перераспределение памяти. Например, если к моему последнему тесту, благополучно проработавшему два часа так и не удалив мувик из памяти, добавить в руте такой код: Код:
var ar:Array = new Array();Значит useWeakReference из функции addEventListener работает корректно, и его можно использовать для событий типа click, mouse..., focus... Которые зависят от самого мувика. Для событий срабатывающих самостоятельно, типа enterFrame, activate... придется прописывать отдельную функцию на удаление всех созданных Listeners и запускать ее вручную или по Event.REMOVED, смотря по ситуации. |
есть полезная фигня: System.totalMemory
The amount of memory (in bytes) currently in use by Flash Player. |
Есть, только по ней смотреть не получается. Если флеш отхавал кусок памяти, то даже после удаления всего хлама он не торопится память освобождать, и получается, что System.totalMemory показывает не сколько памяти требуется в конкретно данный момент, а сколько всего пришлось выделить в пике.
|
по просьбе Merlin-а перевод сообщения artcraft (мерси ему за цитату)
http://www.gskinner.com/blog/archive...source_ma.html Очень важная вещь, которую нужно понимать при работе со сборщиком мусора в 9-м флешплеере, заключается в том, что эта операция является отложенной. Ваши объекты не будут уничтожены немедленно после того, как все активные ссылки будут удалены, напротив они будут уничтожены лишь через некоторое неопределенное (с точки зрения разработчика) время. Сборщик мусора использует набор эвристических алгоритмов, которые контролируют распределение ОЗУ и размер стека (а также другие факторы) для принятия решения о чистке. Как разработчик вы должны смириться с фактом, что вам не остается никакой возможности для того, чтобы узнать когда (и даже убедиться что) ваши неактивные объекты будут уничтожены. Вам также необходимо знать, что неактивные объекты продолжают выполняться неограничено, (до тех пор пока сборщик мусора не удалит их), а значит код будет продолжать выполняться (например enterFrames), звуки - играть, загрузки - выполняться, события - срабатывать и т.д. Очень важно помнить, что у вас нет никаких методов для управления моментом, когда ваши объекты будут удалены из памяти, в связи с чем, вы должны сделать их максимально пассивными и не взаимодействующими с другими объектами в тот момент когда вы заканчиваете работу с этими объектами. |
Код:
package {но вот заставить GC сработать когда я этого захочу (двойным LocalConnection()) мне не удалось :~/ |
ура я сделал это :~)
теперь для тестовых целей можно провацировать GC сработать тогда, когда это вам угодно у меня срабатывает в течении 2-х секунд Код:
package { |
Цитата:
Код:
private function onRemove(e:Event):void{ |
Забить память разными ненужными объектами, для того чтобы удалить "нужное" событие - не есть правильно!
|
http://www.flasher.ru/forum/showthread.php?t=100234
Что касается того что необходимо отписаться от событий, как правило для этих целей реализуют метод destoy или die, в котором производится чистка ресурсов и отписка от событий в том числе. то есть перед тем как удалить экземпляр вызываем destoy, конечно это усложняет немного жизнь но позволяет избежать многих утечек памяти |
2vooparker, +1
Ручной контроль за удалением обработчиков соответствует принципу всех серьезных языков. Автору рекомендую почитать "OReilly Essential ActionScript 3.0", там обрисованы все важные ситуации. |
Вобщем-то нужно не ленится и запомнить простое правило "Насрал - убери"
Если ремувишь, что либо отпишись от событий, задиспозь битамапы, помочи все ссылки, и будет тебе счатье. Канешно это не решат проблемы GC но решает проблемы с логикой работы вышей программыи и ожидаемым результатом. Ентерфрейм тому пример ). |
Если элементы и листенеры к ним создаются динамически, то можно вызывать при каждом addEventListener какую-нибудь функцию, которая будет добавлять в некий объект наш элемент, событие и слушатель. А потом нужно будет просто пробежаться по этому объекту для очистки всего.
|
| Часовой пояс GMT +4, время: 15:18. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.