0
votes

We have a huge flex applications using multiple modules. There is a huge memory leak problem over prolonged usage of loading and unloading modules.

Based on all the search and different articles I understand that I need to clean up objects on unload, remove event listeners, stop timers and dispose any references.

I started this by picking up one component at a time within one of the module.

Here is how this is structured.

There is one parent application which loads a module, which has multiple views. The component is defined in mxml and is referenced in the mxml module in a view stack.

This mxml component is a VBox with event listeners added as-

<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)" ....

There are couple of properties that are binded from the parent container in mxml. Other than the above listeners there is also a private variable accessed from outside -

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

On unload of the module I call a dispose function in this component as below-

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);

}

Now when I run profiler and switch between modules number of instances of this component still continues to grow. I clicked on GC Collect on profiler and still the instances stay.

On the parent container which is the module mxml, I also tried writing the following lines upon unload of module-

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

Please help. I am not sure what am I missing here, or even if this is the right approach.

Thanks.

3

3 Answers

1
votes

This will not solve your problem but I hope it helps.

  1. First and foremost you are not getting anywhere just by looking and refactoring code. You need hardcore data that proves that you have a leak, which then will tell you what is leaking so you can fix it. From all the memory profilers I've used the FlashBuilder one is still the best, the IntelliJ one was not reliable a year and Adobe Scout only does performance analysis.

  2. Start by your smallest modules and with the memory profiler open prove that opening and closing a module (preferably in isolation of the main rig) creates a leak. If that's the case I would start by removing ALL the code from the module, and testing it again, add part by part which will lead you to the lead eventually. You can use a best suspects search, where you first address event listeners, etc.

  3. This article from Thomas Sugden is still the best I've read about flex memory profiling and you should read it from end to end if you haven't.

  4. It worth your time to write tools that allow you to test your modules, who knows even automate the process that evaluates if there are leaks or not. This is important because sometimes there are leaks that will not be your fault, the Flex framework has a bunch of them that you just can't avoid.

Hope this helped.

0
votes

You might want to try a different container. I've personally had performance issues with VBox. And as the pervious user said, Flex has a habit of waiting until memory reaches high levels before it performs a memory sweep.

0
votes

Flash doesn't always initiate the memory sweeping method, but it only frees null pointers when you are taking up memory excessively, so do mind that hindrance.