One of the most problematic and discussed area in Flex development is garbage collection and memory optimization. Even with new tools added to Flex Builder (now Flash Builder) like Profiling, struggling to obtain a memory clear application is not easy. One of the methods is the undocumented hack with LocalConnection
where you connect two of them and do nothing at all after.
1 2 3 4 5 6 7 8 9 | try { var lc1:LocalConnection = new LocalConnection(); var lc2:LocalConnection = new LocalConnection(); lc1.connect( "gcConnection" ); lc2.connect( "gcConnection" ); } catch (e:Error) {} |
This will trigger the internal garbage collection and clear everything that is decoupled from application.
But doing just this doesn’t mean your code will work as expected. The whole architecture needs to be ruled out with GC in mind and here is where the Flex 4 framework came in big help. Offering methods like partAdded() and partRemoved() to skinnable components is a path that assures every listener added to skin parts is removed in partRemoved(). This means if you show/hide some parts without removing the whole component from stage, all you need to do is call partRemoved() and partAdded() on the part you need to garbage collect. Make sure you call theese methods only if the part exists first as the first partAdded() is called from withing the component. This technique applies mostly to DataGroup where itemRenderers are used and bound with data that might have a longer lifespan than the renderer itself. Another critical time where some extra logic for memory should be added is when renderer is removed from stage, aka when “data” property is set to null. Here is where you might want to call detachSkin() to make sure all parts are decouples from the external resources and available for garbage collection.
Another handy method relates to images, components that are very problematic when comes to garbage collecting, where there is a new functionality inserted in Flash Player 10. SWFLoader has an unloadAndStop method that takes “invokeGarbageCollector” as a param which eventually result in calling “unloadAndStop” method available in Flash Player 10.
Working on a data intensive project in Flex 4 i’ve noticed that the framework better supports memory optimization that it did before so kudos for SDK guys. Will get back here with any interesting idea related to garbage collector in Flex 4 and where is the next critical place where you need to do extra work for it.


2 Comments to 'Flex 4 Memory Optimizations'
June 29, 2009
[...] One of the most problematic and discussed area in Flex development is garbage collection and memory optimization. Even with new tools added to Flex Builder (now Flash Builder) like Profiling, struggling to obtain a memory clear … The rest is here: Flex 4 Memory Optimizations | Ayone Blog [...]
July 5, 2009
Perfect!
Leave a comment