I use Flash to build game prototypes, and you can get some great performance out of the packager, but you have to be aware of certain things. First off, it might be tempting to think that an iOS device is just a slower version of a PC. You might think that if you make your code run fast on a desktop, then it'll run decently on iOS. And nothing could be further from the truth.
The biggest difference is on the desktop, when running flash, your actionscript is being JIT-compiled. Its being dynamically interpreted by the flash player and executed. When you are talking about flash, the actionscript is getting precompiled and executed. Its like the difference between optimizing Ruby vs C++. Understanding that your actionscript is going to be compiled down to the iOS instruction set and not interpreted on the fly means that performance bottlenecks and bugs will be different (sometimes very different) between deployment platforms.
A couple quick things that I've noticed:
Instantiating objects is painful, and slower than you might think. If at all possible use an object pool to reuse existing objects.
Combined with the last one, garbage collection is painful and non-deterministic.
Events are slow. Every time you dispatch an event you have have create a new instance, and then flash has a lot of overhead to capture and bubble that event around. Prefer simple callbacks (or even function objects) for simple event rasing.
Related to the last, only have one listener bound to Event.ENTER_FRAME. Have a centralized scene manager and takes care calling an
update() method on children. It may sounds like you are reimplementing the native flash display stack (which you are), but like mentioned the last point you are incurring a lot of overhead.
Prefer bitmaps over vectors. Vectors are drawn by the CPU, so every render frame the vector has to be redrawn... from scratch. Bitmaps (with the
cacheAsBitmap property) can be differed to the GPU.
Optimize your bitmaps for the device. If you are making an iPhone targeted game, dont make a character sprite sheet that is 256x256 pixels big if the character is only going to be 64x64 on the screen.
Learn to use
cacheAsBitmapMatrix. You can get a pretty decent performance boost using bitmaps and using this matrix for rotation and scaling over the simple
scaleY properties. In fact I would say, even if you aren't using
cacheAsBitmapMatrix still prefer
.transform.matrix for moving stuff around. If you are mathematically minded at all, then this will make your life so much easier.
Understand how bitmaps, filters, and cacheAsBitmap works in flash. Understand how they effect memory usage.
Prefer strongly typed variables over dynamically typed variables:
var x:uint = 0. Also mark your classes as
final if you aren't going to subclass it. There is a little performance boost for that.
Get Flash Builder 4.5 Pro over Flash CS5.5. Flash Builder (even as an Eclipse plugin/extension) is way more suited for this style of development, and its memory and cpu profiler is one of the best, and well worth the investment.
Lastly, watch this slideshow by grant skinner. Its probably one of the best over all references on ActionScript optimization. But pay close attention to the first few screens where he says "optimization without benchmarking is pointless". I cannot stress that enough. Learn to deploy your game and app to the device and get some instrumentation off of it. Benchmark it and see where you need to optimize before optimization.
But with all that said, iOS apps built by the flash compiler aren't inherently slow. But they are very different.
I haven't had a chance to get my hands on a flash 11 compiler for iOS, so I have no idea what the new molehill api will look like on an iOS device, or what other internal compiler optimization they have done between releases. But it will probably be an improvement.