Squeeze some extra frames per second out of your app with some basic optimizations. In many cases your target device will have a 1Ghz processor and less then 100Mb of available ram. Trying to utilize more processing power or RAM than this will lead to erratic app behavior and in many cases will cause the application to crash.

Blitting – Moving Bitmaps

Attempting to move display objects around during transitions can be very slow and choppy. Moving Bitmaps is much faster and can provide a smooth animation. When using this technique there are two things to consider; speed and memory.

Creating BitmapData from a DisplayObject is CPU intensive. Your user will notice even a fraction of a second delay in a transition. One solution to this is to predict where the user will go and store the BitmapData up front. For example, you know the first page they will hit after the splash screen is the login page. While the user is on the splash screen take a snap shot of the login page. Once they’ve arrive at a new view, take a snap shot of the previous and next views.

BitmapData is expensive. Caching to much BitmapData is the fastest way to slow down and crash your app. Make sure to call destroy on any unused BitmapData or re-use the same two or three instances. Another technique is to use a matrix to take a picture of the screen at half the resolution. You save both processing power and memory when doing this. During transitions on a device with high DPI this is often un-noticed by the user.

How much memory are you using? Use the profiler in Flash Builder to check for leaks and check out Memory Doctor on the iOS store. Version 5 of iOS is said to include app memory monitoring as well.

More information on blitting can be found on Jesse Freeman’s blog: http://flash.developerartofwar.com/


There are plenty of sites that explain the precise difference between these two rendering modes. In the end how should you decide? Guess and check. With AIR 2.7 increasing the performance of CPU on iOS by 4 times, I’ve found that many of my apps perform better and use less memory with CPU.

Run your app with one than check the other. I found that before 2.7, my app ran better with CPU mode for Android and Blackberry but faster in GPU mode on iOS. Now that 2.7 is out, it runs better with CPU on all three. Selecting GPU mode can cause the application to consume as much as twice the memory. My app used 100Mb of memory in GPU mode and only 56Mb in CPU mode.

Avoid Transparency Like the Plague

Changing the alpha on display objects will significantly cut the performance of your app. Keep everything at 100% alpha and minimize the number of transparent PNGs you use. Similar to alpha, adding filters to your display objects will also decrease performance and increase memory usage. Is that drop shadow, beveled, semi-transparent text really worth it?

Destroy Your Display Objects

This part gets complicated. It can be beneficial to re-use display objects rather than re-creating them, for example in a list control. One thing to keep in mind is that these controls consume lots of memory. Keeping a ScrollPane, List, Grid and Picker around in memory all at once will crash your app. Re-use instances when possible but never keep around expensive components when your done with them.

There are plenty more optimizations that you can make in the world of mobile. The list above is what got me through my latest app for a client. Flex Hero handles some of the transitions and memory management for you and with AIR 2.7 it performs quite well. Please post any additional optimizations you’ve found helpful when building mobile apps with AIR.

One thought on “Mobile Optimizations with Adobe AIR

Comments are closed.