Another session on optimizing Air applications, but for which the tips often apply to Flex apps in a browser as well.
Split heavy loads across frames to remain responsive
Don’t do rendering in a timer. It will occur multiple times within a frame, having no effect
Strongly type your objects so that the VM doesn’t have to do a lot of checking at run time
Coding with JIT-awareness
Constructors are always interpolated (never compiled)
Don’t put heavy code into constructors
Primitives offer more bang for the buck, use them whenever possible
Bytearrays allow for faster access of primitives than arrays.
Air 1.5 has a vectorarray that you can use instead
Regex is an order of magnitude slower than string functions for searching
AMF processed on the main thread cannot be processed over frames
Avoid databinding on data transfer objects or AMF objects
Avoid unnecessary parenting
Follow the Flex component model
Only use a datagrid as a last resort
Try to use a list instead
A datagrid uses a displayobject for every single cell it displays
Avoid using repeaters for a cursor
Memory tips for AIR
17 m of memory to launch 1 window
Every additional window adds 4 bytes for each pixel
Assume 4k of memory for every displayObject
Air will lazy load modules, but doesn’t unload them until the application quits
The biggest impact on memory is the number of displayObjects used
Profiler built into Flex only shows the amount of memory used by the Flex VM. You need to use other tools to see total impact.
Use disk space or SQL Lite to avoid reduce app memory impact for data
Reuse objects – particularly dataObjects, URL Loaders, etc
Use large single objects rather than multiple smaller objects (fills memory better)
Flash and Air use a mark and sweep garbage collection
You can call garbage collection manually from Air (but not in Flash).
Make sure you clean up asynchronous objects directly (timer, ULR loader, etc).
Nulling them doesn’t unhook them from the flash player.
Memory fragmentation is pretty significant in Air, event in 1.5 (they are working on it for 2.0).
When you request a page and start filling it, it won’t be available to be returned to the O/S until every object on it is removed.
Even if you call garbage collect, the memory won’t be released because of other objects on the page.
Air can be unreliable at unloading WebKit
Keep your frame rate at 60 frames per second or less. Setting it higher has no effect, because the vast majority of video monitors operate at 60 frames per second or less. Some operating system (e.g. Mac) restrict the frame rate below what the display runs at.
Avoid multiple display manipulations per frame.
Try to use creationPolicy = queued in order to defer object creation across frames
Rendring is done in three steps: Layout, Rasterization, Compositing
Calculation of positions and sizes
Determine parent/child relationships
Determine what is in view and then pass that off to Rasterization
Create vector objects for each object
Objects that are marked invisible are skipped
Aggregates objects to form images
When you mark something as cache as bitmap, this is the only place you see the benefit
A change in that setting may not help, it may actually hurt
DrawBitmap is a way to save composites for later use
Drawing to a single graphic layer allows you to bypass compositing
Bitmaps or Vector Graphics
Bitmaps are constant load times / Vectors can vary
Bitmaps use more memory
Bitmaps allow for post processing
Vectors look better when scaling, rotating, etc.
Create displayObjects ahead of time
Use scrollRects rather than Masks
Mac versus PC
10% penalty on PCs, comes free on Mac
PCs process more per second
Windows apps live and die by whether their main window is showing
Mac apps can continue to live in the doc after their main window is gone