Application Domain and External SWF 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.
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?
For all of you who aren’t sure what class definitions are, remember all the classes that you import on top of the document when writing AS3. You can then instantiate your mx.controls.Button or flash.events.Event in the document. You can then add instances of visual components to the display list (stage).
Now think about your SWF for a minute. When you create a symbol in the library and export it for ActionScript, you’re basically creating a definition in the SWF. That definition will be loaded into some domain and you can instantiate it on the stage.
If you look at the schema, you’ll see all the class definitions in the current domain. When you close the application, all instances will be destroyed, class definitions removed and memory freed. If you decide to load an external SWF, you can choose where to load the definitions: in the same box as Class1 or in its own box.
If you choose to load them in the same box as Class1, what will happen when you decide to unload your SWF? Any instances on that stage are destroyed, any definitions in its box are removed and memory is freed. Oh wait, there were no definitions in its box, so there’s nothing to remove from it. The file is unloaded in any case, but the definitions live on as a parasite in the box of our application. That’s right, a parasite. You can’t target a specific definition to unload. If you want to unload ClassC, you’ll need to unload the whole app (basically just close it). That’s not what you want to do. You want your app to run all day.
What is the solution? Remember there are 2 choices when loading your SWF. What if you want your loaded SWF to keep it’s garbage to itself? Sure.
So instead of loading you SWF into the application’s domain, load it into its own domain. How?
var appDomain:ApplicationDomain = new ApplicationDomain(); var context:LoaderContext = new LoaderContext(false, appDomain); var loader:Loader = new Loader(); loader.load(new URLRequest("myButtons.swf"), context);
We created a new domain and loaded all definitions into it. So now our application has 2 domains: the default one and a new one. You can create as many new domains as you have SWFs to load.
What will happen now if you unload your SWF? All classes are no longer in the same box, and the Loader that loaded our SWF has a reference to our new domain. That means that when you unload your SWF, the domain (box with definitions A, B and C) will be removed and memory freed. Yay!
So what does that all mean? Should we create a new domain for EVERY file that we load? Sure you can. But you shouldn’t. There are some nice functions such as getDefinitionByName() that I want to be able to use without searching for the domain in which my definition is contained. If I have a mini-game that requires 20 SWF files, searching for that little symbol in all these domains can be painful. I would rather create 1 new domain (say domainA) and load all 20 SWFs into it. Then I can access my symbol definition from domainA, and unload this domain when no longer needed. For a second mini-game, I’ll create domainB. The idea is not to stick everything into the application’s domain.
Please tell me if this post helped you with your memory usage. Also, feel free to add to my explanation if I missed something.