Предполагая, что вы используете Flex Builder, вы можете попробовать Profiler. По моему опыту, это не так хорошо для производительности профилирования, но это очень помогло найти утечки памяти.
Это не самый интуитивно понятный инструмент, и требуется некоторое время, чтобы привыкнуть к нему (я имею в виду, что он действительно становится полезным). Но, на мой взгляд, инвестировать некоторое время, чтобы хотя бы узнать основы, окупается. Существует огромная разница между тем, сколько памяти использует игрок во всем мире (что дает System.totalMemory, очень грубый, неточный и часто вводящий в заблуждение индикатор) и фактически отслеживает, сколько экземпляров каждого объекта было создано, сколько еще живые и где они были выделены (так что вы можете найти потенциальную утечку в коде и фактически исправить, вместо того, чтобы полагаться на черную магию).
Я не знаю хороших учебников для профилировщика FB, но, возможно, это поможет вам начать работу.
Сначала запустите профайлер. Снимите флажок профилирования производительности и проверьте все остальное (включите профилирование памяти, просмотрите данные живой памяти и создайте трассировки стека выделения объектов).
Когда начинается профайлер, вы увидите статистику об объектах приложения, сгруппированных по классу.На этом этапе вы можете настроить фильтры. Вы увидите много данных, и очень легко быть перегруженным. Пока что, если это возможно, игнорируйте все, что нужно для создания флеш-флеш-файлов, и сосредоточьтесь на каком-то объекте, который, по вашему мнению, должен быть собран.
Наиболее важными цифрами являются «кумулятивные экземпляры» и «экземпляры». Первое - общее количество экземпляров, созданных до сих пор; во-вторых, количество оставшихся экземпляров. Итак, хорошей отправной точкой является получение вашего приложения в состояние, в котором вид, который вы подозреваете, создает утечки. Вы должны увидеть 1 для «кумулятивных экземпляров» и «экземпляров».
Теперь сделайте все, что вам нужно сделать, чтобы добраться до точки, где это представление должно быть очищено (перейти к другой части приложения и т. Д.) И запустить GC (есть кнопка для этого в пользовательском интерфейсе профайлера) , Решающим моментом является то, что вы будете проверять поведение приложения на свои ожидания, если это имеет смысл. Автоматическое обнаружение утечек в собранной среде с высокой загрузкой практически невозможно по определению; в противном случае утечек не было. Поэтому помните об этом: вы проверяете свои ожидания; вы тот, кто знает жизненный цикл ваших объектов и может сказать: «В этот момент этот объект должен был быть собран, а если нет, то что-то не так».
Теперь, если количество просмотров «экземпляры» для вас уменьшено до 0, утечки нет. Если вы считаете, что приложение протекает, попробуйте найти другие объекты, которые могут быть неправильно удалены. Если счетчик остается в 1, это означает, что ваш взгляд просочился. Теперь вам нужно будет найти, почему и где.
На этом этапе вы должны взять «снимок памяти» (кнопка рядом с кнопкой Force GC). Откройте снимок, найдите объект в сетке и дважды щелкните по нему. Это даст вам список всех объектов, имеющих ссылку на этот объект. На самом деле это дерево, и, вероятно, каждый элемент будет содержать в свою очередь несколько обратных ссылок и так далее. Это объекты, которые препятствуют собиранию вашего представления. На правой панели также будет выделена трассировка выделения. Это покажет, как был создан выбранный объект (в значительной степени похожий на трассировку стека).
Возможно, вы увидите количество объектов Хью. Но лучше всего сосредоточиться на тех, у кого более длительный жизненный цикл, чем объект, который вы изучаете (ваш взгляд). Я имею в виду, смотрю на сцену, родительское представление и т. Д .; объекты, от которых зависит ваше представление, а не объекты, которые зависят от вашего представления, если это имеет смысл. Если у вашего представления есть кнопка, и вы добавили к ней слушателя, у вашей кнопки будет ссылка на ваш просмотр. В большинстве случаев это не проблема, так как кнопка зависит от вида и как только собирается представление, так и кнопка. Итак, идея состоит в том, что, поскольку есть много объектов, вы должны стараться сосредоточиться, или вы ничего не получите. Этот метод довольно эвристический, но по моему опыту он работает.
Как только вы обнаружите источник утечки, вернитесь к источнику, измените код соответствующим образом (возможно, для этого требуется не просто изменение кода, но и рефакторинг). Затем повторите процесс и проверьте, вызвало ли ваше изменение желаемый эффект. Это может занять некоторое время, в зависимости от того, насколько большим или сложным является ваше приложение и насколько вы знаете об этом. Но если вы шаг за шагом, обнаружив и устранив одну проблему в то время, вы в конечном итоге избавитесь от утечек. Или, по крайней мере, худшие и более очевидные. Таким образом, в то время как немного утомительно, это окупается (и, как хорошо в стороне, вы, в конце концов, поймете, что трата времени в большинстве случаев используется для использования слабых ссылок для каждого обработчика событий на лице этой земли, аннулирования каждого единственная переменная и т. д., и т. д., это просветительский опыт;).
Надеюсь, это поможет.
Ничего себе, спасибо кучу. Этот двойной щелчок на снимке памяти - это именно то, что мне нужно. К сожалению, визуализация довольно запутана. У меня есть 22 обратных ссылки, состоящих из большого количества UIComponentDescriptors (которые, как я полагаю, являются дочерними родителями), несколько функций (кажется, представляют собой слушатели?), Пару Bindings и PropertyWatchers, но не все, что очевидно * другой * компонент. Пара элементов функции имеет дочерний элемент Button (с таким свойством, как [listener1]), поэтому я предполагаю, что это прослушиватели событий щелчка, определенные в определении MXML. – orlade
Отличный ответ. Это очень помогло мне в профилировании моего приложения flex. – Rajat