Mind Candy

Over here at Moshi HQ, we’ve spent a fair bit of time looking at how to reduce the size of the SWFs we publish to ensure that the game loads quicker for all our users (and to cut down on bandwidth cost!); here’s our quick checklist that we rattle through to get the most bang for our buck (or in this case, Kb)

Joa Ebert’s Apparat.
Joa is an ActionScript hero (in fact he won an award to prove it); one of his tools is Apparat – a Scala application which optimises SWFs by tinkering with the compression they use. Apparat is a real quick win as once you’ve integrated it into your build process you will immediately being reaping the rewards.

Sothink SWF Decompiler
Yes, number two on my list is a decompiler; this is not a mistake. Sothink SWF Decompiler is an essential part of the optimisation process as it allows you to explore all the assets, ActionScript classes, fonts, bitmaps, etc which are lurking around in your SWF – think of it like a visual Size Report for a SWF.

Making use of Run Time Shared Libraries
Flex developers seem very comfortable with Runtime Shared Libraries, but it’s something that most ActionScript dev’s aren’t so hot on. The MXMLC compiler provides a couple of ways to reduce the size of your published SWF by allowing you to automatically exclude duplicated class definitions across SWFs loaded at run time. The problem is a very simple one; you have a Main application which loads in a bunch of child “sub apps” into the same Application Domain; both of the SWFs end up with the same classes compiled into them (for example, you may be using famework elements in both) – because the Main application SWF has already loaded these classes there is no need to include them into the child swf as well.

The simplest MXMLC compiler flag you can use is, -runtime-shared-libraries, simply point it at the location of your Main SWF when compiling the subapps and it will do the rest for you. Alternatively, Those of you who worked in AS2 back in the day may recall the old exclude.xml; well it’s still alive and kicking with MXMLC, it just goes under the name of -link-report.

The process is pretty straight forward, compile your main application supplying the link-report flag, this will dump out an XML file. Next, compile all your subapps supplying the load-externs flag. Keith Peters goes into more detail on his blog.

Checking our Compiler Flags
This may seem pretty obvious, but it’s important to check; The MXMLC compiler which ships with the Flex SDK supports a crazy number of switches and options, the following options can impact on the size of the compiled SWF:

• -debug – Pretty obvious, if you set the debug flag to true when compiling, MXMLC will embed a whole bunch of debugging information to your SWF, bloating out the filesize. The main thing to watch out for is that you don’t end up deploying SWFs compiled with the debug flag set to true on your live server. Sames goes for the -optimise and -verbose-stacktraces flags
• -include-libraries – Make sure that you didn’t mean to use -library-path instead! include-libraries will compile the entire contents of a SWC into your final SWF file even if you never actually use any of it! Using library-path, on the other hand, results in only the classes which you import being compiled into the SWF

All of the above require no changes to our existing codebase, but combined have resulted in a massive reduction for the size, and loading time of our SWFs.