Adobe 29400084 User Guide - Page 27

Optimizing ActionScript for Flash Lite content on mobile devices, identifier, such - flash download

Page 27 highlights

DEVICE CENTRAL 24 User Guide Optimizing ActionScript for Flash Lite content on mobile devices Because of the processing speed and memory limitations on most mobile devices, follow these guidelines when developing ActionScript for Flash Lite content used on mobile devices: • Keep the file and its code as simple as possible. Remove unused movie clips, delete unnecessary frame and code loops, and avoid too many frames or extraneous frames. • Using FOR loops can be expensive because of the overhead incurred while the condition is checked with each iteration. When the costs of the iteration and the loop overhead are comparable, execute multiple operations individually instead of using a loop. The code may be longer, but performance will improve. • Stop frame-based looping as soon as it is no longer needed. • When possible, avoid string and array processing because it can be CPU-intensive. • Always try to access properties directly rather than using ActionScript getter and setter methods, which have more overhead than other method calls. • Manage events wisely. Keep event listener arrays compact by using conditions to check whether a listener exists (is not null) before calling it. Clear any active intervals by calling clearInterval, and remove any active listeners by calling removeListener before removing content using unloadapplication or removeapplicationClip. Flash does not re-collect SWF data memory (for example, from intervals and listeners) if any ActionScript functions are still referring to the SWF data when a movie clip is unloaded. • When variables are no longer needed, delete them or set them to null, which marks them for garbage collection. Deleting variables helps optimize memory use during run time, because unneeded assets are removed from the SWF file. It is better to delete variables than to set them to null. • Explicitly remove listeners from objects by calling removeListener before garbage collection. • If a function is being called dynamically and passing a fixed set of parameters, use call instead of apply. • Make namespaces (such as paths) more compact to reduce startup time. Every level in the package is compiled to an IF statement and causes a new Object call, so having fewer levels in the path saves time. For example, a path with the levels com.xxx.yyy.aaa.bbb.ccc.funtionName causes an object to be instantiated for com.xxx.yyy.aaa.bbb.ccc. Some Flash developers use preprocessor software to reduce the path to a unique identifier, such as 58923409876.functionName, before compiling the SWF code. • If a file consists of multiple SWF files that use the same ActionScript classes, exclude those classes from select SWF files during compilation. This can help reduce file download time and run-time memory requirements. • Avoid using Object.watch and Object.unwatch, because every change to an object property requires the player to determine whether a change notification must be sent. • If ActionScript code that executes on a keyframe in the timeline requires more than 1 second to complete, consider splitting up that code to execute over multiple keyframes. • Remove trace statements from the code when publishing the SWF file. To do this, select the Omit Trace Actions check box on the Flash tab in the Publish Settings dialog box. • Inheritance increases the number of method calls and uses more memory: a class that includes all the functionality it needs is more efficient at run time than a class that inherits some of its functionality from a superclass. Therefore, you may need to make a design trade-off between extensibility of classes and efficiency of code. • When one SWF file loads another SWF file that contains a custom ActionScript class (for example, foo.bar.CustomClass) and then unloads the SWF file, the class definition remains in memory. To save memory, explicitly delete any custom classes in unloaded SWF files. Use the delete statement and specify the fully qualified class name, such as: delete foo.bar.CustomClass.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46

DEVICE CENTRAL
User Guide
24
Optimizing ActionScript for Flash Lite content on mobile devices
Because of the processing speed and memory limitations on most mobile devices, follow these guidelines when
developing ActionScript for Flash Lite content used on mobile devices:
Keep the file and its code as simple as possible. Remove unused movie clips, delete unnecessary frame and code
loops, and avoid too many frames or extraneous frames.
Using
FOR
loops can be expensive because of the overhead incurred while the condition is checked with each
iteration. When the costs of the iteration and the loop overhead are comparable, execute multiple operations
individually instead of using a loop. The code may be longer, but performance will improve.
Stop frame-based looping as soon as it is no longer needed.
When possible, avoid string and array processing because it can be CPU-intensive.
Always try to access properties directly rather than using ActionScript getter and setter methods, which have more
overhead than other method calls.
Manage events wisely. Keep event listener arrays compact by using conditions to check whether a listener exists
(is not
null
) before calling it. Clear any active intervals by calling
clearInterval
, and remove any active
listeners by calling
removeListener
before removing content using
unloadapplication
or
removeapplica-
tionClip
. Flash does not re-collect SWF data memory (for example, from intervals and listeners) if any Action-
Script functions are still referring to the SWF data when a movie clip is unloaded.
When variables are no longer needed, delete them or set them to
null
, which marks them for garbage collection.
Deleting variables helps optimize memory use during run time, because unneeded assets are removed from the
SWF file. It is better to delete variables than to set them to
null
.
Explicitly remove listeners from objects by calling
removeListener
before garbage collection.
If a function is being called dynamically and passing a fixed set of parameters, use
call
instead of
apply
.
Make namespaces (such as paths) more compact to reduce startup time. Every level in the package is compiled to
an
IF
statement and causes a new
Object
call, so having fewer levels in the path saves time. For example, a path
with the levels
com.xxx.yyy.aaa.bbb.ccc.funtionName
causes an object to be instantiated for
com.xxx.yyy.aaa.bbb.ccc
. Some Flash developers use preprocessor software to reduce the path to a unique
identifier, such as
58923409876.functionName
, before compiling the SWF code.
If a file consists of multiple SWF files that use the same ActionScript classes, exclude those classes from select SWF
files during compilation. This can help reduce file download time and run-time memory requirements.
Avoid using
Object.watch
and
Object.unwatch
, because every change to an object property requires the player
to determine whether a change notification must be sent.
If ActionScript code that executes on a keyframe in the timeline requires more than 1 second to complete, consider
splitting up that code to execute over multiple keyframes.
Remove
trace
statements from the code when publishing the SWF file. To do this, select the Omit Trace Actions
check box on the Flash tab in the Publish Settings dialog box.
Inheritance increases the number of method calls and uses more memory: a class that includes all the functionality
it needs is more efficient at run time than a class that inherits some of its functionality from a superclass.
Therefore, you may need to make a design trade-off between extensibility of classes and efficiency of code.
When one SWF file loads another SWF file that contains a custom ActionScript class (for example,
foo.bar.CustomClass
) and then unloads the SWF file, the class definition remains in memory. To save memory,
explicitly delete any custom classes in unloaded SWF files. Use the
delete
statement and specify the fully
qualified class name, such as:
delete foo.bar.CustomClass.