Отображение ссылок на объект Flex

Question

У меня есть немного проблемы утечки памяти в моем приложении Flex, а короткая версия моего вопроса: Есть ли какие-либо способы (в Acitonscript 3), чтобы найти все живые ссылки на данный объект?

То, что у меня есть несколько просмотров с моделями презентации за каждым из них (используя SWIZ). Взгляды интерес представляют собой дети табнавигатора, поэтому, когда я закрываю вкладку, вид удаляется с сцены. Когда вид удаляется с сцены, SWIZ устанавливает ссылку на модель на NULL, так как она должна. Я также RemovealLhildren () с вида.

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

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

Ваше здоровье.

Answer 1

Предполагая, что вы используете Flex Builder, вы можете попробовать профилировщик. По моему опыту, это не так хорошо для производительности профилирования, но это было отличная помощь для поиска утечек памяти.

Это не самый интуитивно понятный инструмент, и он занимает некоторое время, чтобы привыкнуть к нему (я имею в виду, до такой степени, что он на самом деле становится полезным). Но, на мой взгляд, инвестируя некоторое время, чтобы хотя бы узнать, что основы окупаются. Существует огромная разница между просто видящим, насколько память игрок использует глобально (какую систему .totalmemory дает вам очень грубый, неточный и часто вводящий в заблуждение индикатор) и фактически отслеживать, сколько экземпляров каждого объекта было создано, сколько все еще Живой и где они были выделены (так что вы можете найти потенциальную утечку в коде и на самом деле исправить его вместо того, чтобы полагаться в черную магию).

Я не знаю никаких хороших учебников для FB Profiler, но, возможно, это поможет вам начать.

Во-первых, запустите профилировщик. Снимите флажок Профилирование производительности и проверьте все остальное (включить профилирование памяти, просмотреть данные живой памяти и генерировать следы стека распределения объектов).

Когда Profiler запускается, вы увидите статистику о объектах приложений, сгруппированные по классу. На данный момент вы можете потребовать настройки фильтров. Вы увидите много данных, и это очень легко быть перегруженным. На данный момент игнорируйте все родные для Flash и Flex Task, если возможно, и концентрируйтесь на некотором объекте, который вы думаете, что оно должно быть собрано.

Наиболее важными цифрами являются «кумулятивные экземпляры» и «экземпляры». Первый - это общее количество экземпляров, созданных до сих пор; Во-вторых, количество упомянутых экземпляров, которые все еще живы. Итак, хорошая отправная точка - получить ваше приложение в состояние, где представление, которое вы подозреваете, что утечки создаются. Вы должны увидеть 1 для «кумулятивных экземпляров» и «экземпляров».

Теперь сделайте все, что нужно сделать, чтобы добраться до точки, где следует убрать этот вид (перейти к другой части приложения и т. Д.) и запустить GC (есть кнопка для этого в Profiler UI). Решающим точком является то, что вы будете проверять поведение приложений против ваших ожиданий, которые имеет смысл -. Нахождение утечек автоматически в сборной гардеробной среде близко к невозможности по определению; В противном случае не было бы утечек. Итак, держите это в виду: вы тестируете против ваших ожиданий; Вы тот, кто знает жизненный цикл ваших объектов и может сказать: «В этот момент этот объект должен был быть собран; если это не так, есть что-то не так».

Теперь, если «экземпляры» рассчитывают для вас, отправляется до 0, там нет утечки. Если вы думаете, что утечки приложений, попробуйте найти другие объекты, которые могут не быть правильно расположены. Если счет остается в 1, это означает, что ваш взгляд утечка. Теперь вам придется найти, почему и где.

На данный момент вы должны взять «моментальный снимок памяти» (кнопка рядом с кнопкой GC Force). Откройте снимок, найдите объект в сетке и дважды нажмите на него. Это даст вам список всех объектов, которые имеют ссылку на этот объект. Это на самом деле дерево, и, вероятно, каждый предмет будет содержать в свою очередь, поверните ряд обратных условий и так далее. Это объекты, которые предотвращают собирать ваш взгляд. На правой панели также вы будете распределение трассировки. Это покажет, как был создан выбранный объект (в значительной степени, как трассировка стека).

Вы, вероятно, увидите HUGH ряд объектов там. Но ваша лучшая ставка состоит в том, чтобы сосредоточиться в тех, которые имеют более длительный жизненный цикл, чем объект, который вы изучаете (ваш вид). То, что я имею в виду, ищите сцену, родительский вид и т. Д.; Объекты, на которых зависит ваш взгляд, а не любов, что зависит от вашего мнения, если это имеет смысл. Если у вашего представления есть кнопка, и вы добавили его слушателю, ваша кнопка будет иметь ref на ваш взгляд. В большинстве случаев это не проблема, поскольку кнопка зависит от вида, и после того, как представление будет собирать, так кнопка. Итак, идея состоит в том, что, поскольку есть много объектов, вы должны попытаться оставаться сосредоточенным, или вы не будете никуда. Этот метод довольно эвристический, но в моем опыте он работает.

Как только вы найдете источник утечки, вернитесь к источнику, измените код соответственно (возможно, это не требует просто меняющегося кода, но немного рефакторинга). Затем повторите процесс и проверьте, вызвало ли ваше изменение желаемого эффекта. Это может занять некоторое время, в зависимости от того, насколько большой или сложный - ваше приложение и сколько вы знаете об этом. Но если вы пойдете пошаговый шаг, нахожу и исправляя одну проблему в то время, вы в конечном итоге избавляетесь от утечек. Или, по крайней мере, худшие и более очевидные. Итак, в то время как немного утомительно, он окупается (и, как приятно в сторону, вы в конечном итоге понимаете, какая пустая трата времени в большинстве случаев использовать слабые Refs для каждого обработчика событий на лице этой земли, уделяя каждый одна переменная и т. Д., И т. Д.; Это просвещающий опыт;).

Надеюсь это поможет.

Answer 2

Flash GC использует смесь отсчета и отсчета и отметки и отметки, поэтому он определяет круговые ссылки. Кажется, скорее у вас есть еще одна ссылка на ваш объект графики. Наиболее распространенным причинами является то, что объекты, которые вы хотите расположен, все еще имеют обработчики событий, зарегистрированные на объектах, которые не расположены. Вы можете попытаться убедиться, что обработчики всегда зарегистрированы со слабой ссылкой. Вы также можете переопределить addeventListener и removeeventlistener во всех (базовых) классах, если это возможно, чтобы посмотреть, какие слушатели зарегистрированы, и есть ли шансы, чтобы некоторые не были удалены.

Кроме того, вы можете писать деструкторы для ваших объектов, что для компонентов пользовательских интерфейсов очистить графику и удалить всех детей и для всех объектов, удаляет ссылки на все свойства. Таким образом, только ваш объект хранится в оперативной памяти, который не должен требовать много памяти (небольшой след от 20 B или около того, плюс 4 b на переменную (8 для числа)).

приговор
back2dos.

Answer 3

Также полезная эвристика для поиска утечек памяти: http://www.tikalk.com/flex/solving-memory-leaks-using-flash-builder-4-Profiler.