Optimization Techniques for Air for Android apps

Day one everything I heard about mobile development was performance, memory optimization, and battery consumption. Spread all over the internet are a variety of articles and presentations with a variety of [great] optimization techniques.

As with my previous posts on performance optimization I like to focus on the big gains and these techniques that are practical. I say practical because you can’t always spend a year working on each component and optimizing every interaction, but what you can do is focus on the big gains and when time permits – the details. I don’t mean to play down the importance of code optimization; especially for mobile applications optimization is of the highest importance.

In no particular order of importance let’s look at some excellent places for performance and memory allocation gains.

Keep framerate as low as possible

For anyone that hasn’t looked into it, the default framerate for the Flash Player is 24 frames per second. That means that 24 times every second new code is being executed, regions are being redrawn, and user interactions are being calculated. So it stands to reason that the quickest way to reduce memory consumption, code execution, and redrawing algorithms is to reduce the framerate and therefore the amount of times per second that all these calculations are being run.

What few developers know is that you can change your framerate dynamically dependent on what is happening within your application. The first recommendation is to set your framerate to something low but tolerable – like 4 frames per second. Then when a transition or other animation is going to play increase your framerate to keep your animation smooth.

stage.frameRate = 4;

Monitoring your framerate is very important as many flash designers want to ramp up the framerate to 60 frames per second because it will make the animations “pretty”.

Avoid timers

Each timer that you add and use in your application connects into the Flash Player environment and calculates time on each frame, thus adding additional computations on each frame for each timer you create. Real fast you can multiply these calculations if you aren’t careful.

To improve performance avoid high rate timers, this will reduce the amount of events being fired and the quantity of code being executed.

The second performance increase is to have one timer for the entire application. Think of it as a heartbeat for your application keeping the internal timing for all your functions. This will reduce the amount of timers you have and the amount of time calculations taken from the Flash Player environment.

Blends and Filters

It has long been known that as filters and blends cause for an extra amount of lifting from the Flash Player, lifting that can truly slow down performance. So where possible avoid blends and filters. “But I want to have a 2px drop shadow around this box.” Does it really need to be a filter? Can you not use a dark line that is 2 pixels thick? I know this sounds elementary but many people seem to forget that there are other more creative solutions that might get you to the same goal.

Cache As Bitmap

If you’ve been in the Flash Player world for a while you will remember the day you saw Adobe’s cacheAsBitmap presentation and how quickly everything rendered. My mind was blown and I had found my magic bullet to all my slow rendering woes.

Well not exactly. cacheAsBitmap is amazing and in many situations can be very helpful. How does it achieve it’s amazing win? By caching a bitmap off screen that can be used as opposed to needing to recreate the bitmap over and over again. The issue comes if you change the alpha/rotation/colors on your bitmap. Now the renderer needs to make a new bitmap to cache and you are doing extra lifting to cache and draw rather than just draw. What this means for you is if you are going to be making lots of alpha/rotation/colors changes then you might not want to set cacheAsBitmap to true.

myBall.cacheAsBitmap = true;

One other little used cache method is cacheAsBitmapMatrix. Similar to the cacheAsBitmap this will also cache the x, y, rotation, scale, skew properties. Keeping the Flash Player from having to redraw the object. Again, if you make any changes to alpha/color or the children sprites matrix the object will be redrawn and you will be spending more time and memory to cache an object that is constantly redrawn.

myBall.cacheAsBitmap = true;

myBall.cacheAsBitmapMatrix = new Matrix();

Asset Management

Asset management is extremely important with mobile because all those images can eat up memory quick.

First: Make sure your images are the right size. I’ve seen many developers take icons that are 40×40 and just resize them to 20×20 at runtime. I know this seems picky and obvious but this is a quick way to double your memory and hurt rendering performance with unnecessary calculations. Just make sure that images are set to their proper size.

Second: Don’t embed fonts/images/media you aren’t using. It’s easy to forget about all the items you are embedding. Be an asset nazi.

Third: Compress Compress Compress. Do you really need that high quality sound file? Or that PNG with the transparency layer when there is no transparency? Compress those media files. Use JPGs rather than PNG when possible. And if you are just trying to see the background through an icon, think or building the icon with the correct background already in the file. Transparency is another calculation that isn’t necessary if you can be sure of the end goal.

Don’t forget that images split by the power of 2 are going to be more efficient on memory than odd sized images. This can’t always be avoided by it’s good to remember. This is definitely a nit-picky thing.

“Make bitmaps in sizes that are close to, but less than, 2n by 2m bits. The dimensions do not have to be power of 2, but they should be close to a power of 2, without being larger. For example, a 31-by-15–pixel image renders faster than a 33-by-17–pixel image. (31 and 15 are just less than powers of 2: 32 and 16.)”

-From the Developing Air Apps for Android Guide.

Events and Bubbling

I’m really interested to see how Mate responds to this one. We’ve known for a long time that events are costly and that lots of events and event bubbling through deeply nested component trees can lead to bottle necks and performance issues.

A quick way to deal with these issues is to not bubble your events when possible and when you do need to bubble, stop propagation when the events have reached a point that they don’t need to bubble anymore.

event.stopPropagation();

Simplifying your display tree whenever possible is a great way to improve performance. Don’t do this for just the events but for your entire application.

One other thing you can do is prevent mouse events (that are set to bubble by default) from effecting children you weren’t intending. Try setting mouseChildren and mouseEnabled to false.

Drawing API

For you masochists that love to write out Actionscript drawings I’d take particular notice of this part. Watch out how much you draw dynamically because each drawing is drawn to the stage and then rendered in the rasterizer. When you build assets at authoring time your assets are rendered and stored in memory rather than created on the fly.

Color Selection

This gain is specifically to do with battery life. The color white takes more power to show than the color black. Am I saying to have all your applications look like tributes to The Dark Knight? Nope. Just giving your designers a warning that their decisions directly effect performance and battery consumption.

Embedded Fonts and Device Fonts

Android devices have fonts that are embedded within the system, these fonts will require the smallest amount of memory because it won’t require embedding any additional fonts and they render remarkably fast. Use these fonts when possible.

But what if you have a picky designer that has to have the fonts his way? Embed your fonts for the fastest rendering and follow best practices to limit the glyphs that you include with your embed.

You can find out what fonts your Android system has in the /system/fonts folder.

Garbage Collection

First off I think I need to say “stop running the garbage collection”. Yes developers, I know you want your application to clean itself up immediately. However, I’ve seen more than one app become sluggish because of an over worked garbage collector. So all those tricks that you’ve found to run the garbage collector, stop. The Flash Player runs the garbage collection when it needs to. If something isn’t going away the way you expect maybe you should check for other leaks caused by listener references or other common leaks.

Memory Allocation

Not enough programmers take advantage of Object Pooling. This is probably why I was impressed with PushButton Engine right from day one, everything is based off object pools. This is an easy and tested way to reuse objects and save your application from the costly ‘new’ function.

What do I mean by the costly new function? Whenever you use the “new” function and create a new object you are running a costly operation. Multiple things happen deep within the Flash Player including heap/memory allocation, garbage collection, and component creation. If you know you are going to be creating and destroying something frequently make the change to Object Pools early and save yourself the memory and performance woes.

A few months back I wrote another article doing a series of performance tests. I devote an entire section of tests to the “new” operator in Practical Performance Tweaks.

Video

This is something that your designers are going to hate: stop messing with the video player! All those crazy graphics, overlays, and blends that you may put over your video to add the grunge border will need to go. If you are worried about performance these are a quick way to cause redraws and layering calculations on each video frame.

When encoding your video thing of the final endpoint. Most devices have a native codec (usually H.264) that will help improve decompression and playback on the hardware level rather than the software level. Make sure to target these native codecs and see the performance and battery life improvement.

Show Redraw Regions

This is pretty low on the priority list but very important if you get it wrong. Flex visual components build off of the Flash Sprite class. As such they are interactive objects without animation timelines. However, when working with Flash based components, Flex developers often forget the MovieClip Class – the lowest class to include a timeline. This class can be set to run causing all sorts of redraws on each frame of animation until it is eventually told to stop playing.

When working with visual components from Flash or especially components that are based off of Movieclip make sure to stop the timeline when the component is not visible. Even when invisible the timeline is running and redraws are occurring. Using the Show Redraw Regions will expose this.

movieClipComponent.stop();

It is also best practices to look over your application as a whole and make sure that components aren’t needlessly being redrawn. This may be caused by a bad property or a misbehaving function. Check that only regions that change are actually getting redrawn for some pretty nice performance increases.

Open To Comments

I’d be interested to see where else others have seen visible improvements when using specific performance improvement methods. Feel free to comment! All the methods displayed above I have personally tested and seen the difference between using them and not using them.