Flash Builder Profiler – Fixing Memory Leak on ExternalInterface


One of the most common problems with Flash applications are memory leaks, programming flaws that cause Flash Player to loose access to memory that it could recycle otherwise.  In the mobile space it’s crucial to understand memory management to get the most out of the Flash Player, and ultimately to ensure a smooth ride for your consumers.

Flash Player memory management

Flash Player makes use of automatic memory management, to help you to create applications with ease and with less code. In fact the Flash Player uses a pretty simple mechanism that determines how many times you have referenced a particular object. Once an object has nothing referencing it then it can be garbage collected – predictably it’s called “reference counting”.

The following is a great example of reference counting in action, notice that I have created a Geolocation object (geo) and added updateHandler as a listener function for update events.  This counts as a reference against updateHandler:

var geo:Geolocation = new Geolocation();
geo.addEventListener(GeolocationEvent.UPDATE, updateHandler);

function updateHandler(event:GeolocationEvent):void
{
geo=null;
trace(event.longitude);
}

The updateHandler function marks the geo object null, tagging it for deletion by the garbage collector which is great.  The problem is that the geo object still has a reference to updateHandler, and therefore the geo object cannot be deleted until we remove the listener and free the reference up.

function updateHandler(event:GeolocationEvent):void
{
geo.removeEventListener(GeolocationEvent.UPDATE, updateHandler);
geo=null;
trace(event.longitude);
}

Memory leaks are easy to create in Flash, and even harder to debug later.  It’s therefore essential to build your applications with memory in mind and use all tools at your disposal to keep checking for leaks, slow performance, and run away code.

Flash Builder Profiler

Flash Builder 4 ships with a new feature called the Profiler and in the video below I’ll show you how to use it to solve a memory leak.  Now don’t be fooled, this memory leak took a few hours to solve in reality – these aren’t easy problems to solve.

In fact I found two memory leaks, the first is the ExternalInterface.addCallback holding onto a function reference.  The other is more complex, and I have marked it “Flash Player Bug” as I believe this is a problem with the runtime itself.

, , ,

  • http://flashstockfiles.com/news/flash-builder-profiler-%e2%80%93-fixing-memory-leak-on-externalinterface/ Flash Builder Profiler – Fixing Memory Leak on ExternalInterface | Flash Stock Files

    [...] Visit link [...]

  • http://www.jolyonruss.co.uk Jolyon

    I always thought that by passing the fifth parameter of addEventListener as true (use weak reference) you to some degree negated the need to clean up after yourself so much.

    Any thoughts on that?

  • http://www.flashmobileblog.com Mark Doherty

    That’s correct, there are two ways to go about it. I’m not sure if I recommend the weak reference path as it separates the developer from keeping track of things themselves.

    Notice that the bug I found suggests that references are being counted when they shouldn’t in the player :-)

  • http://twitter.com/jpauclair jean-philippe

    There is a free open-source alternative to FlashBuilder Profiler
    It’s called FlashPreloadProfiler.
    Try it at http://jpauclair.net/flashpreloadprofiler/