Optimizing performance for mobile AIR applications by Jun Chen

Have you ever wondered why console games with lower available CPU cycles, like the earlier versions of Sony PlayStation (PS1 ~33 MHz, PS2 ~300 MHz) perform much better than some Flash games on desktop or mobile devices with 600 MHz to over 1 GHz? It's not a fair comparison to evaluate the platforms based on CPU cycles alone because there are significant differences in both hardware and software when delivering games on different platforms. To get the optimal performance with any computer or device, it is important to maximize the hardware capabilities as well as implementing software development best practices. In this article, I'll describe development practices that help improve performance of mobile AIR apps.

Improving performance by updating the AIR SDK

The fastest way to optimize performance and fix bugs that may be slowing down mobile apps involves updating your AIR SDK. Unfortunately, there isn't an .exe or .app installer that will facilitate this for you. However, you can follow the two-step process outlined below to update your AIR SDK quickly and easily:

Step 1

Download and unzip the newest AIR SDK into the application folder FlashProCS5.5/AIR2.6/, replacing the contents. Don't worry about renaming any of the folders.

Step 2

Copy the file ../frameworks/libs/air/airglobal.swc from the unzipped AIR SDK and replace the older one in your FlashProCS5.5 install folder ../Common/Configuration/ActionScript 3.0/AIR2.6/
Going forward, just ignore the fact that items will be labeled as AIR2.6. Although you've not updated the folder name or paths, you can be confident that your SDK has been updated to use the newer version. Although you could change the string to match the SDK version number by updating an XML file somewhere in Flash Professional, it is not necessary.

Applying manual garbage collection

The term manual garbage collection doesn't refer to triggering the automatic garbage collection that it runs in the background in Flash Professional from time to time. Instead, I'm suggesting that when you program mobile apps, you have to take care to clean up your own mess. Every class you create should include a cleanUp function that removes its own listeners, timers, loaders, and unused movie clips when they are no longer needed. To keep things simple, here are two different ways to apply garbage collection to your code:

Method 1

If your class is able to detect when its usefulness ends, then call its custom cleanUp() function. For example, let's say your game has many ball instances flying across the screen from right to left. You know that once the ball is no longer visible on the screen (x < 0), the ball is no longer useful. If that is the case, you can call cleanUp() whenever that happens.

Method 2

Sometimes it is more efficient to create a single timer that will detect whether or not individual instances in a batch of objects are still useful. This approach can save CPU cycles by using a much bigger delay in your timer. For example, you can set up a function that checks for usefulness of objects every two seconds instead of every 100 milliseconds.
Here's an example of a cleanUp function:

public function cleanUp(){ removeEventListener(MouseEvent.ROLL_OVER, meRollOver); removeEventListener(MouseEvent.ROLL_OUT, meRollOut); playTimer.stop(); playTimer.removeEventListener("timer", playHandler); }

And here's an example of a cleanUp timer function:

private function cleanUpTimerHandler(e:Event){ var tempNumChildren:int = playContainer.numChildren; var tempMovie:MovieClip; for(var i=0; i < tempNumChildren; i++){ try{ tempMovie = playContainer.getChildAt(i) as MovieClip; if(tempMovie.scaleX < .1){ tempMovie.cleanUp(); playContainer.removeChildAt(i); } }catch(e:Error){break;} } }

The cleanUp function is pretty self-explanatory; so let's take a look at the cleanUpTimerHandler(), which is available in the sample files folder at this location: cleanTimersAndListners/code/YesClean.as
In this sample application, triangle objects are constantly being generated and added to the playContainer movie clip. In the cleanUpTimerHandler function, each movie in the playContainer is analyzed and tested to check whether or not it is still useful. In this case, the terms of usefulness depend on the object's x scale (the triangles continue to decrease in scale over time). Once triangle is so small that it is not visible, the cleanUpTimerHandler method removes the instance from the display list.
To see demos showing the usefulness of garbage collection, watch the following videos:

Manual garbage collection

These animations on the iPod 4 (top) and Nexus One (bottom) perform well, keeping under 200 triangles in playContainer and never slowing down.

No manual garbage collection

These animations on the iPod 4 (top) and Nexus One (bottom) perform poorly, shown by the ever-increasing number of triangles in playContainer as the animation plays.

Considerations when using vectors and bitmaps

Vector graphics are great to work with because they look clean and vector assets are scalable. However, it is best to use vector artwork sparingly when you want to optimize performance. Vectors are displayed through a process of mathematical calculations performed for every line/polygon in each and every frame. For example, math calculations are processed 24 times a second if the stage fps is set to 24. The more complex the vector graphic is, the more complex the math equations will be.
For a mobile application, I recommend using minimal vector graphics during runtime. However, most—if not all—of the graphical assets in my project library are in vector form. Flash Professional makes it easy to right-click a vector graphic and choose the option to Convert to Bitmap. As I develop projects, I create a bitmap folder that contains bitmap versions of every vector graphic in the Library panel. This strategy allows me to have both scalability as well as the performance that I need for resolution tailored projects.
When you build mobile apps, you might be able to get way with using vector graphics for objects that do not move, such as a title screen. But when it comes to creating animations, it is best to stick with bitmap graphics.
To see demos of working with bitmap and vector graphics, watch the following videos:

Use of bitmap graphics

These animations on the Nexus One (left) and iPod 4 (right) perform well, shown by the high and consistent 30 frames per second (fps) even though more and more bitmap graphics come in.

Use of vector graphics

These animations on the Nexus One (left) and iPod 4 (right) perform poorly, shown by the degraded performance (as slow as 12 fps) as more and more vector graphics come in.

Tips for achieving better performance on mobile devices

This section highlights some best practices to improve performance in the mobile applications you build with Flash Professional.

Decreasing application startup time

To minimize load times, it is important to not bog the application down by loading your entire application all at once. For example, imagine that a game has 100 levels. There is no point in loading all 100 levels even before the title screen is displayed. This means you should not instantiate objects until they are ready to be used. Using an init() function in every class that instantiates objects and variables instead of placing the instantiation code in the class constructor or a global declaration allows for a more controlled environment. In terms of user experience, it is much better to have smaller chunks of load times than one big loading process right in the beginning.

Decrease the compile time by disabling warnings mode

In Flash Professional, access the Advanced ActionScript settings and locate the warnings mode option. By default, it is enabled; turn it off. If you have 400 linkages in your library to classes, it will take approximately 1–2 minutes to run a test movie when the warnings mode is turned on. When the setting is turned off, the same movie takes about 3–5 seconds to test instead.

Set ".visible = false" rather than "alpha = 0" properties to hide instances on Stage

Although the end result of setting a movie clip property as alpha=0 or visible=false looks the same on the Stage when you are testing, the performance ramifications are not equal. Long story short, objects that are set to alpha=0 are still computationally drawn on the screen, taking up valuable CPU resources. So set the visible property to false instead.

Avoid using real-time filters

Special effects such as glow, blur, bevel, or drop-shadow effects are wonderful to look at but bad for performance. That's not to say you should never use the built-in filters in Flash Professional. However, you'll find that if you convert the filtered movie clip to a bitmap graphic and use that instead, you can achieve similar visual results. And that way, you can boost the application's performance while displaying the eye-candy that you desire.

Be careful when enabling the Allow smoothing option

The Allow smoothing option for bitmap graphics helps images look good instead of jaggy when they are resized on the Stage. The problem occurs when you start animating many images that have the smoothing option enabled, or applying smoothing on a single image that has large dimensions, or when the image has been resized to larger dimensions. Remember that the Allow smoothing option is essentially the same as applying a filter to a bitmap in real time. For example, a 10 × 10 pixel image with smoothing enabled that has been resized to 2000 × 2000 pixels is just as slow, if not slower, than using an image with an original size of 2000 × 2000 pixels. However, a image 10 × 10 pixel image resized to 2000 × 2000 pixels without smoothing performs much better.

Sprite sheets > tiling graphic instances > one big image

The more time you invest in improving an application's performance, the better performance gains you can achieve. In the past, developers used tiling graphics rather than one big image to reduce load times and improve performance. These days, you can use sprite sheets in games to optimize performance and improve the user experience.