Monitoring and Managing Memory on the Device
- Use size reports to manage SWF file size
- Avoid complex vectors with too many curves and points.
- Attempt to use primitive vectors including circles, squares, and lines.
- Experiment converting vectors to JPEGs and test how this affects performance.
- Wherever possible use JPEGs optimized for smaller file size in an external editor such as Photoshop or Fireworks and save for the appropriate bit depth.
- Use PNGs if bitmap transparency is required and cannot be faked by using masked JPEGs or JPEGs merged with the background.
- When using transparent PNGs insure that they do not overlap (including the transparent areas). Rendering transparency through another transparency will exponentially burden the processor.
- Experiment converting JPEGs to vectors (via Trace Bitmap command in Flash) and test how this affects performance.
- Most supported handsets will playback Flash at 12-15 frames per second(fps)
- Low-end = 6-12 fps
- Average = 12-15 fps
- High-end = 15+ fps
- During development limit the framerate to resemble playback speed on target handset to test responsiveness and speed of animation in low fps situations
- Set the framerate to at least 20 fps when publishing final file to avoid artificially limiting performance should the handset be capable of higher framerate
- Transparency and gradients are processor intensive tasks and should be used sparingly. Experiment with faking transparency using JPEGs, masks, and gradients.
- Adjusting the render quality
- You can control this during playback to improve performance
- fscommand2("SetQuality", "low");
- fscommand2("SetQuality", "high");
- It is important to remember that with a typical mobile UI, without a stylus, the user’s eye can usually only follow one thing at a time.
- Make the area of focus well designed and animated, then reduce animation and effects in other areas of the screen.
- Pause passive background animation (i.e. subtle background effects) during transitions.
- Content performance will be directly affected by percentage of the screen being updated simultaneously. Avoid designs that rely on frequent full-screen refreshes.
- Avoid tweening too many items simultaneously. Reduce the number of tweens and/or sequence animation so that one begins when another ends.
- Test adding/removing animated elements to weigh their impact on performance.
- Use easing wisely. On slower hardware it can create an “appearance” of lag.
- Use frame-based loops sparingly
- Stop frame-based loops as soon as they are not needed
- Where possible, distribute complex blocks of code across more than one frame
- Use scripted animation sparingly
- Avoid array emulation
- Avoid doing string manipulation
- Scripts with hundreds of lines of code will be just as processor intensive as timelines with hundred of frames of tweens
- Evaluate content to determine whether animation/interaction can be easily achieved with the timeline, or simplified and made modular using ActionScript
- Use frame calls to make ActionScript calls only as needed and avoid too many looping “if” statement movie clips that do not terminate