Anna Filina

I had an interesting Flex bug to solve a day before the project deadline. I was showing a progress bar while some images were preloading in the background. The application was only allowed to fire applicationComplete event once these images have finished loading.

The client complained that the progress bar stalls the first time you run the app in the browser. Refreshing the page causes the application to start immediately, as if everything has been loaded. I reproduced the bug with bandwidth throttling. That made me think: “the assets are being fully loaded, but the progress bar doesn’t seem to care”.

With further investigation, I realized that I solved the same problem over a year ago. When one creates Loaders on the fly, such as in a loop, one often does not keep any reference to these Loaders outside of the scope of the function. Since it is a good habit to make event listeners weak, it is possible for the garbage collector to flag these Loaders for removal before they even have a chance to fire their complete event.

So to make sure that the progress bar does not stall, I needed to keep a reference to the Loader that I create within my loop. I simply pushed every Loader to an array. Once everything finished loading and the application started, I cleared the array to allow the garbage collector to take care of the rest.

Problem

Progress bar stalls while preloading images.

Cause

Loaders with weak event listeners and no references to them within the application.

Solution

Use an array to store references to the Loaders until all of them have finished loading.

Why do we care about application domains? I worked on a project that required me to load and unload SWF files into a bigger application (loading mini-games into a virtual world). Every time I loaded a mini-game, it would never unload when I exited it. That will keep accumulating until the app slows down to a crawl and crash because we’re out of memory.

The application domain and definition loading is one of the things that is not documented in a way the common mortal can understand. By popular demand, I will attempt to explain it the way I understand it. I will provide some examples along the way. Before I continue, here is a link to the official documentation on ApplicationDomain.

I will explain class definitions and domains, and then tell you what you can do to properly unload your movies and assets.

Class Definitions

Everything that you load has to be stored somewhere. It’s easy to understand the visual elements because you can just stick them on the stage. But what about class definitions?

Read more…

An object that has no references to it will be eventually garbage-collected. An event listener is also a reference, thus preventing it from being removed from memory.

In order to allow your objects to be garbage-collected, you can either remove all listeners from it or use weak event listeners instead (don’t forget to remove other references to it as well). To make a listener weak, you must set the 5th parameter of the addEventListener method to true, like this:

var btn:Button = new Button();
btn.addEventListener(MouseEvent.CLICK, clickHandler, false, 0, true);

But you have to be very careful where you use weak event listeners. When you instantiate an object in a function’s scope and then add weak event listeners, your object could be garbage-collected before it had a chance to dispatch these events. Example:

private function getStuff():void {
    var service:HTTPService = new HTTPService();
    service.url = "get-stuff.php";
    service.addEventListener(ResultEvent.RESULT, resultHandler, false, 0, true);
}

In this case, you should either avoid using weak listeners and remove them manually, or add a reference to your object outside of the function’s scope to prevent it from being garbage-collected too early.

I ran some performance tests today. I made an interesting discovery. When you load a SWF that has elements exported for ActionScript, the class definitions of these elements are stored in the application’s domain and take up memory (we already knew that). But whether you load these definitions into the SWF’s context or your main application’s context will determine whether that memory is ever released.

I tried loading SWFs using the Loader class and unloading them immediately after the load completes. These SWFs contained symbols that were exported for ActionScript (linkage). When providing a LoaderContext with its applicationDomain property set to ApplicationDomain.currentDomain, even if you unload the SWF, memory of that symbol definition is never released. However, if you do not provide one, when you unload the SWF, memory is released.

Conclusion: if you are to use linked library symbols in your projects, avoid loading it in the application’s domain for performance reasons. In one of my projects, I used it intensely and my application lagged and crashed after a few hours of use (could be much less depending on the size of the symbols that you have).