2013-09-11 6 views
0

У нас есть огромные гибкие приложения, использующие несколько модулей. Существует огромная проблема с утечкой памяти при длительном использовании модулей погрузки и разгрузки.Flex 3 Проблема с утечкой памяти

Основываясь на результатах поиска и разных статьях, я понимаю, что мне нужно очищать объекты при выгрузке, удалять прослушиватели событий, останавливать таймеры и устанавливать любые ссылки.

Я начал это, набрав один компонент за один раз в одном из модулей.

Вот как это структурировано.

Существует одно родительское приложение, которое загружает модуль, который имеет несколько видов. Компонент определяется в mxml и упоминается в модуле mxml в стеке представлений.

Этот MXML компонент является VBox со слушателями событий добавил как-

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" 
     paddingTop="10" 
     paddingLeft="10" 
     paddingBottom="10" 
     paddingRight="10" 
     creationComplete="onInit()" 
     show="onShow()" 
     resize="onResize(event)" .... 

Есть несколько свойств, которые переплетены из родительского контейнера в MXML. Помимо вышеуказанных слушателей есть также собственная переменная доступна извне -

[Bindable] 
private var _model:SModelLocator=SModelLocator.GetInstance(); 

На выгрузке модуля ввода вызова функции Dispose в этом компоненте, как

ценам ниже
public function dispose():void 
{ 
    this.removeEventListener(FlexEvent.CREATION_COMPLETE,onInit); 
    this.removeEventListener(FlexEvent.SHOW,onShow); 
    this.removeEventListener(ResizeEvent.RESIZE,onResize); 

    var arr:Array = this.getChildren(); 
    for(var i:int = 0; i<arr.length;i++) 
     delete arr[i]; 
    this.removeAllChildren(); 

    _model = null; 

    //Properties that are binded from the parent container 
    Property1 = null; 
    Property2 = null;    

    this.deleteReferenceOnParentDocument(this.parentDocument as IFlexDisplayObject); 

} 

Теперь, когда я запускаю профайлер и переключаться между модулями число экземпляров этого компонента продолжает расти. Я нажал на GC Collect на профилировщике, и все еще остается.

На родительском контейнере, который является модуль MXML, я также попробовал писать следующие строки после выгрузки модульно

//function call to invoke dispose as above 
component1.dispose(); 
component1 = null; 

Пожалуйста, помогите. Я не уверен, что мне здесь не хватает, или даже если это правильный подход.

Спасибо.

ответ

1

Это не решит вашу проблему, но я надеюсь, что это поможет.

  1. Прежде всего, вы ничего не получаете, просто просматривая и рефакторинг кода. Вам нужны хардкорные данные, которые доказывают, что у вас есть утечка, которая затем сообщит вам, что происходит, чтобы вы могли исправить это. Из всех профилей памяти, которые я использовал FlashBuilder, все еще лучше, IntelliJ не был надежным в год, а Adobe Scout только анализирует производительность.

  2. Начните с самых маленьких модулей и с открытым профайлером памяти убедитесь, что открытие и закрытие модуля (предпочтительно в изоляции от основной установки) создает утечку. Если это так, я бы начал, удалив ВСЕ код из модуля и снова проверив его, добавьте часть по частям, которая в конечном итоге приведет вас к лидерству. Вы можете использовать поиск лучших подозреваемых, где вы впервые обратились к слушателям событий и т. Д.

  3. Этот article from Thomas Sugden по-прежнему является лучшим, что я прочитал о профилировании гибких дисков, и вы должны прочитать его из конца в конец, если у вас нет ,

  4. Стоит ваше время, чтобы написать инструменты, которые позволяют вам тестировать ваши модули, кто знает даже автоматизировать процесс, который оценивает наличие утечек или нет. Это важно, потому что иногда есть утечки, которые не будут вашей ошибкой, инфраструктура Flex имеет кучу из них, чего вы просто не можете избежать.

Надеюсь, это помогло.

+0

Спасибо за помощь. Вот что я сделал. 1. Да, я использую профилировщик adobe, чтобы увидеть, что я получаю утечку памяти. Это подтверждается, и load-unload увеличивает количество экземпляров компонентов. 2. Я попробую сделать этот шаг. Однако это долгий процесс, но я думаю, что нужно сделать. 3. Спасибо, я буду следовать этой статье. 4. Безусловно, следующие шаги в будущем. Но сейчас я должен найти краткосрочное решение. Я отправлю обратно то, что я нахожу. Спасибо – Nikhil

+0

утечка памяти и краткосрочное решение в flex не входят в одно и то же предложение, извините, но я могу говорить из опыта. Возможно, вы можете убить большого преступника, используя стратегию удаления всего кода и оттуда. – bitoiu

0

Вспышка не всегда замалчивает метод подметания памяти, это только свободные нулевые указатели, когда вы занимаете память чрезмерно, поэтому не обращайте на это внимание.

0

Возможно, вы захотите попробовать другой контейнер. У меня лично были проблемы с производительностью с VBox. И, как сказал опытный пользователь, у Flex есть привычка ждать, пока память не достигнет высоких уровней, прежде чем она начнет прокрутку памяти.