Форум Flasher.ru - Лики памяти (общее)

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

- - Лики памяти (общее) (http://www.flasher.ru/forum/showthread.php?t=165827)

Лики памяти (общее)

Хочу еще раз затронуть тему ликов памяти при выполнении флеш приложения.
Я думаю, что не все программисты проверяют свои разработки на подобные баги или часто используют профайлер? Особенно остро этот вопрос стоит, когда юзается более менее большое приложение и достаточно долго без его перезагрузки. Я довольно часто ощущаю подобные неудобства, работая с различными приложениями, буквально с каждой минуты его работы, заметна разница в падении производительности работы приложения.

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

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

Код AS3:

public class Test extends Sprite

        {

                public function Test()

                {

                        super();

 

                        this.addEventListener(Event.REMOVED_FROM_STAGE, __thisRemove);

                }

 

                private function __thisRemove(e:Event):void

                {

                        this.removeEventListener(Event.REMOVED_FROM_STAGE, __thisRemove);

 

                        //Отписываемся от динамических событий

                }

        }

Возможно, я никому ничего нового не рассказал. Но кто знает, может кому-то это будет полезным.
Или даже, возможно, я использую велосипед, кто как выходит из положения, можете поделиться опытом?

Вопрос я этот поднял потому, что программируя несколько лет и разрабатывая приложения, где лики памяти были ощутимы, эти две строчки кода в тот момент для меня не были очевидными.

Утечки памяти и их устранение

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

Вопрос такой а если я перезаписываю какую либо переменную новым экземпляром удаляется ли предыдущий объект из памяти?

Код AS3:

var link1:Class = new Class1();

link1 = new Class2();

Удаляется ли то что выделялось под Class1?

Когда придет GC, удалится. Однако все обработчики события так и останутся висеть в памяти, их нужно вручную чистить.

Еще такой вопрос, если внутри контейнера несколько разных объектов, их тоже надо удалять из списка отображения и обнулять перед тем как обнулить этот контейнер, или достаточно обнулить сам контейнер?
Насчет обработчиков понятно. Если они есть внутри контейнера то отписываемся.

Лучше обнулить. Но, насколько мне известно, GC неплохо обрабатывает кольцевые ссылки. А вообще, профайлер в руки и вперед пробовать.

@Vreden

Безобразие. У вас ошибка в слове "памяти". Правильно писать "лики мемори".

Есть хороший русскоязычный термин "утечка".

Цитата:

Сообщение от dimarik (Сообщение 1026019)

@Vreden

Безобразие. У вас ошибка в слове "памяти". Правильно писать "лики мемори".

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

Звучит прям как "лики смерти", Боже упаси. Мемори ликс тогда уже, а лучше, действительно - "утечка пямяти".
Я стараюсь отписаться всегда маниакально от всего, делая деструкторы.

Подписки на самого себя можно не убирать.

Когда проектирую объект стараюсь тщательно продумывать его инициализацию и уничтожение, а от событий стараюсь отписываться сразу как только появляется возможность. GC вызываю silin-ским скриптиком. А по другому и не возможно, ИМХО, контролировать ресурсы.

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

mayakwd как привел сссылку - мне понравилась идея, что от мышиных событий типа клика и овера например отписываться не обязательно. Так ли это?

В первом посте имеет место быть бессмысленная операция удаления обработчика из собственного списка обработчиков. Удаления собственного слушателя может быть целесообразным только в одном случае — обработчик хранится в стороннем объекте, не подлежащему удалению.

это чего-то ты непонятное сказал, как то есть бессмысленная ?
объект, подписавший на ENTER_FRAME свой метод, будет исправно получать в него событие до ~~второго пришествия~~ срабатывания GC, почему бы не отписываться-то от него
другое дело, если события в принципе не будут генериться (мышиные дела например), то и путь бы с ними

Цитата:

Сообщение от dimarik (Сообщение 1026162)

И если это броадкаст событие.

Согласен, есть категория событий, от которых необходимо отписаться когда надобность в их получении пропадает.

Только эти действия к утечкам памяти не имеют никакого отношения.

>>Только эти действия к утечкам памяти не имеют никакого отношения
частично имеют: сами события тоже висят в памяти пока их не подберет GC, это как бы не утечка, рано или поздно почистится, но все же