Статья: "ActionScript 3. Работа с памятью"

[bugizavr]

http://www.dtf.ru/articles/read.php?id=51967

доброго времени суток
поясните работу Memory Controller

[willis83]

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

Добавлено через 12 минут
В AS3 нет прямых методов удаление объектов из памяти. Для этого флэш плеер периодически вызывает GC, по русски - сборщик мусора и этот сборщик удаляет из памяти экземпляры классов на которые вы удалили все ссылки, листенеры и который не находится в контейнере видимых объектов, т.е. висит в памяти как сопля на стене и вы уже его никак не сможете использовать. Удаляются только ты объекты которые вы сам отрезали он мира и которые в данный момент не выполняют какой-то код, например как листенер ENTERFRAME.

Добавлено через 16 минут
Я например пишу в классах которые буду удалять функцию prepareForDie в которой удаляю все листенеры, чищу переменные, короче готовлю объект к переходу в мир иной. И для удаления сперва запускаю её, а потом стираю ссылку на экземпляр в его родителе.

[bugizavr]

прошу прощения

хотел написать: "поясните работу Memory Controller"

смотрел код

создание огромного числа объектов, потом их удаление....
как танцы с бубном выглядит для меня

[etc]

Так они и есть танцы с бубном :)
Псевдонаучный код, на самом деле просто нужно перелопатить довольно большое количество бесполезных разношерстных данных, чтобы форсировать GC. А в целом подобные «менеджеры», на мой взгляд, бессмысленны. Код просто должен не только гадить, но и подчищать за собой. А принудительные вызовы GC только лишь снизят производительность.

[willis83]

Если вы про описание класса, то советую вам начать изучение as3 с азов, а не разбора классов utils.

package utils
{
import flash.system.System;
import flash.utils.ByteArray;
import flash.geom.Point;
import flash.utils.setInterval;
import flash.net.LocalConnection;
import flash.utils.setTimeout;

public class MemoryController
{
private var mInterval:int; //Интервал обновления, в милисекундах
private var mWarningMemoryLimit:int; // Размер порога памяти, при котором начинается форсированное очищение
private var mCriticalMemoryLimit:int; // Размер порога памяти, который является критическим
private var mAbortFunction:Function; // Функция, вызываемая при достижени критического порога
private var mWarningFunction:Function; // Функция, вызываемая при достежении опасного порога
private var mForcedIterationsNum:int; // Количество принудительных итераций GC, при достижении порога
private var mForcedCleanInterval:int; // мин. интервал в милисекундах между принудительными очистками
private var mIsAbleToForce:Boolean;

Это собственно определение класса и его внутренних переменных. Далее

public function MemoryController(refreshInterval:int = 1000, warningMemoryLimit:int = 1024*1024*60,
criticalMemoryLimit:int = 1024*1024*100, forcedCleanInterval:int = 60000,
forcedIterationsNum:int = 1,
abortFunction:Function = null, warningFunction:Function = null):void
{
mInterval = refreshInterval;
mWarningMemoryLimit = warningMemoryLimit;
mCriticalMemoryLimit = criticalMemoryLimit;
mAbortFunction = abortFunction;
mWarningFunction = warningFunction;
mForcedIterationsNum = forcedIterationsNum;
mForcedCleanInterval = forcedCleanInterval;
mIsAbleToForce = true;
setInterval(checkMemoryUsage, mInterval);
}
Определение конструктора и передача значений из конструктора в переменные класса, ну а дальше вызывается функция setInterval и там понеслась, анализируйте код.... ну вообще не понятно зачем вам это надо. Тем более автор статьи написал как она работает, чтобы использовать класс, вам не обязательно построчно его разбирать. И вообще в начале освоения as3 можно работать и без таких классов

[bugizavr]

willis83 спасиб за совет)
ну вообще не понятно зачем вам это надо
исходников уже за 150 kb
всерьёз беспокоюсь за производительность флешки
вот создал тему, вдруг кто-нибудь что-то умное скажет

[willis83]

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

[bugizavr]

willis83 - это понятно))
код рефакторю постоянно, почти везде вик референс использую
слежу за ссылками

ну да ладно...

[kemsky]

http://compile4fun.wordpress.com/
можно тоже почитать

[terbooter]

Почитал вспомнил про эти статьи, вот народ развлекается! =)

Следуйте рекомендациям адобе.
Используйте профайлер для контроля и поиска утечек.

И вам не понадобятся всякие подпольные рогатки

[kemsky]

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

[terbooter]

kemsky, я оставил комент в вашем блоге.
http://compile4fun.wordpress.com/2010/11/25/weakreference/
Ответ мне совершенно не понятен =)
Предлагаю перенести дискуссию сюда.

[kemsky]

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

В свою очередь, хочу спросить какие советы адоби вам помогают решать проблемы с памятью :)

[inozemcev]

Почитал вспомнил про эти статьи, вот народ развлекается! =)

Следуйте рекомендациям адобе.
Используйте профайлер для контроля и поиска утечек.

И вам не понадобятся всякие подпольные рогатки

Еще бы написали: пишите как хотите и не парьтесь.

Во первых далеко не у все есть возможность и желание использовать flash builder.
Во вторых flash плеер действительно работает не очевидным образом.
Вы можете сделать все, чтобы тот или иной компонент был удален. Но для того, чтобы в этом убедится вы должны будете вызвать System.gc() . MemoryController был собран по мотивам блогов gscinner.com, написанных аж 2006 году и тогда еще такого метода в System не было и поэтому использовался хак, с классами LocalConnection. С тех пор изменилось совсем немного, если не считать библеотеки flash.sampler.

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

Было бы правильно научить :
1 все EventDispatcher ы в один присест отписываться от событий.
2. объекты определять какое количество жестких ссылок связано с объектом и главное где были объявлены эти ссылки.
3. научить DisplayObject ы корректно уничтожаться (автоматически отсоединять себя и всех потомков, отписываться от событий, обнулять все жестские ссылки на себя и выпихивать их из массивов и кешей)

[dimarik]

Ну, право, велосипеды тоже имеют право быть! Поддерживаю начинания.

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

@kemsky. Бегло посмотрел Ваш блог. Понравилось про совсем не "Дви́гатель Сти́рлинга".

[kemsky]

dimarik, вас тоже спросить про советы адоби? Пока terbooter готовит ответ, может быть вы поможете? =)
назначение слабых ссылок разжевано на википедии (http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D0%B0%D0%B1%D0%B0%D1%8F_%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0)

[dimarik]

На своей памяти помню только одну такую необходимость, да и то в коде BloodHound'a.

[Psycho Tiger]

На своей памяти помню только одну такую необходимость, да и то в коде BloodHound'a.
Для расширения кругозора - для чего там?

[dimarik]

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

[Psycho Tiger]

А, перехват Loader`а. Ну в любых патчах выходит имеет смысл использовать weakReference.

[terbooter]

kemsky, все равно не могу понять зачем общающемуся с сервером классу нужна слабая ссылка на DisplayObject =)

Про ваш пример. Я бы сделал (точнее уже делаю) так:
1) Все классы (вид, модель, контроллер и класс для соединения с сервером- ServerConnector) инстанцируются единожды
2) Инстанцировать многократно нужно только URLLoader (или его наследник ServerURLLoader). Для каждого запроса свой лоадер.
3) По завершению загрузки ServerConnector отписывает от всех событий объект ServerURLLoader и диспатчит нужное событие с данными сервера.
4) Контроллер слушает события коннектора и выставляет нужный флаг у модели и
5) лочит или анлочит вьюшку (MainLayer.lock() или MainLayer.unlock())

При необходимости, если все-таки напихали ссылок в ServerURLLoader на вьюшку, то делаем шаг
3*) вызываем метод ServerURLLoader.destroy(), который убирает все ссылки на внешние объекты.


Добавлено через 5 минут
Лично мое мнение, что если появились циклические ссылки, то архитектура проекта кривовата и утечки памяти, это только "первые звоночки" проблем которые появятся

Добавлено через 13 минут
Про советы от "адобе" =)
Коректнее было бы назвать best practices (http://en.wikipedia.org/wiki/Best_practice).
Это набор рекомендаций, которых придерживается значительная часть опытных программистов.

Добавлено через 39 минут
Углубившись немного в вопрос, могу сказать, что слабые ссылки можно применять для кэширования, которым нельзя управлять =)
Так что, даже это, лучше делать самому.
Тут в конце много интересных ссылок
http://c2.com/cgi-bin/wiki?CanonicalizedMapping