When moving beyond the desktop, where the ability of the system to express, size of the screens and the relative resources available to Flash are roughly equivalent, special considerations need to be made when deploying the same or equivalent content on devices that have a fundamentally different interaction model (mobile=touch interface, small screen and maybe a keyboard and whereas television input might be limited to a 5-button remote but offer up a large display area and fast h.264 decoding but at the same time being sluggish when it comes to animating content). As well, while mobile devices are challenging from a resource perspective, televisions are even more so.

What's not immediately clear is at what point offering up different SWF's becomes important. Does it make sense to offer up a different SWF for every single device or to re-leverage a single SWF universally? Certainly, both are possible and at the same time either extreme has costs associated with it.

The downside of offering a different SWF for each and every device out there is that the on-going costs associated with maintenance and updates increase significantly, as well as organizational issues related to source version control.

And while it's possible to offer a single SWF for all target devices, doing so could have consequences in the short-term. In the long-term, a lot of these issues will be resolved by the use.

• Design-time optimizations that are made to satisfy mobile performance issues or real estate challenges won't translate well back into the desktop experience.
• Since the interaction models are fundamentally different, certain aspects which are helpful on desktop (such as rollover) actually make the usability worse on a mobile device and provide misleading visual cues to the user.
• The image assets that are appropriate for a mobile device (small, takes up less bandwidth) won't be appropriate for a high-definition 50" LCD. So, you're stuck with 3 options: embed small image assets and pixelate the heck out of them when scaling up, embed large image assets and scale the down, incurring the filesize bloat, or using an asset management system to deliver the right-sized assets.
• The best practice that appears to be emerging is to target one SWF for desktop, another for mobile devices and another for set-top boxes.

Gaming Display Recommendations

There are two fundamentally different display/interaction modes for Flash on mobile devices:

• Embedded – content is likely to be more exposed to the potential for gesture ambiguity, D-PAD and trackball issues, as well as orientation and content sizing issues. This is the default display mode for Flash in the browser. Even if the user zooms into the Flash content, they will most likely be able to see some HTML content in the periphery.

• Full Screen – similar to the same mode on the desktop, the user must initiate full-screen mode (by tapping a button within your movie). Flash will go full-screen, inform the user of the same (and some hint how to escape it (by hitting the back button) – but with the caveat that you basically can't use the device's keyboard (neither the physical keyboard nor its virtual one). In this display mode, only Flash content is displayed.

5-point Input Controls

• The DPAD and trackball both emit arrow-based events: 37 (left), 38 (up), 39 (right), and 40 (down)
• Both controls automatically align with the device orientation. In other words, when in landscape, pressing the left-most DPAD button (or pressing trackball to the left) will generate 37(s).
• On the Motorola Droid, opening the keyboard tray forces the orientation to be in landscape, regardless of how the phone is physically oriented.
• The DPAD will emit a single onKeyDown() and onKeyUp()M event for each button pressed. In the latest version of the Flash Player 10.1.61.69, pressing the CENTER DPAD button is the same as hitting ENTER.
• The trackball will emit multiple OnKeyDown()s and KeyUp()s for each thumb-swipe, thumb-zing, or whatever you want to call the action where you spin the trackball. It will approximate the vector of the spin. So for example, if you spin up at 45 degrees, you will probably see the events clustered together: up, right, up, right, up, right, up, right or if you spin straight up, you should see something similar to up, up, up, up, up (anywhere from 4-8 on average), pressing the trackball down is the same as hitting ENTER.
• I was able to confirm that AS2 logic using Key.addListener() is working as expected, used this URL for testing: http://flash-creations.com/notes/asclass_key.php

Accelerometer

The accelerometer is only available in AS3 applications. While it might be available in a future release for AS2, it won't be for 10.1.

Also, when contemplating how you might use an accelerometer in an application, consider that you can't lock content in portrait mode when in a browser. However, see an interesting hack in the orientation section, below.

You can specify the accelerometer notification interval – and upon each accelerometer event that gets generated, you'll get three numbers that correspond to acceleration in the X, Y and Z axii.

• Note that if the phone is perfectly level and is still, you should get values (0, 0, 1) – because the Earth is always exerting a gravitational pull equivalent to 9.8 meters per second2 (1G).
• muted is always false for Android devices (no way to disable accelerometer)

Here's the bare-bones code snippet:

import flash.sensors.Accelerometer; 
      import flash.events.AccelerometerEvent; 

      var gravity:Number = 9.8 // 1G = 9.8 meters per second 
      var xAcc:Number, yAcc:Number, zAccNumber; 
      var xVel:Number, yVel:Number, zVel:Number ; 
      var friction:Number = 2; 

      function init():void { 
         if(Accelerometer:isSupported && !Accelerometer.muted) { 
            var acc:Accelerometer = new Accelerometer(); 
            acc.setRequestedUpdateInterval(100); // in 
      milliseconds 

      acc.addEventListener(AccelerometerEvent.UPDATE,handleAccele 
      ration); 

      acc.addEventListener(AccelerometerEvent.STATUS,handleAccele 
      rometerStatus); 
         } 
      }
      function handleAcceleration(event:AccelerometerEvent):void 
      { 
       xAcc=event.accelerationX; 
       yAcc=event.accelerationY; 
       zAcc=event.accelerationY; 

       xVel=calculateVelocity(xVel,xAcc,gravity,friction) ; 
       yVel= calculateVelocity(yVel,yAcc,gravity,friction) ; 
      zVel= calculateVelocity(zVel,zAcc, gravity, friction) 
      ; 

       … 
      } 

      function 
      handleAccelerometerStatus(event:AccelerometerEvent):void { 
      // double check the isSupported and muted flags 
      }

Drag and Drop

• Don't require the user to drag objects that are small or require that their placement be precise – especially in the absence of additional feedback than that which is typically offered on the desktop.
• Do use an auxiliary zoom lens that shows what the content under the finger looks like.
• Do use visual and/or auditory feedback to let the user know that they are either over a valid drop area, or where the object’s placement would be if they let go immediately.

(note: this section should be compared with the content found in the Resources section, above – some content may overlap)

• Hardware accelerated rending not always available, and is required for pixel bender to work
• Use standard and alpha blend modes -- but avoid others, particularly layer
• Avoid morphing shapes as these have to be re-tesselated on each frame (expensive)
• Complex or finely articulated shapes are more expensive to render than large simple shapes
• Avoid large changes in scale
• Avoid over-drawing (when relying on hardware acceleration) although it's fine when rendering using software
• Set background color of stage instead of putting a large rectangle in the background
• Avoid default bitmap fill mode
• Simplify vector graphics
• Use CacheAsBitmap for content that doesn't change frequently but avoid it for content that does change frequently.
• Avoid filters
• Carefully picking bitmap sizes if content will need to be sized down&hellipmipmap rule
• …but ideally, the content would always be 'right-sized'
• Turn smoothing on if reducing image scale (does impact performance)

• Old School Polygonal Data Structures (available as source)
• Consider using polygonal labs data structures --highly optimized
• Newer Highly-optimized polygonal data structures (only available as a SWC):
• Object Pooling

(note: this section may overlap with content found in Resources)

There are two common performance sinkholes in Flash content:

• onEnterFrame event listeners – it is not uncommon for there to be a lot of un-necessary processing that happens on each frame, which can quickly become very CPU expensive.
• Timers – timers are also frequently abused. Try to keep the number of Timer objects to a minimum, be preferential to using them in objects that are likely to be around for a while (for example, shy away from creating a Timer class for each game avatar, as tempting as it might be). Challenge yourself to see if you can accomplish everything you need with a single Timer class instantiation.

Recommendations

• Implement a Timer manager class
• Single Timer instance
• Multiple Timer subscriptions -- but guaranteed to fall on even boundaries.
• Timer resolution is configurable
• Organize timers in groups so that they can be suspended/resumed/destroyed as a group.
• Consider replacing object-based event listeners with iteration loops.
• Avoid using many timers
• onEnterFrame vs. Timer
• Dynamically throttling the frame rate

• When animating multiple objects simultaneously, perform the delta operation as a single pass

  For example: in a re-make of the Asteroids game, you could create the ship and four big asteroids (n=5) -- placing a Timer object on each game object. When each Timer emitted a tick you could update the position of its parent. However, that results in [n] separate rendering events. It would be more efficient to make a single rendering pass in order of dependencies (if dependencies exist) updating all of the object positions and triggering just a single display refresh. This should result in a higher effective frame rate.

• Consider using an open source Tween library, such as TweenLite or TweenMax
• Use event notifications to react to keyboard events, don’t create loops that check to see if a certain key is pressed or not.

(note: this section should be compared with the content found in the Resources section, above – some content may overlap)

Remember that the best practices for developing a game are not always going to agree with, and in fact will sometimes be in contradiction to best practices for other types of applications.

There is a natural tension that exists between some of the recommendations in this section that seek to optimize run-time efficiency and other, equally valid forms of efficiency, such as the amount of time it takes to write, troubleshoot, and maintain the code. Well-accepted OOP practices such as black-boxing functionality may have long-lasting payoff, but there is a small yet noticeable performance tax that results.

However, one best practice is always recommended, regardless – and that’s to use strict (or strongly-typed) AS3 in your projects. Not only does it make troubleshooting easier but because of the way Flash’s virtual engine works, strict AS3 code actually runs more efficiently than its counterpart AS2 or loosely-typed AS3.

Referencing

• Eliminate weak references: e.g. asteroid["velocity"] should be asteroid.velocity;
• Coerce untyped data (such as configuration data from an XML file) into the anticipated datatype before attempting to access
• If using a data element more than a couple of times, use a local variable to bypass the cost of a lookup
• Replace explicit or implicit Object datatype instantiations such as asteroid = {x:x_pos,y:y_pos}; with a more explicit class definition: asteroid = new Asteroid(x_pos,y_pos,asteroid_type)

Arrays

• Use ByteArray instead of Array for byte/short/int values
• If you store value objects in an array, coerce them back into the original value object class before attempting to access any of its members, for example, replace x_pos:int = asteroids[i].x; with x_pos:int = Asteroid(asteroids[i]).x;
• Better yet, if all of the elements in an Array are the same data type or same class, then use the Vector class

Comparisons

• Use bytes and bit operators to manage game object boolean states (canBeDestroyed, absorbsShot, activelyFiring, isCloaked, etc.)
• Use hard-coded constants in lieu of the 'const' data type: while it decreases the readability/maintainability of the code, it is also more efficient.
  public var type:uint =3; instead of public const FORCEFIELD_TYPE:String="standardForceField"; as the latter form results in a string comparison (comparatively expensive)

Math

• Use long-hand notations for functions such as Math.min(), Array.push(), Array.shift(), etc. to avoid the function call penalty:
  • replace var n=Math.abs(n) with if (n < 0) n = -n;
• Use a++ (four times) or a+=4 in in lieu of a=a+4;
• Use a=a-4 in lieu of a-- 4 times or a-=4;
• Use multiply instead of division (b*.5 instead of b/2)
• Shift left and shift right in cases where you need to multiple or divide by a power of 2
• Coerce to uint instead of using Math.floor, and if appropriate int is even faster

• Recast int calculations as Flash runtime will sometimes cause the outcome of calculations to become a Number.

  var x_pos:int;
  &hellip
  x_pos = x_pos * acceleration;

  should be

  var x_pos:int;
  &hellip
  x_pos = int(x_pos * acceleration);

• Instead of

  y = Math.sin(Math.PI/180*i);

  use fast inline trigonometric functions

Iteration

• Replace for loops with while loops. For example, instead of:

  for(var i:int=0;i<1000;i++) { data[i]=func(i);}

  do

  var i:int=0;
  while(i<1000) {
  data[i++] = func(i);
  }

• Instead of

  var v1:Number=10;
  var v2:Number=20;
  var v3:Number=30;

  do

  var v1:Number=10, v2:Number=20, v3:Number=30;

• Remember that removing a child from a display list (e.g. stage.removeChild(demon);) neither destroys the object nor does it stop the object from consuming resources. So adding and removing asteroid sprites that have an onEnterFrame listener or use a Timer() object may continue to consume resources until the timers are stopped/destroyed and you remove the EnterFrame listeners that may have been created, even if all explicit references to the object have been lost.

• Replace anonymous function closures with method closures. That is, replace

  var f:Function = new function(event:Event) {trace("handler");}

  with

  function f(event:Event):void {
  trace("handler");
  }

• haXe is a potential solution to the inherent conflict between performance and maintainability of a game: http://haxe.org/doc

See Flash Sizing Zen document

Tip: When applying a blur filter with ActionScript, using values for blurX and blurY which are powers of two (such as 2, 4, 8, 16, and 32) can be computed faster and offer the benefit of a 20–30% performance improvement.

Once trick I learned while making some flash games is that a higher framerate on the fla file does not translate into smoother gameplay. In fact, you want the framerate as low as possible so that the main loop has adequate time to compute. I found a solid 18 fps actually looks better visually than an inconsistent 24-30 fps.

Following is from:
http://www.bigspaceship.com/blog/labs/flash-performance-tips-part-i/

Masks Are Bad
Well, they're not all bad. Masks can be exceptionally useful, as we all know by now. They're the #1 performance killer though. When you mask something, you force the player to decide what needs to be rendered and hidden every single frame. So how do you get around without masks? With a little bit of patience and tricky layering (such as making the background the foreground with a giant hole cut out for where your viewable area is) you'll be able to get the same end result without the performance hit.

Alpha PNGs and Video
Same deal as the masks. Sometimes it's unavoidable, but you're still asking the player to figure out what to render under the alpha. Sometimes we'll make an alpha video at half size and then scale it in Flash. You'd be surprised how good it still looks.

Oh, and with regards to alpha video: Try experimenting with PNG sequences in place of the alpha video. Video usually performs a little better, but its always worth looking into.

Frame Rate
Despite all discussions otherwise, there is no magic framerate. We use 25 or 30 because (as far as I know) we like it best. At some point we tested and determined one was slightly better than the other, but generally speaking this is not going to be the primary cause of a site running slow. I wouldn't generally advise going higher than 30 though, just because you're asking the player to render an awful lot awfully fast…

cacheAsBitmap and BitmapData
Where possible use cacheAsBitmap to rasterize vector items. You'll force Flash to draw the symbol one time and then never again. On the flip side, if you're scaling or rotating a symbol NEVER set it to cacheAsBitmap. Then you force Flash to render AND recapture the raster every frame, making the process slower instead of faster.

With sites like the Da Vinci Code and Nike Air, we would take a dynamic screenshot of the section, draw it into an empty movieclip and then manipulate the screenshot to animate it out. This is far, far faster than animating many elements out, or animating over top of many elements. I highly recommend this practice.

_visible is better than _alpha
_alpha = 0 and _visible = false are totally different things. Alpha determines the opacity of a clip. Visible determines whether or not the clip should actually be rendered by the player. If you're setting something all the way invisible, use the _visible property.

onEnterFrame and setInterval
When you're through with these processes, clear them from memory with onEnterFrame = null; and clearInterval(myInterval); respectively. Leaving these around when you're not using them is like leaving the telephone off the hook when you're done with a call.

Pre-define your math
Got a sine wave you're about to draw? Is it the same sine wave every time? Hard code the numbers into an array. By doing the math for Flash, you're saving some complex processes in advance. I even experiment with using a Tween that I nextFrame() thru to get all of the entries into an array before hand.

Game Persistence
The following questions are obviously true for AIR, but it’s interesting to think about whether or not the same issues apply to in—browser content.

"What these results show is that people want mobile games to be 'pick up and play', and use them to fill time, as opposed to committing a large amount of time to playing them. It is therefore important that game designers facilitate this method of game playing, and make it easy to pick up and play games. The main elements of this are:"

• Fast start up time (from app load to actually playing)
• low number of extraneous menus to navigate before playing
• app resumes from where it left off
• app shuts down quickly, but doesn’t lose progress

-- http://www.stevebromley.com/blog/2009/10/23/mobile-games-should-start-quickly-lets-get-down-to-business/