Optimizing Adobe Air for Code Execution

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

Layout
Calculation of positions and sizes
Determine parent/child relationships
Determine what is in view and then pass that off to Rasterization

Rasterization
Create vector objects for each object
Objects that are marked invisible are skipped

Compositing
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.

Additional Tips
Create displayObjects ahead of time
Use scrollRects rather than Masks

Mac versus PC
Window Transparancy
10% penalty on PCs, comes free on Mac
Event Loops
PCs process more per second
Windowing architecture
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