CODEWITHSUNDEEP
actionscript-3apache-flexmobileactionscriptflex4.5
Andy
Andy

Reputation: 4675

Flex mobile memory leaks & memory profiling

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:

  1. start the app, take a snapshot
  2. go to child view and come back, then run garbage collection, and take a snapshot.
  3. 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:

Thanks Andy

Upvotes: 1

Views: 812

Answers (1)

Nate
Nate

Reputation: 2881

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

Upvotes: 1

Related Questions