Optimizing Flex Apps
Notes:
- Flash Player 9 internal lifecycle: rendering, excute actionscript code, networking, repeat
- writing crappy AS code can starve rendering
- deferred creation
- several container components support a creation policy which should be used if possible, such as Accordian, TabNavigator, ViewStack, etc
- this allows items that are not yet viewablle to defer creation
- you can implement deferred creation in your own custom containers, but better to just extend ViewStack
- constraint layouts can be slow with lots of nested containers
- reduce container nesting when possible
- if you are loading lots of images, do it smartly
- each one's load complete will cause a re-layout process
- better to load them all off the display list, then, when all loaded, add them to display list
- use cacheAsBitmap for effects that don't change size
- this renders the component to an offscreen buffer and fast draws the buffer to the display
- MoveEffect - good use for cacheAsBitmap
- Resize - bad use for cacheAsBitmap
- use Resize.hideChildren to hide children during state transitions when possible (e.g. resize a grid you could hide the item renderers with this, but that would leave a blank grid in meantime)
- setStyle is expensive, except during object creation time
- using performance profile in Flex Builder 3:
- start app via profiler
- uncheck memory profiling if not using it
- once you get to the point in your app you want to profile, clear the results
- do the action you are profiling
- take a snapshot
- you can now drill down each method, and each method it called to see performance breakdowns
Case Study
- List itemRenderers that were doing lots of changes to the list
- initially wrote renderer as a VBox with other containers inside to positon label
- rewriting as a simple AS class that andled the layout very simply drastically improved performance of all the dynamic updates going on to the list
- Flash Player 9 internal lifecycle: rendering, excute actionscript code, networking, repeat
- writing crappy AS code can starve rendering
- deferred creation
- several container components support a creation policy which should be used if possible, such as Accordian, TabNavigator, ViewStack, etc
- this allows items that are not yet viewablle to defer creation
- you can implement deferred creation in your own custom containers, but better to just extend ViewStack
- constraint layouts can be slow with lots of nested containers
- reduce container nesting when possible
- if you are loading lots of images, do it smartly
- each one's load complete will cause a re-layout process
- better to load them all off the display list, then, when all loaded, add them to display list
- use cacheAsBitmap for effects that don't change size
- this renders the component to an offscreen buffer and fast draws the buffer to the display
- MoveEffect - good use for cacheAsBitmap
- Resize - bad use for cacheAsBitmap
- use Resize.hideChildren to hide children during state transitions when possible (e.g. resize a grid you could hide the item renderers with this, but that would leave a blank grid in meantime)
- setStyle is expensive, except during object creation time
- using performance profile in Flex Builder 3:
- start app via profiler
- uncheck memory profiling if not using it
- once you get to the point in your app you want to profile, clear the results
- do the action you are profiling
- take a snapshot
- you can now drill down each method, and each method it called to see performance breakdowns
Case Study
- List itemRenderers that were doing lots of changes to the list
- initially wrote renderer as a VBox with other containers inside to positon label
- rewriting as a simple AS class that andled the layout very simply drastically improved performance of all the dynamic updates going on to the list

Comments