Flash is a frame-based system. Knowing how it runs is fundamental to understanding performance issues.
The Concept of Frame
The concept of frame refers to a block of time more than traversing a frame on the traditional timeline, especially now that few developers use the timeline or put code on frames.
Code execution happens first, in the form of events and code; then the screen is rendered, and so on. Even if no ActionScript code needs to be executed, nor displayOb ject transformed, the process always happens.
The elastic racetrack termination encapsulates this notion of a loop process with potential elasticity and irregularity if the process takes longer than expected. The expectation is determined by the frame rate as you defined it. At 24 frames per second, the default rate on mobile devices, a frame has 1/24 of a second to run code and render the screen.
A high frame rate carries out more operations, but this does not imply better performance on mobile devices if they are not able to keep up, and it drains the battery. A lower but consistent frame rate guarantees smoother playback and a better user experience.
The four blocks starting from the left in Figure 19-2 and Figure 19-3 represent the analysis of events first and the execution of your code in response second.
The runtime never attempts to exceed the frame rate, or speed up if it is idle, but it may slow down if one of the two phases takes longer than expected. Some fluctuation is expected. But in the case of a consistently slow frame rate, or an erratic one, look for the bottleneck. In Figure 19-3, rendering slows down the frame rate.
Calculating the frame rate
Here is some code you can use to calculate your frame rate. To get a relatively accurate frame rate, interact with your application as you expect your audience to. Test it with other native processes running in the background:
[code]
import flash.utils.Timer;
import flash.events.Event;
var frames:int = 0;
var time:Number = new Date().time;
var timer:Timer = new Timer(1000);
timer.addEventListener(TimerEvent.TIMER, onTimer);
timer.start();
this.addEventListener(Event.ENTER_FRAME, onEnterFrame);
function onEnterFrame(event:Event):void {
frames++;
}
function onTimer(event:TimerEvent):void {
var now:Date = new Date();
var lapse:int = now.time – time;
trace(“FPS: ” + frames*1000/lapse);
time = now.time;
frames = 0;
}
[/code]
Improving performance
Because the ActionScript Virtual Machine handles code execution and rendering on a single thread, only one thing can happen at a time. This is why a processor-intensive operation blocks the renderer until completion or a complex rendering may delay the next code execution.
Use asynchronous events, which use a different thread, whenever possible. The operation may take a little bit longer but will resolve some of the bottlenecks.
SQLite operation can be done in synchronous or asynchronous mode. Only one mode can be used at a time:
[code]
SQLConnection.openAsync();
SQLConnection.open();
[/code]
Operations on the filesystem can also be asynchronous. Use such operations for fairly large files:
[code]
fileStream.openAsync(file, FileMode.READ);
fileStream.open(file, FileMode.READ);
[/code]
If your code performs long operations, you can restructure it to execute in chunks instead of all at once.
Rendering related to sensors should be done on EnterFrame, not when the sensor updates, which can be more frequent than the refresh rate and can be irregular. If you use EnterFrame, create a single listener to manage all your objects.
Never use the updateAfterEvent function. It forces rendering for faster animation. On mobile devices, it will reduce your frame rate. If you need extremely high-speed animation, AIR is not the right tool for the job.
Setting the stage quality to low, or toggling settings, is a good option for faster rendering:
[code]
stage.quality = StageQuality.LOW;
stage.quality = StageQuality.HIGH;
[/code]