Jun Heider has an excellent piece on O’Reilly’s InsideRIA site discussing a number of the options for minimizing the startup time of Flex applications,
in hopes of helping developers reduce the amount of time that users see the ugly "Loading" dialog. He covers the different areas of consideration in depth, along with any important pros and cons to consider for each technique.
- Externalize Media
Heider discusses a common Flex best practice of limiting the amount of media embedded in the application / SWF file, as things like images, movies, and mp3 can all be loaded from outside the SWF file:
The Flex framework makes available to you a way to compile assets such as images, mp3 files and fonts directly into your application SWF. Although this comes in handy with making sure that the end user will have a copy of your assets this is a very good way of causing your application to remain in “Loading”.
- Limit Character Sets for Embedded Fonts
Heider suggests limiting the characters within the embedded fonts to reduce the overall download size of the SWF file:
When you embed a font in Flex, you are given the whole range of characters supported by that font. Although that might be what you’re trying to accomplish with your application, are you sure you need all the characters? For instance, in an English-only applications are you sure you really need to spend time loading data for Chinese characters?
- Caching the Framework
Heider reviews Flex 3 support for runtime-shared-libraries (RSL):
As of Flex 3 you can now cache Adobe signed framework RSLs into a Flash Player cache. The beauty of this is twofold. First, signed framework RSLs cached in the Flash Player cache are shared among all Flex applications that are configured to use them. In other words, if someone else’s app had already pulled down the 500KB or so of signed framework RSL, and the RSL is still in the Flash Player cache, your application can use that cached RSL. Second, if someone clears their browser cache, it does not affect the Flash Player cache.
- Consider Modules
Heider evaluates the benefits and trade-offs of breaking Flex applications into modules:
Another way to minimize that up front load time is to break your Flex application into Modules. A benefit to using Modules is that you have control over when a Module is loaded into your application and also unloaded.
Last point to make about Modules is the reason they were faster was because I could load them in just in time. In other words, the only Module loaded at startup was the Step1.swf Module. So in this case of Modules, the end-user saved on startup time, but will end up paying for it when they move from one Module to the next since each new Module will need to be loaded in a JIT manner. In the case of my app, this penalty is when the user moves through each of the steps 1-5 for the first time.
- Deferring Instantiation
Heider discusses the options around the “creationPolicy” attribute on the Flex components and when to instantiate different pieces of the application:
The number one thing you can do to help minimize the amount of time from when data is downloaded to when the user can actually use the application is by deferring instantiation. The concept behind this technique is not creating objects in memory until they’re actually needed by the application.
Although deferred instantiation techniques will cause little - and oftentimes unnoticeable - delays throughout the use of the application, this is often considered more acceptable behavior than having a long application startup delay. The other benefit to deferred instantiation is optimized memory utilization.
Heider includes an additional “experimental” item, “Taking Advantage of the Stream,” where he discusses Dirk Eismann's post, “Building monolithic Flex SWFs that still startup quickly.”
Eismann offers a technique for using multiple frames in the Flash Player to stream in parts of the application. Check out the full post
to read more about this and all of the suggested improvements to reduce Flex startup times.