Dear reader, this is one of those posts where a lot of readers might be fully educated, however while working with other developers and with various opensource projects, this is an area that repeatedly pops-up as being neglected. Additionally it’s not a topic often seen in books or on the web, especially the popular ActionScript resources, so I feel compelled to begin addressing the topic here. I encourage you to contribute additional points and/or suggestions in the comments.
We constantly deal with object lifetimes when we are developing our applications. Evidence of this is making sure we clear all references to an object so it can be cleaned up by the garbage collector. However object lifetime should play a much bigger role in the design of an application then that, and as a result deserves more attention then it gets. In this article we will look at what object lifetime means on a technical level, and then the role it plays in performance and application design.
Object lifetime is the length of an object’s existence in an application. Technically speaking, from when memory is allocated (reserved) for the object until it is deallocated (freed for re-use). This process is handled for us in ActionScript, but occurs based on our actions. For example when we use the keyword “new” memory is allocated for the object we are creating, and when the garbage collector cleans it up that memory is deallocated.
Based on the previous definition, we can look at our Flash applications in terms of lifetime. The Stage has a lifetime at the application level, meaning it exists as long as the application is running. An array that contains references to all the children in a DisplayObjectContainer has a instance level lifetime, so it will exist as long as the DisplayObjectContainer exists. Other object’s lifetime may be limited to a method call.
Often developers have objects who’s lifetimes are too long. I believe a it stems from a number of places, but based on work with other developers a few key place are:
- the knowledge that object creation is expensive
- a lack of formal programming theory, particularly Design Patterns, which offers tools for dealing with application design
- Insufficient focus on the topic in popular resources
Object creation in ActionScript is expensive, but so is keeping unneeded objects in memory. Managing object lifetimes in an application means creating and destroying objects as needed, allowing us to keep the application running at an optimal speed while using minimum resources.
Take for example a Flash website where all the major sections are created at application initialization. (which puts them all into application level lifetime.) Changing a section simply means changing the visibility property, or adding/removing display objects from the display list. The result is that the entire site is kept in memory all the time, regardless of if the user ever visits each section.
The truth is, that for many Flash sites, “micro sites” for example, you could argue this just doesn’t matter. Doing things differently would result in unnoticeable performance improvements on most modern computers, and the end user would not know the difference. This changes however with one particular changing/new (certainly new growth) market that is going to be huge for Flash, that market is cellphones. Cellphones are now starting to to have full Flash support, and we’re not talking about Flash light, but full Player 10 support. Suddenly that little bit of memory counts for a lot more.
So how else could you construct your site? The simple solution is to construct the sections as the user requests them, and destroy them when they leave them. You’re navigation might be at an application level lifetime, but each page need not be. What about the expense of creating new instances? Changing the section is a limited action, only happening on a user action, so it will not occur at a high rate of speed or necessarily at all, and therefore is not a issue. It becomes cheaper to build on demand and not maintain in memory for reuse. There are several design patterns to assist in the creation of objects, for example the Factory Method.
Looking at another example in a different situation, lets take a general button that offers several methods and properties for styling it, one of which is a label and another is an optional display object to use as an icon. The button uses a TextField object for displaying the label.
A common way of building this button would be to create a TextField in the constructor, add it to the display list, and maintain a reference to it through a private variable for changing the text displayed. The problem with this is that there will be situations where a button has no label, (an empty string), perhaps it’s strictly icon based instead. In this case you still have a TextField object in memory that you are not using, that’s one for each button instance, so potentially lots of them. So our label TextField lifetime should not be the same as our button’s lifetime. When the label is set, the function handling that process should determine if it needs to create, dispose, or update the TextField object. Construction is not a performance issue because likely the label will only be set once, or not at all.
By paying attention to object lifetime in the design/construction of your application, and keeping objects in the proper lifetime scope, you can gain significant performance increases, especially as the application grows in size, or when targeting power limited devices. While this article only looks at specific examples, this is a topic that applies to every piece of you application, and as a result should be fully considered throughout the construction process. I’ll be exploring this topic more in future posts.
additional resources:
Managing Object Lifetimes, by Miško Hevery
ActionScript3 Design Patterns, Bill Sanders & Chandima Cumaranatunge
