Но, когда смотришь чьи либо исходники в сети, то замечаешь что такую
технику мало кто применяет.
Помогите разобраться как лучше? Как практичнее?
--
ign
_____________________________________________________________________
http://www.isky.ru
Правильным путем идете, товарищ.
Есть еще подписки со слабыми ссылками, но я лично их не использую.
По-моему это не дело намеренно позволять себе забывать отписываться от
событий. Чем больше таких моментов, тем больше анархии в системе. А
когда начинается передел власти между тобой, разработчиком, и классами
системы, обычно все встает колом.
А что до чужого кода... Если ты пишешь три строчки кода для баннера,
можешь вообще ничего не удалять. Никто не заметит. :) А если система
большая и сложная, то без какого-то разумного управления временем жизни
объектов не обойтись. И понимание необходимости всяких destroy() и т. п.
приходит как раз тогда, когда в таск манагере прочесс firefox.exe
доедает последнюю планку памяти и начинает вгрызаться в материнскую
плату. Поэтому может показаться, что такой подход мало кто использует.
Немного кто разрабатывает такие системы, где без этого не жить.
--
Michael Antipin
______________________________________________________________________
n...@gammagroup.ru | http://www.gammagroup.ru | http://www.noregret.org
ясно, а обнуление ссылок это значит всем переменным присваивается
NULL?
С таким же успехом можно, например, true присваивать или 2009 если тип позволяет :)
Гарбаж коллектор очень хорошо на null реагирует )
On 26 дек, 20:01, "andrey Vichodcev" <andrey.vichod...@gmail.com>
wrote:
Чтобы следить, какие объекты удаляются, а какие нет, можно
воспользоваться профайлером из Flex Builder. Правда он жутко глючный.
По крайней мере у меня возникало много проблем, когда я пытался
подсунуть ему произвольную .swf-ку.
Ещё можно соорудить свой псевдопрофайлер-монитор. Для этого создаете
словарь со слабыми ссылками:
monitor = new Dictionary(true);
Затем помещаете туда все подозрительные объекты:
monitor[suspectedObject] = true;
И когда нужно, проверяете, что в нём ещё осталось:
for each (var i in monitor) {
textField.appendText(i+"\n");
}
Хак с двумя локалконнекшнами рассказал Грант Скиннер еще в 2006 году.
Гуглом можно найти. Как он дошел до жизни такой -- неведомо, но это
работает.
try {
new LocalConnection().connect("gc");
new LocalConnection().connect("gc");
} catch (error:Error) {
// ignore
}
Это заставит GC запустится. Однако, стоит учитывать, что за один проход
коллектор может и не собрать весь мусор (никто этого и не обещал).
> Есть ещё метод gc(), но он работает только в Debug версии
> проигрывателя.
Кстати в AIR работает и в недебаговой версии, если контент, который
запускает System.gc() находится в песочнице установленного AIR-приложения.
Еще незнаю хак или нет но GC србатывает при вызове метода Loader.unloadAndStop()
Однако, стоит учитывать, что за один проход
коллектор может и не собрать весь мусор (никто этого и не обещал).
try {
new LocalConnection().connect("gc");
new LocalConnection().connect("gc");
} catch (error:Error) {
// ignore
}