Accessibility

Table of Contents

Launch Fighters – Part 2: Optimizing Content for Resource-Constrained Devices

Managing Memory and Assets

For the time being, handheld devices have much slower CPUs and less memory than desktop machines running the Flash Lite player. Whenever any piece of Flash Lite content is developed, you must take memory usage into account. In addition, most devices are designed to display bitmaps at a specific bit depth, and can support only certain device sounds. So keep these constraints in mind.

Monitoring Memory Use

The runtime memory available to Flash Lite running on handheld devices is severely limited. Because of this, there may be limits imposed by the device to the final size of the SWF or sounds that need to be buffered while playing back the SWF file.

There are a few features of the Flash authoring tool and the Flash Lite player that help monitor memory usage. The Flash authoring tool generates a size report for the published SWF detailing where all the bytes in the file are used. You can use this feature to find "byte-heavy" frames in the Flash movie that may cause performance to suffer during playback. In some cases this exposes graphics that could be optimized or ActionScript that could be distributed to others place in the Timeline that aren't as memory-intensive.

The Flash Lite player also supports methods to return the total runtime memory assigned to the player on the device, as well as the amount of memory the current SWF has left to use. These methods are part of the FSCommand2 commands specific to the Flash Lite player—for example:

// returns the amount of memory allocated to the player in kilobytes
allocatedMemory = fscommand2("GetTotalPlayerMemory");

// returns the amount of available free memory in kilobytes
freeMemory = fscommand2("GetFreePlayerMemory");

Optimizing Bitmaps and Sound

To reduce the size of the SWF, as well as processor and memory usage, it's a good idea to take a close look at all of the graphic and sound assets in the movie. In most cases, there will be places where you can modify the assets to improve overall performance.

For instance, some device's LCDs are designed to display bitmaps at a specific bit depth. Because the LCD in the iRiver U10 is optimized for 16-bit graphics, I inspected each of the bitmaps used in Launch Fighters and saved them as 16-bit wherever they were originally 24-bit. Not only did this save a small amount of file size but it ensured a consistent render quality across bitmaps in the file.

In addition to adjusting the bit depth of the bitmap images, it's important to make sure that pixel dimensions of the image are not greater than they need to be. It's easy to import a larger image and scale it down for use on a mobile display in Flash. Better to reduce the file size and memory usage of the image in the movie by editing the image to the size and shape actually needed before importing it to Flash.

For example, the image of the earth in the Launch Fighters game screen is only partially displayed at the bottom of the screen. But the image in the Library is actually a picture of the entire earth that I scaled, broke apart, and cropped. I optimized the graphic by editing it in Fireworks so that it included only the top crescent actually used in the game. This cut the file size of the image dramatically.

The last type of asset to look at when optimizing your Flash Lite content is sound. There are two ways to use sound in Flash Lite 1.1. The first way is simply to import a WAV or MP3 file directly into the FLA and compile the SWF with the embedded sound. The second way is to use MIDI device sounds. If you are using MIDI device sounds, then the sounds are built into the device itself and there isn't much flexibility in customizing or optimizing sounds. Because MIDI device sounds are triggered from Flash, they probably impact performance less than WAV sounds do.

When using imported sounds, optimize the file size by using an MP3 format that's encoded at a low bit rate. Avoid using long sound samples that increase file size and memory usage. The properties for each sound in the library allow you to adjust its MP3 compression settings. Whenever possible, record the original sound at a low bit rate. This reduces possible noise and artifacts by avoiding down-sampling and higher bit rate wave compression.