Профилирование ActionScript 3.0 проекта

Если Вы не раз профилировали проект, то что-то интересное, возможно, найдете ближе к концу поста.

Вступление

На данный момент единственный инструмент для профилирования это Flex Builder Profiler (хотя необходимый профайлеру API открыт - делай кто хочешь).

В процессе разработки top4top.ru не раз возникали проблемы с утечками памяти, иногда для их устранения приходилось даже вызывать разработчиков в офис по ночам. Иногда память не освобождалась вообще - росла с шагом 50-200 mb от числа переходов по страницам:

Это очень заметно и чинятся, как правило, за несколько часов. Сложнее сказать, есть ли утечка памяти, и где она по такому графику:

Тут уже мало что понятно. Поэтому первый вопрос - как определить, есть ли в приложении утечка памяти.

Определение факта утечки памяти - общие моменты

Тут нам очень поможет функция взятия разности между двумя dump-ами памяти приложения:

Результат - таблица Loitering Objects View, цитата из хелпа:

The Loitering Objects view shows you the differences between two memory snapshots of the application that you are profiling. The differences that this view shows are the number of instances of objects in memory and the amount of memory that those objects use. This is useful in identifying memory leaks. The time between two memory snapshots is known as the snapshot interval.

Для нас в ней самое интересное это имена классов и количество их оставшихся экземпляров.

На схеме выше приведен первый приходящий в голову вариант по поиску memory-leak-ов на Главной Странице. Однако он не работает - в список “бездомных” объектов попадают не только лики с Главной страницы, но и все объекты, создаваемые в Профайле 1.

Определение факта утечки памяти - стратегии

Можно придумать много разных стратегий. На картинке ниже прямоугольниками обозначены состояния системы, в которых инстанциируются объекты. При уходе из состояния его объекты должны удаляться. У нас в top4top состояния были страницами сайта, иногда - разделами (главная, чат).

Устранение утечки

1. В простых случаях достаточно просмотреть код остающихся в памяти классов для устранения ошибки

2. Если она не очевидна, то тут нам поможет окошко Object References, которое показывает все ссылки на объект и открывается по дабл-клику на элементе в таблице Loitering Objects:

   

3. Сложнее всего искать утечки, из-за которых не удаляется вообще ничего. В этом случае два предыдущих способа не работают.

   Именно такая ситуация у нас и была. Утечка находилась в часто исползуемом визуальном компоненте (назывался HtmlText). При создании компонента-страницы LayoutIndex в него где-то глубоко добавлялся экземпляр HtmlText и с тех пор вся иерархия (даже после удаления компонента всей страницы из дисплей-листа) становилась неуязвима для Garbage Collector’а.

   

   Способ борьбы тут оказался довольно простой:

   1. package
   2. {
   3. import flash.display.Sprite;
   4. import flash.events.Event;
   5.  
   6. public class test extends Sprite
   7. {
   8.         private var picture:Picture;
   9.         private var mainText:HtmlText;
   10.         private var enterButton:SomeButton;
   11.         private var closeButton:AnotherButton;
   12.        
   13.         public function test()
   14.         {
   15.                 initContent();
   16.         }
   17.        
   18.         private function initContent():void
   19.         {
   20.                 picture = new Picture();
   21.                 addChild(picture)
   22.                
   23.                 // Дальше в том же духе инициализируем и
   24.                 // добавляем другие компоненты
   25.                
   26.                 // И подписываемся на удаление со сцены
   27.                 addEventListener(Event.REMOVED_FROM_STAGE, onRemovedFromStage, false, 0, true);
   28.         }
   29.        
   30.         // Удаляем все ссылки на дочерние элементы
   31.         private function onRemovedFromStage(event:Event):void
   32.         {
   33.                 picture = null;
   34.                 mainText = null;
   35.                 enterButton = null;
   36.                 closeButton = null;
   37.                
   38.                 while (numChildren > 0)
   39.                         removeChildAt(0);
   40.         }
   41. }
   42. }
   43.  

   Таким образом в памяти остаются только “текущие” объекты и мы с легкостью с помощью таблицы Loitering Objects их удаляем.
   Делать подобные удаления всегда или добавлять этот код только в процессе устранения ликов - это отдельное решение.

Также у нас действует стандарт, что все подписки на события должны быть объявлены с Weak Reference, если нет четких противопоказаний. За весь проект случаев, когда нужна была подписка с жесткой ссылкой было всего несколько. false, 0, true!

Напоследок - регулярное выражение для поиска не-weak подписок: addEventListener\(([\w.\"]*), (\w*)\) (автор: Алексей «Vooparker» Аникутин).

Bookmark this article at …