Утечка памяти.
 

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

История такая, решил побаловаться со стрелялкой для сына, и процесс затянулся то федя слетает ни с того ни с сего, то другой гемор. короче сейчас обнаружил утечку памяти, через 10-20 минут игры плеер жует уже почти 500 метров при этом фпс естественно падает. Перечитал кучу всего и пока только теория своя появилась, мне что каждый элемент слушать на предмет удаления родителя и удалять все самому?

У меня пока такая иерархия.
1 - описывается самый простейшая деталь (картинка, событие, вспомогательные фишки)
2- из мелких собирается родитель боле сложный и так далее (чтоб не писать кучу текста в одном файле)
3 - из более сложных собираю потому же принципу еще более сложные пока не добьюсь окончательного результата.

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

после создаю к примеру табло с надписями собранное из выше описанного класса.
и в конце вывожу все это дело на экран.

Так вот насколько я понял если я удалю табло, то все его дети останутся, то есть если я удаляю табло то все textfield`ы останутся в памяти? или же они удаляться вслед за родителем (визуально естественно удаляются), но ощущение что они остаются в памяти. В общем подучите неуча пожалуйста.

пока хоть что-то ссылается на объекты, они останутся

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

это я уже давно усвоил еще когда только начинал осваивать as3. просто пока до сих пор не могу понять как же все таки правильно подчищать память, чтоб при удалении обьекта от него не оставалось ни одного бита (байта, собственно кому как нравиться).
Вот к примеру текущий проект добавляются корабли. Добавляются инамически, я при определенных условиях задал чтобы они удалялись, то есть не важно были ли они уничтожены или просто вышли за пределы поля (такая логика)) корабли добавляются динамиски, при выполнении условий они удаляются, а при добавлении проходят через массив, который при удалении какого-либо корабля, удаляет ЭТОТ корабль из самого массива, то есть по сути удаляется последняя ссылка на этот экземпляр, потом что все другие также чистятся. вот вертиться мысль что в корабле вероятно не все учтено к удалению. к примеру может быть какой-то параметр практически не имеющий отношения к самому кораблю зависает в памяти. вот этого я пока понять не могу.
Сегодня утром отредактировал весь проект и почистил даже числовые и строковые переменные на всем этапе сборки готового экземпляра, но по прежнему наблюдаю увеличение занимаемой памяти, хотя в меньшей степени. вот собственно это и беспокоит то есть на данный момент критическая утечка наблюдается уже не через 10-20 минут а около 30 минут после запуска.

Ну код всё равно никто не видит, но задумайтесь о пулах - это простое, удобное и производительное решение, которое прекрасно защищает от утечек памяти

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

Сам не пробовал такой подход, но может сработать. Нужно создать new Dictionary(true) - словарь со слабыми ссылками на ключи. Пихаете в него все создаваемые инстансы. Также нужна возможность ручного запуска сборщика мусора (flash.system.System.gc() в дебагере или любые методы форсирования сборки в релизом плеере).
Если идея верна, то:
* дожидаемся подозрительно тяжелого состояния;
* приглашаем сборщик мусора;
* делаем несколько дыхательных упражнений, чтобы не терять время, пока сборщик работает;
* мониторим содержимое словаря.
А по хорошему, брейкпоинты и профайлеры - наше все!

Идея верна. У нас получалось зафиксировать факт удаления из Dictionary после двух последовательных вызовов System.gc() через кадр. Я обычно пользуюсь Adobe Scout. Жамкаешь на его кнопку gc пару-тройку раз. Запускаешь что-нибудь тяжелое, что должно будет выгрузиться в момент X. Ждешь или искусственно его достигаешь. Жамкаешь снова на gc несколько раз. Потом смотрим что не выгрузилось между двумя вызовами в меню Memory Allocation. Идем в листинг виноватого класса и тупо видим, что виновата обычно забытая отписка от модели.
В особо упоротых случаях я включаю профайлер Flash Builder. Он тупо показывает GCRoot этого пациента. Но этот профайлер жрет много памяти и времени и падает на пустяках.