So the more you work with ActionScript 3 and especially when it comes to building RIA’s (Rich Internet Applications) or games, the more garbage collection will become really important. When I first started down the road of memory management and garbage collection there were a lot of things that were very confusing. This post is to share the things that I’ve learned and hopefully help others avoid much of the confusion. The first thing to know is as of right now there is no real way of triggering a garbage collection pass on demand, but there are some good practices to follow that will ensure that objects are flagged to be collected. The first thing to be aware of is that if you are not using the Premium version of Flash Builder to profile your swf file you are going to have a difficult time knowing if it’s cleaning itself up properly. There are some other tools out there to help with this, but as off the time I wrote this Flash Builder Premium is by far the best. One tool to keep in eye on though that looks very promising is called project monocle. Do a Google search for it. Covering how to profile a swf is a little beyond the scope of this post, but when you’re writing your code here are the things I’ve found that you want to look for.
- Remove all event listeners.
It’s good practice to use weak referencing when adding listeners. To do this set the last parameter in the addEventListener function to true. Doing that is not a guarantee though so remember to always remove listeners. - Set all complex data types and any other object that contains a reference to another object such as Arrays and vectors to null.
Although you can’t call the garbage collector on demand, this is the best way to ensure that an object is marked for collection on the next pass(as long as listeners are remove prior). - Stop and nullify all timer and loader variables.
Timers and loaders are notorious for hanging out in memory so make sure you watch them carefully. - Ensure that all display objects are off of the display list before trying to destroy them.
It’s rare, but there have been times when I’ve had to manually remove children from a parent before destroying the parent. - Start a habit of good coding practices that works for you.
So after you know what types of things to look for in your code that can lead to memory leaks, start making some habits to help you avoid those things. One thing that I’ve found helpful is to create a “destroy” or “cleanup” function for every class. Another thing that I’ve started doing that is very helpful is to make “create” and “destroy” functions for every complex object that I instantiate. So for example say that you were making a game that had a hero class, the two methods would be “createHero” and “destroyHero”. In those functions is where the object is created/destroyed(null) and where listeners are added and removed. Then you would have one public function that when it comes time to do the overall cleanup would call all of the destroy functions for the different objects. You can download a sample AS file that illustrates how to do this.
Memory management is very important in polishing any game or project. I hope this helps.