One of the strengths of Flash as a development environment is that it is very visual, and you're able to get things moving on the screen quite fast. However, this might also prove to be one of its weaknesses concerning mobile development if you are not careful.
The difference between tight and working code is that both do work. But the tighter the code, the smaller the footprint—meaning less space in kilobytes and faster execution. This is quite challenging with Flash Lite 1.1 due to its nature as a scripting language instead of a procedural programming language. With Flash Lite 2.0 and later—using ActionScript 2, which is an object-oriented programming language—there is a real difference between code created by a programmer and code created by a visual developer. There are hacks and gimmicks that can be used to optimize the code, but everything starts from the programming style.
To learn more about optimization, read this excellent Flash Lite article on LiveDocs: Optimizing ActionScript Performance.
Here are some additional tips:
Shorten variable and function names. When you're really running out of space, or want to squeeze out everything—and believe us, you do—make the variable and function names shorter. By doing this, you will save a few bytes from the overall file size.
In Flash Lite, variable names by default are not converted to anything shorter when a SWF file is compiled. Because the code is not obfuscated (packaged using an obfuscator, which shortens variable and function names automatically) when it is published, there's room for improvement. Here is an example:
// This is descriptive var monthNamesArray:Array = new Array(); monthNamesArray[0] = "January"; // This is shorter, but still somewhat understandable var months:Array = new Array(); months[0] = "January"; // This is very short and not descriptive at all. // Should be used only if absolutely necessary // and with a description about the variable. var m:Array = new Array(); m[0] = "January";
There are two side effects of shortening variable and function names. First, you need to have excellent documentation (which is always good, and hopefully mandatory) in order to make the shortened code understandable by others, or even yourself, at a later time. Second, because DRM (digital rights management) in Flash is not yet top-notch, and it's pretty easy to reverse-engineer SWF files, using shortened code makes it increasingly difficult, or even impossible, for others to understand what does what in your code—except perhaps by your workgroup which has the excellent documentation.
If possible, divide or modularize large applications into several SWF files that can be loaded separately when needed. For example, you could try designing your game so that separate game levels are in separate SWF files. After the user has completed one level, your application just loads another movie. Of course, you might need to copy some common code into each SWF file but that's a small price to pay for having a game that can easily be extended.
This requires a target device that supports some file format that you are able to package files into, such a SIS file in Symbian devices. The other option is to use Flash in a web browser or a standalone Flash Lite application that loads SWFs from a server. Note that using several SWF files causes increased loading times (called latency) and data does cost money for the end user, so beware.
Just keep in mind that the end user has to pay for the data transfer, which can be a major obstacle unless airtime is included in the carrier's contract.