Memory, Memory, Memory

The biggest enemy when creating Flash Lite content is not performance, but running out of memory. I touched on this already in various places throughout this article, and it really is most likely the issue on which you’ll spend most of your debugging time. First, you need to realize that file size is not equal to memory used. File size is an important indicator, but it is simply not the same as how much memory your movie needs to run. For example, JPEG images are compressed inside the SWF file, but they need to be restored to their full size for display. The same is true for sound files—an MP3 or ADPCM compressed sound file is a lot smaller than a raw sound file, but when played, it has to be turned back into raw sound. Other objects, such as movie clips or code, need more memory at runtime by themselves than they would if they were stored in the SWF movie.

Additionally, you’re able to create more objects when the movie is running, for example, by duplicating movie clips. Each new object uses additional runtime memory without adding to the file size.

That doesn’t mean file size is not important; you may still have to meet file size limit specifications, and bandwidth when the file is received over the air is still very limited, similar to the bandwidth of a 14.4K modem—unless you are fortunate enough to develop for 3G networks only. You also need to keep in mind that most phones have rather limited storage capacities.

“2001” in Memory Space

Our first attempt to put the “2001” animation on the phone worked just fine regarding the file size. We put it on the phone, and opened it. However, as soon as we pressed Play it ran out of memory. The Flash Lite player simply needed more memory to play back the animation than to load it.

As discussed earlier in the section on sound, this had a lot to do with the soundtrack, and we found a way to help the Flash Lite player manage its memory better by splitting up the animation into shorter segments, each placed in separate movie clips.

In a linear animation like this one, without duplicating clips or any code apart from a few gotoAndPlay actions, the runtime memory is determined strictly by how much memory the objects that are currently on the Stage use, how much sound uses, and how Flash handles the objects that are not used right at this moment.

Unfortunately, we don’t have access to tools that enable us to see how memory is handled. However, I can make some educated guesses: For sound, as described above, Flash loads and decompresses all the sound for a specific movie clip and keeps it in memory, ready to play whenever you go to any frame. Flash does this for every nested clip separately. That is why splitting the soundtrack over multiple movie clips made such a difference.

Something very similar is the case for all shapes, outlines, and graphic symbols placed in a movie clip (and the main Timeline of the FLA file is also a movie clip for that matter): It loads everything into its runtime memory, as soon as that movie clip is in a keyframe. The more such objects Flash needs to keep track of, the more memory it uses. Again, this does not relate directly to file size; it is about the number of objects, along with their complexity.

This explains why an animation may run fine on its own, but when adding more and more audio, it will eventually run out of memory. However, after we optimized the animation—by putting 10 symbols that make up a hand in a movie clip and move them together—it all worked fine again. The player has fewer objects to keep track of, and, even though the file size went down just a little bit, it requires less runtime memory.

This may sound like voodoo to you, but until we have better tools that show exactly how much memory is used and by what, this is all we have to work with.

Tips to Remember

Now on to a few more practical tips for optimizing animation for both runtime memory and file size:

• Put your graphics in symbols, and optimize them, either by selecting Modify > Shape > Optimize or using the subselection tool. Remove all unnecessary points.
• Use graphic symbols for flat shapes and lines, and use movie clips when nesting symbols.
• Graphic symbols render faster since they are not “active objects” at runtime. Nested graphic symbols (static and animated) are broken down when exported; each nested symbol is exported with its own 12 placement bytes for each keyframe of the parent.
• Movie clips on the other hand are exported only once, complete with all their child content. Again, 12 bytes may sound like nothing. However, if you have 12 nested symbols, you are adding about 150 frames for each keyframe where you use a nested graphic symbol.

  By comparison, a movie clip uses only 12 bytes per keyframe after the 150 bytes it uses when it is used for the first time. Again, this doesn’t sound like much of anything, but if this is used over 10 frames (for example, a tween), you are already saving 1.2 KB in file size. This reduction in file size also corresponds to fewer objects that Flash needs to handle. Yet, you still see the exact same objects as the SWF plays. This is because the movie clip (instead of each nested graphic for each keyframe) is tracked, and the movie clip keeps track of its own contents. If that doesn’t change, nothing else needs to be memorized.

Remember that graphic symbols and movie clips function very differently when exported. When I first discovered this, my initial reaction was to use only movie clips. However, a movie clip carries a runtime overhead, because it is an active object. If you use movie clips for simple graphics (nothing nested, just shapes, outlines, and text), you don’t gain anything; you only end up using more runtime memory.

Keep in mind that motion tweens are exported as individual keyframes; you don’t save anything compared to using a keyframe each frame.

Summary

In this article, you have learned a number of tricks that ensure that your Flash animations run and look good on mobile phones. I have shared with you some tips on how to work around the size and performance limitations of mobile devices, including the sound and memory pitfalls to avoid. I have introduced you also to the nitty-gritty details on how to optimize your animation for memory usage, file size, and performance. You should now be well-equipped to get started with your own project.

At this point you may wonder, “Is it really worth all the trouble?” The answer is a resounding “Yes.” If you’re not trying to squeeze a two-minute-long animation onto a phone, you’ll probably not even face half the troubles that we went through. For us, it was a challenge we couldn’t refuse, and we succeeded. And I hope that what we learned will save you some headaches and trouble as well.

If you haven’t tried to put your first animation on a mobile phone—what are you waiting for? Get a compatible phone, get the Flash Lite player, and get started already! Download the “2001” animation from the Flash Lite exchange and view it on a phone for your inspiration.

And by the time you see your own content on a phone, you’ll be a Flash Lite convert, for sure.