Вот что у меня стоит для Eclipse 4.5 (Mars) по минимуму:

Сборка самой IDE: "Eclipse IDE for Java Developers", т.к. Classic уже не нахожу в списке для скачивания.

Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина 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. В частности в ней есть ссылка на такой способ.

Моя девушка решила меня порадовать и написала Hello World. Так приятно это!

<input type="button" value=" Нажми меня " ONCLICK="AlertButton()" >
<script>
function AlertButton()
{
window.alert("Hello, World!");
}
</script>

Вобщем мотивационный метод использовал такой: берёшь лист бумаги и пишешь там текущие задачи. Слева от каждой задачи рисуешь пустой квадратик как в бланке для голосования. Когда задача будет выполнена, ставишь в квадратике галочку. Листок держишь перед глазами на столе. Очень скоро руки сами полезут выполнять эти задачи. Для меня работает.

Пару дней ковырялся чтобы настроить IDE для серверной и клиентской части одного проекта. Захотелось мне заставить IDE одновременно работать как серверной так и с клиентской частью чтобы не тратить внимание на переключение между разными средами. Сложность в том, что клиент и сервер на разных языках, соответственно на Флеше и на Питоне. И вот наконец получилось!

В качестве основы взял среду FDT4, потому что она быстрая и на ней уже работает Флеш. Установил в неё PyDev и кучу разных плагинов, в т.ч. для синхронизации с удалёнными серверами. Серверную часть пока запускаю на той же машине, что и клиентскую, но ничто не мешает и править серверный код удаленно потому что есть RSE для Эклипса. Отдельная проблема была с FlashPlayer, потому что для юнит-тестов он совершенно не нужен и его окошко надо было спрятать. Как это сделать нормально пока не знаю, может быть надо писать тесты на Adobe AIR. Я же извратился и вызываю плеер через браузер в одной и той же вкладке, а само окно браузера скрыл навсегда сторонней утилиткой. В результате у меня получилась IDE с двумя консолями и двумя проектами, где ничто не отвлекает от сути.