![]() |
Вопрос по Garbage Collector
задался вот таким вопросом: "Если в приложение загружается изображение или мувик (не важно, что именно ) и после загрузки нужно удалить loader, то как правильно (если так можно выразится) удалить этот loader, что бы он не завис в памяти с концами". Почитал не много немало литературы по этой теме, в частности заглянул в книгу Мука, вообщем написано везде, что нужно удалить все ссылки на объект а потом обнулить, но как быть в случае, когда нужно, например, загрузить картинку а после удалить loader, но при этом у нас есть ссылка на битмап, удаляем все слушатели , обнуляем loader , выводи в трейс и получаем null, то есть то к чему стремились, но мне не до конца понятно, удалится из памяти сборщиком мусора loader или нет ? И, наверное, из-за того, что есть ссылка на одно из его свойств, а точнее на свойство contentLoaderInfo.
Вот кусок кода в пример: Код AS3:
|
По идее лоадер должен удалиться при следующем вызове GC.
Грубо говоря, этот пример работает по тому же принципу: Код AS3:
|
Попытаюсь порассуждать.
Лоадер никуда не денется и GC не может его удалить. Bitmap, как DisplayObject, имеет ссылку на LoaderInfo, который содержит ссылку на Loader. Код AS3:
Т.о. пока существует хоть один визуальный объект, загруженный через данный Loader, экземпляр этого лоадера не будет уничтожен. Добавлено через 18 минут Не. Даже не так ) Пока существует ссылка на ApplicationDomain, в который лоадер загрузил классы, то будет существовать и сам лоадер. О, как! Кстати, так как картинка является экземпляром Bitmap класса без имени, то "выдернуть" ее класс непосредственно из ApplicationDomain и сделать еще один экземпляр не представляется возможным. Но это можно сделать через ссылку на конструктор BitmapData. В своих экспериментах с байткодом я загружал картинку, оборачивал ее бинарные данные в именованный класс и, вуаля! Имеем картинку, которую можно в любой момент инстанцировать по ApplicationDomain#getDefinition(). Добавлено через 1 час 22 минуты Если будет существовать корневой объект (ссылка DisplayObject#root указывает на него), то можно получить ссылки на loaderInfo и его loader. Для загруженных через Loader изображений корневым объектом является сам Bitmap. Опять же это говорит в пользу того, что loader не уничтожается. |
не лоадер, а Кощей бессмертный получается. т.е. чтобы убить лоадер нужно сделать тройное сальто.
|
olexandr, то есть, если ссылка на другой объект через свойство первого объекта сохраняется в другом объекте - первый будет удален из памяти.
Тогда в случае с loader, сам loader мог бы быть удален, а значение bitmap и byteArray сохранилось бы. Вернусь к Вашему примеру, а именно в второй строчке Код AS3:
а вот если это ссылка на одно из свойств объекта, то ссылка ведет на тот участок памяти в котором и есть наш объект по ссылке, и при следующем обращении к bitmap мы обращаемся напрямую к объекту типа данных Bitmap минуя loader и его свойство loaderInfo, и это значит, что loader может быть удален со своими свойствами сохраняя при этом bitmap, но тогда зачем такое удаление объекта, если все что с ним связано не удаляется полностью. Тогда вообще не понятно, что удаляется. Или удаляется, то что не было сохранено прежде по ссылке через loader, а все остальное прежде в памяти будет сидеть. Пожалуйста, уважаемые форумчане, укажите путь праведный. Я уже сам запутался и в одиночку не разберусь. olexandr, вот еще, если сделать вот так: Код AS3:
dimarik, это тот не приятный случай когда первый объект ссылается на второй, а второй на первый, при котором даже зануление не поможет. |
Очень интересная тема.
dimarik, я гружу все Bitmap`ы в текущий ApplicationDomain, т.к. коллапса идентификаторов по getDefinition никак не произойдёт. Но Цитата:
Это очень грустная новость. Что можешь посоветовать для загрузки "мимолетных" картинок, которые могут легко появится на экране и так же легко исчезнуть? Создавать каждый раз для картинки дочерний ApplicationDomain мне кажется совсем не хорошей идеей. Для групп картинок "на сеанс", вроде зашли в комнату - увидели лица людей, вышли, "убили" домен - как-то идея тоже чем-то не нравится. |
Пользуйтесь пожалуйста профайлером, все вопросы отпадут.
Наглядный тест: Код AS3:
Смотреть тест надо в профайлере с веселой кнопочкой "run gc" |
mayakwd опередил )
Профайлер избавит тебя от неизвестности, так как в нем можно не ждать пока GC решит освободить память, а запустить его принудительно и посмотреть на результат. Профайлер есть во Flex и FlashDevelop, это из тех что я знаю. |
Спасибо всем, теперь я узнал что такое профайлер.
А на самом деле замечание такое сказал весьма авторитетный человек и я уверен что слова его ну пустые. Флеш плееров много, в одной из проблема может иметь место. Остается дождаться комментариев. Но за то что вы провели тесты и сказали что в какой-то фп всё ок — спасибо ) |
адекватно работает в любом плеере начиная с 9ой версии, не скажу с какой именно так как проблем в принципе в этом вопросе не возникало.
вообще никто не ставил под сомнения слова димарика, но тесты показывают иную версию происходящего. а ставить авторитет выше адекватных данных попахивает предрассудками. |
| Часовой пояс GMT +4, время: 01:12. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.