Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина Flash Player. Иследования проводились только для версии 11.1 standalone debugger for win32. В следующих версиях Flash Player могли как улучшить работу с памятью так и ухудшить, но скорее всего всё осталось также. Итак, garbage collector (GC) исключительно хреново работает с памятью. Он её попросту не очищает во многих случаях или выделяет в разы больше чем требуется.

Вы наверняка знаете, что такое сильные и слабые ссылки и как GC их считает чтобы понять нужен этот объект или нет... Всё это написано во многих местах, в т.ч. в документации по AS3. Я всё это повторять не буду. Здесь описано как всё должно хорошо очищаться: http://help.adobe.com/en_US/as3/mobile/flashplatform_optimizing_content.pdf
Но нифига оно так не работает к сожалению. При соблюдении всех этих правил моя программа всё равно жрала память как сумасшедшая при загрузке, а потом Flash Player просто падал, когда кончалась физическая память в операционной системе. Вот так он работает на самом деле.

Всё началось вот с этой темы в Juick: http://juick.com/eugene20237@ya.ru/2009006 и моего вопроса на StackOverflow: http://stackoverflow.com/questions/11833009/as3-bitmapdata-memory-leaks
Почитайте, если хотите, узнаете много нового о флеше. А ещё почитайте вот эту статью о том что надо реально сделать для оптимизации по памяти на флеше.

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

• Loader в дефолтном своем применении порождает утечки памяти. Поэтому если через него загружается картинка, то надо брать её BitmapData и делать bitmapData.clone(), сохраняя в другую переменную. А потом диспозить существующую картинку в Loader, а затем делать loader.unload(). Ещё на всякий случай можно cacheAsBitmap=false.
  

  PHP:
  
  
  var bitmapData:BitmapData = (loader.contentLoaderInfo.content as Bitmap).bitmapData.clone();
  
  (loader.content as Bitmap).cacheAsBitmap = false;
  
  (loader.content as Bitmap).bitmapData.dispose();
  
  (loader.content as Bitmap).bitmapData = null;
  
  (loader.contentLoaderInfo.content as Bitmap).bitmapData = null;
  
  loader.unload();
  font>
  

  
  Только тогда он работает нормально. И то с учетом, что память очищается секундой позднее. Но очищается. Во всех остальных случаях можно сушить вёсла... При этом Loader остаётся единственным способом загружать картинки без утечек памяти.


• C Embed ресурсами всё гораздо хуже. Под них выделяется всегда в разы больше памяти (в 2 раза обычно) и далее она не очищается никогда. Поэтому просто так Embed ресурсы использовать нельзя. Причина заключается в том, что они построены на Flex-компонентах, а в них много неоптимальной фигни. Юзайте Loader. А если нужно встроить ресурс в приложение, то делайте бинарный Embded, а затем Loader.loadBytes(...). Другого пути пока не найдено.
  

  PHP:
  
  
  [Embed(source="../media/128.png", mimeType="application/octet-stream")]
  
  static private const EmbedBMP:Class;
  
  ..............
  
  loader.loadBytes(new EmbedBMP() as ByteArrayAsset);
  font>
  

  
  


• Использовать много мелких картинок - плохая идея. Флеш будет выделять больше памяти чем требуется. Если же для большой группы картинок (допустим 100 шт.) вызывается dispose(), то их память будет очищена, но не сразу, а как повезет: может через минуту или как угодно Богу Мусорщику. Если же использовать десяток больших картинок (допустим 4096x4096), то память под них будет выделять и очищаться абсолютно корректно и сразу же.


• Выделение памяти под BitmapData происходит не при создании объекта BitmapData, а при первой операции рисования на ней или копирования данных пикселей в неё. Это внутренняя оптимизация BitmapData.


• Говорят, что BitmapData иногда выделяет памяти больше чем надо из-за внутреннего мипмеппинга. Этот мипмеппинг отключить никак нельзя. Также есть информация, что он отключается, если задать размеры картинки не являющиеся степенью двойки. У меня на практике это совсем не подтвердилось, так что никакой возможности управления мипмеппингом скорее всего уже нет.


• Сюда же поделюсь опытом использования трюка с local connection. Так вот, в исходном варианте этого хака LocalConnection создаётся два раза внутри try. Мои эксперименты показали, что надо вписать там три строчки, а не две. Вот так:
  

  PHP:
  
  
  public static function freeMemoryGC(): void
  
  {
  
    // the GC will perform a full mark/sweep on the second call.
  
    try
  
    {
  
      new LocalConnection().connect('foo');
  
      new LocalConnection().connect('foo');
  
      new LocalConnection().connect('foo');
  
    }
  
    catch (e:*)
  
    {
  
    }
  
    //System.gc();
  
  }
  font>
  

  
  В этом случае вероятность очистки памяти сразу гораздо выше (почти всегда сразу очищается). Если сделать два раза эту инструкцию, но вызвать тоже самое хотя бы через 100 мс, то память также очиститься. System.gc() не использую потому что он работает только AIR или только в отладочной версии Flash Player. Кроме того советую почитать эту тему о способах принудительного пинания GC. В частности в ней есть ссылка на такой способ.

Мы закончили работу над демкой игры Optimus online!
Если этот пост вдруг прочитает потенциальный инвестор , добро пожаловать на партнёрский сайт, где выложена демка, скриншоты и инфа об игре.

Уважаемые любители компьютерных игр!

Мы готовы раскрыть карты :) В настоящее время наша команда занимается разработкой компьютерной игры космической тематики. Мы решили сделать процесс разработки открытым и постоянно его освещать! Теперь каждый желающий может присоединиться к разработке игры и внести в неё свой творческий вклад. Поклонники Космических Рейнджеров, Вселенной X, старенькой Элиты и Master Of Orion — объединяйтесь!

Мы собираемся сделать небывалую космическую леталку жанра Elite (вселенная живёт, а ты делай в ней что хочешь) и сдвинуть с места прогресс в этой области! Мы взялись за это из чистого интереса, потому что в деталях знаем как сделать лучше, но в новых играх этого не делается. Почему такие космические цели? А всё остальное просто скучно. Так или иначе, проект уже профинансирован и в любом случае будет завершен. Команда профессионально занимается этой игрой и тратит на неё всё время. Запуск бета-версии намечается в июле 2011г.

Я предлагаю всем творческим людям, интересующихся космической тематикой присоединиться к сообществу разработчиков игры! Игра называется «Optimus». Сообщество разработчиков представляет собой группу ВКонтакте, вот здесь: http://vkontakte.ru/club26470591 — там Вы найдёте всю информацию об игре и ответы на свои вопросы. В группе можно выкладывать свои творения и мы включим их в игру.

Интересных дел в проекте полно. Есть задачи по дизайну, задачи по рисовке, моделирование в 3dmax, озвучка, музыка, придумывание квестов. Ну и программирование конечно. Молодая команда разработчиков просит у Вас помощи. Включи своё творчество, вступай в Optimus!

Присоединяйтесь.
Разработчики игры.

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

Вот Сталкер. К нему много нареканий. Я считаю игра неправильно сбалансирована. В итоге там вообще ничего не нужно чтобы пройти основной сюжет. При желании его можно пройти голым и с пистолетиком. Вообще очень глупо что они этот мир бояться вовсю использовать в игре и делают какие-то дибильные квесты. Вот слабо им было сделать хотя бы автгенератор новых видов аномалий или других премудростей Зоны? Была киллер фича, но это уже для игр будущего, а сейчас им и так хорошо. Меня это просто бесит в современном игростроительстве. Везде именно так. Можно сделать реально круто, но это не делается.

Есть целый вагон научных областей, в первую очередь в математике, где описаны интереснейшие алгоритмы, пригодные для использования в играх. В будущем они станут элементами ИИ, но для нас это не важно. Важно то, что это даже уже придумано, но людям то ли лень в этом копаться, то-ли вообще плевать на интересность игры. Я вот больше склоняюсь ко второму. Но даже если моя игра зашибает кучу денег, я всё равно не остановлю прогресс. Это противоестественно для меня.