This chapter is from the book
This chapter is from the book
This chapter is from the book
Optimizing Interfaces
It is a well-known "law" of programming that when you run a program, it will spend 90% of its time in 10% of the code. Determining what that 10% is is literally half the battle of optimization. After you've optimized that 10%, there's little more optimization that needs to be done because mathematically, the rest of the code is just noise.
How does this apply to interfaces? Well, it just so happens that interfaces have a nasty habit of living in that 10% of your code that runs the most. Your interface is always around; therefore, it often has code running to handle it. The last thing you want to do is to waste valuable cycles on your interface on a low-powered device! With that in mind, let's take a look at various ways of tracking down the most wasteful parts of your code and optimizing them.
Non-Coding Issues That Are Related to Optimization
Most of the non-coding issues with developing Flash interfaces for devices (or any platform for that matter) come down to being careful with bitmaps, gradients, excessive vectors, and alpha. By themselves, all four of these can grind a processor into the dirt.
Drawing bitmaps hurts devices in two ways. First, they tend to be large, which is obviously an issue on devices where space is at a premium. Second, blitting bitmaps to the screen takes up a relatively large amount of processor power. This is made even worse if you animate bitmaps. That's not to say that you shouldn't use bitmaps—just use them in moderation.
That's not to say that vectors can't hog the CPU as well. Remember: Vectors are just rules that describe how to draw an image, so if there are a lot of vectors, the processor has to do a lot of work to draw them. In fact, very complex vector images are just as bad—if not worse—than bitmaps. The secret is to find the sweet spot for your particular image. If your image is relatively simple in nature, a vector will probably work best. If your image is complex and detailed, a bitmap will be a better choice. When in doubt, test both options.
Gradients are similarly CPU intensive. This is particularly true if you use gradients that have transparent colors in them. When optimizing a movie for devices, gradients should be one of the first things to go.
If you saw the earlier paragraph on bitmaps and thought that you might be able to use "trace bitmap" to get rid of your bitmaps in a processor-friendly way, you are mistaken. That process produces hundreds—if not thousands—of vector shapes, something that can easily bring a device's processor to a grinding halt. Simplify your vector shapes whenever possible using the Modify, Optimize panel.
If a particular shape or symbol in your movie is using alpha transparencies, then the CPU has to render both behind that object and behind the actual object. Essentially, it's more than twice the work. If you don't have to use alpha, then don't. When possible, consider modifying a symbol's brightness or tint instead of its alpha.
Besides optimizing in this manner, you might also want to look into the possibility of rendering your movie in low quality. When you do this, you are skimping the anti-aliasing engine that's built into Flash and saving quite a bit of CPU power. If that's not possible, try the medium setting. That setting does half of the anti-aliasing and can speed things up a bit.
Code-Based Optimizations
Keep in mind that it is often said that premature optimization is the root of all evil, and I tend to agree. Before you go gung-ho with these optimizations, be sure that your idea is optimized. Changing how you think about a problem can easily outstrip any optimizations you can do by tweaking a bad idea.
With that in mind, we are going to cover three optimizations: variable and object optimization, loop optimization, and memory optimization.
Optimizing Variables and Objects
Optimizing variables and objects is actually pretty straightforward. The rule of thumb is to keep it simple. For example, if a variable doesn't need to be a floating point, chop it down to an integer before you do math on it as in this example:
foo = x/y; // if foo doesn't have to be a floating point number, just force it an integer foo = int(foo); // you could also use Math.floor or Math.ceil
Don't do string operations if you don't have to. The string operations in Flash 5 are actually written in unoptimized ActionScript and can bog down quickly. If you have to use string operations, get the string object rewrite from http://chattyfig.figleaf.com/.
You should also try to avoid the XML object, which is naturally pretty slow in parsing. If you have to use the XML object, be sure to also use the XMLNitro package from http://chattyfig.figleaf.com/.
One of the biggest optimizations you can do with loops is to use shortcut variables. That is, if you have objects that you need to reference often, like this:
root["item"+I].header["icon"+j]
then create a shortcut to that variable:
var temp = _root["item"+i].header["icon"+j]
Loop Optimizations
All of those array operators and such are CPU intensive, particularly if you are doing it multiple times within a loop. By creating a shortcut, you are only doing that once within your loop.
This also applies to working with the length property of strings and arrays. The following code
for (var i=0; i<str.length;++i){
...
...
}
is going to be significantly slower than this code:
var max = str.length;
for (var i=0; i<max; ++i){
...
...
}
This fact is particularly true if the length of the string or array is large. This occurs because the act of calculating the length of something takes CPU cycles, and by having that calculation in the comparison part of the for loop, you are forcing it to be rerun each iteration. By precalculating the length of the string, you are letting Flash do a simple variable lookup rather than a measurement calculation, which quickly adds up to a lot of savings.
Memory Optimizations
Memory optimizations are particularly important on devices due to their limited RAM sizes. When at all possible in your Flash movies, clean up after yourself. That is, remove movie clips that aren't needed, unload SWFs that you aren't using, and use the delete operator to remove objects that you are no longer using.
Keep in mind that the delete operator does not immediately delete an object; instead, it removes that particular reference to the object. Flash automatically collects its "garbage" by doing what is known as reference counting. When an object doesn't have more variables referencing it (and there is sufficient CPU time), it removes the object and frees up its memory.