• Choose a category
• All
• Classic-Fiction

Read blogs for up-to-date information and code snippets. Visit websites for in-depth articles and application examples.

The Community

Post questions on the Adobe forums. This is a good place to ask beginner- to intermediate-level questions and gain access to the Adobe engineering team.

Attend conferences. Many sessions cover the latest in technology. In fact, it is often the arena chosen by software companies to make announcements and give sneak peeks.

Be active. Share your work. If you demonstrate interest and knowledge, you may be invited to be part of the prerelease lists. This will put you in the privileged position of testing and making suggestions on beta products. Be aware of Adobe bugs so that you can find workarounds for them, and if you witness new bugs, report them at http://bugs.adobe.com/.

Find a user group in your area. If one does not exist, create it.

How Does It Run?

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 displayObject 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.

Figure 19-2. One frame in terms of code execution and rendering

Figure 19-3. A slower frame rate due to rendering

We covered rendering at some length in Chapter 14, so we will now focus on code execution.

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:

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;

}

The section Diagnostics Tools discusses other methods.

Improving performance

Change your application frame rate if it is idle or goes to the background. Revisit Chapter 6 for more on this topic.

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