>
Resource Management in Actionscript 3
Welcome, Guest

by pooja on Saturday, 29 May 2010
Resource Management in Actionscript 3


ActionScript 3 has empowered Flash developers with faster code execution and a ton of API enhancements. Unfortunately, it has also led to the need for a much higher level of developer responsibility than ever before. The biggest change in AS3 that affects resource management is the new display list model. In Flash Player 8 and below, when a display object was removed from the screen (with removeMovie or unloadMovie), it and all of its descendants were immediately removed from memory, and halted all code execution. Flash Player 9 introduces a much more flexible display list model, where display objects (Sprites, MovieClips, etc) are treated the same as normal objects. This means that developers can now do really cool things like reparenting (moving a DO from one display list to another), and instantiating display objects from loaded SWFs. Unfortunately, it also means that display objects are now treated the same as every other object by the Garbage Collector, which raises a whole slew of interesting (and possibly non-obvious) issues.


Issue 1: Dynamic Content

One of the more obvious issues is related to Sprites (or other DOs) that you instantiate dynamically, then wish to remove at a later time. Because display object's no longer live and die on the display list, when you remove the object from the stage it continues to exist in memory. If you have not cleaned up all other references to the clip, including the object's listeners, it may never be removed. If you have done a good job of cleaning up all references, the clip will be removed from memory the next time the GC runs a sweep, which is at some indeterminate point in the future based loosely on memory usage.

It is very important to note that not only will the display object continue to use memory, it will also continue to execute any "idle" code, such as Timers, enterFrames, and listeners outside its scope. A couple of examples may help illustrate this issue:

   1. You have a game sprite that subscribes to its own enterFrame event. Every frame it moves and carries out some calculations to determine it's proximity to other game elements. In AS3, even after you remove it from the display list and null all references to it, it will continue to run that code every frame until it is removed by garbage collection. You must remember to explicitly remove the enterFrame listener when the sprite is removed.

   2. Consider a MovieClip that follows the mouse by subscribing to the stage's mouseMove event (which is the only way to achieve this effect in the new event model). Unless you remember to remove the listener, the clip will continue to execute code every time the mouse is moved, even after the clip is "deleted". By default, the clip will execute forever, as a reference to it exists from the stage for event dispatch.

Now imagine the implications of instantiating and removing a bunch of sprites before the GC does a sweep, or if you failed to remove all references. You could inadvertently max out the CPU fairly easily, slowing your application or game to a crawl, or even stalling the users' computers entirely. There is NO WAY to force the Flash Player to kill a display object and stop it executing. You must do this manually when it is removed from the display.


Issue 2: Loaded Content

If you consider that the contents of loaded SWFs are also now treated the same as every other object, it is easy to imagine some of the problems that you can encounter with loaded content. Just as with other display objects, there is no way to explicitly remove a loaded SWF and its contents from memory, or to stop it from executing. Calling Loader.unload simply nulls the loader's reference to the SWF, it still has to be picked up by a GC sweep (assuming all other references to it have been properly cleared).

Consider the following two scenarios:

   1. You build a shell that loads your experimental Flash pieces. This experimental work is cutting edge, and pushes the CPU to the limits. A user clicks a button to load one experiment, views it, then clicks a button to load a second experiment. Even if all references are cleared to the first experiment, it will continue to run in the background, which will likely max the processor out when the second experiment starts running at the same time.

   2. A client commissions you to build an application that loads AS3 SWFs created by other developers. These developers add listeners to the stage, or otherwise create external references to their own content. You now have no way of unloading their content, it will live in memory, and consume CPU until the user quits your application. Even if their content does not have any external references, it will continue to execute indefinitely until the next garbage collection sweep.

For security sensitive projects, it is very important to understand that if you load third party content, you have no way of controlling when it is unloaded, or what it executes. It would be VERY easy to write a SWF that once loaded into your application continued to execute in the background and captured / transmitted user input / interactions, even after being unloaded.


Issue 3: The Timeline

This one is mostly an issue for those playing with Flash 9 public alpha, and it is important to remember that it is alpha. Hopefully this gets resolved before beta or final.

The timeline in AS3 is code driven. It dynamically instantiates and removes display objects as the playhead moves. This means it is subject to the same problems as those listed in issue 1. Clips that are removed from the screen due to timeline updates will remain in memory, and continue to execute any idle code on them until they are picked up by the GC. Not really expected behaviour for Flash developers, and certainly not for Flash designers (who shouldn't have to think about GC at all).


Summary

Flash developers are not used to having to do manual resource management beyond basic best practices (ex. kill references when you're done), whereas Java developers have been through all this before. These issues are par for the course for most modern memory managed languages, and unfortunately there is no way to completely avoid them.

On the other hand, Flash raises a lot of challenges that are rare in other languages (including Flex for the most part). Flash content tends to have a lot of idle / reactive code execution, whereas Java and Flex are mostly interactive (ie. CPU intensive code usually only executes based on a user interaction). Flash projects load external content from third party sources (possibly with poor coding standards) far more often as well. Flash developers also have fewer tools, profilers and frameworks to utilize.

Resource management is going to be an important part of AS3 development. Ignoring the issue could result in sluggish content, and potentially stalling users' systems completely. There is no longer any way to explicitly remove a display object from memory and stop its code from executing, which means we have a responsibility to clean up properly after our objects.

 

 



Blogger Image
My Blog Title

Product Engineering, software engineering company, Product Development, Product Migration, Product Re-engineering, Product Maintenance, Product Testing Commercial Application Development, Business Software development, commercial software for startups, Application Support and Maintenance, software testing Product Maintenance, Outsource product maintenance, product support and maintenance Product Migration, Product Re-engineering, product re-engineering services Product Research, Product Engineering, UI Prototyping Services Software Testing Services, Quality Assurance services, professional software testers, Load Testing, Functional Testing, Cross Platform, Browser Testing, Test Automation, Testing Tools, software quality analysis Functional Testing Services, software quality analysis, Software Testing Services, Application Testing Services, Functional Testing Types Automated Testing, Automated Testing Services, automation testing, test script development, Automation Test Tools, outsource automation testing Load Testing, Performance Testing Services, Load Testing Tools Offshore Software Development, Outsource software services, offshore outsourcing services, offshore software development services, IT outsourcing services, software quality assurance services, Offshore IT services, Custom Application Development Services, Offshore Product Engineering Benefits of IT Outsourcing, Offshore Software Development companies, offshore software development firms Outsource planning, IT outsourcing, IT development services, offshore IT companies, offshore software development Offshore Software Development, Outsource software services, offshore outsourcing services, offshore software development services, IT outsourcing services, software quality assurance services, Offshore IT services, Custom Application Development Services, Offshore Product Engineering Offshore Software Development, Outsource software services, offshore outsourcing services, offshore software development services, IT outsourcing services, software quality assurance services, Offshore IT services, Custom Application Development Services, Offshore Product Engineering