Flex mobile memory leaks & memory profiling

Question

I've been trying to profile my flex mobile application for memory leaks and I get very unexplainable results so i decided to do the most basic test imaginable to see if flex memory management is reliable.

FirstView.mxml

<?xml version="1.0" encoding="utf-8"?>
    <s:View 
        xmlns:fx="http://ns.adobe.com/mxml/2009" 
        xmlns:s="library://ns.adobe.com/flex/spark" 
        title="FirstView"
        >

        <s:Button
            label="Go to child"
            click="navigator.pushView(ChildView)"
            />

</s:View>

ChildView.mxml

<?xml version="1.0" encoding="utf-8"?>
    <s:View 
        xmlns:fx="http://ns.adobe.com/mxml/2009" 
        xmlns:s="library://ns.adobe.com/flex/spark" 
        title="ChildView"
        >

        <s:Button
            label="Back to home"
            click="navigator.popView()"
            />

</s:View>

That's it. It can't get any simpler.

So if you try to profile this with the memory profiler do this:

start the app, take a snapshot
go to child view and come back, then run garbage collection, and take a snapshot.
repeat step 2 a few times

Now go and try a "find loitering objects" on any two snapshots and you find more than 100 objects "loitering" after returning to the first view and everything in the childview should have been destroyed. It's really discouraging because there is no conceivable way to make this simpler or "cleaner" in terms of memory management.

Can anyone shed any light on why these objects are getting created and never getting thrown out? Also, any tips on getting a really clean view-based mobile app that really removes all memory related to a destroyed view would be great.

So far I have:

always add weak event listeners
set variables to null when closing view ( and remove event listeners)

Thanks Andy

What are those 100 objects that are loitering? Are they objects explicitly created for use in the child view? Or just pieces of the Flex Framework? — JeffryHouser

Nate Nate · Accepted Answer · 2012-06-26T03:14:26

First, you aren't destroying any objects in your example - thus no pointer references have been removed in order for garbage collection to grab them.

Secondly, it's not technically a memory leak unless your application continues to grasp more memory unnecessarily. As far as I can tell, it doesn't create a bunch of new objects each time the views are pushed, rather it hits a limit and thats it.

I don't see the memory constantly growing, I don't think because you have 100 objects hanging around you have a memory leak. Now, if you gained 100 objects each time you pushed a view, THAT would definitely be a memory leak.

Let me know if you're seeing something different on your end. :)

Flex mobile memory leaks & memory profiling

1 Answers