The proliferation of cellular phones has revolutionized the way we communicate with one another and is the foundation for a more mobile lifestyle.

Adobe, a long time player in rich internet applications, wanted to, once again, be an active participant. As part of the Open Screen Project, it collaborated with multiple partners and will soon release Flash Player 10.1 to run on a large selection of mobile devices' browser. You can watch the related announcement made at the MAX 2009 keynote or read the article on Adobe Labs.

Apple has not been interested in such collaboration. Nevertheless, Adobe engineers put their minds together and delivered a solution to work around the problem. If the iPhone Safari browser will not support the Flash player, let's use the Flash tools to compile a native iPhone application (ipa) which lives directly on the device.

This initiative now gives the opportunity for ActionScript developers to develop applications for the wonderful iPhone and iPod Touch devices.

There has been confusion on the topic as many tend to think that Flash platform development translates to a swf running in a browser. Looking at the emergence of the AIR technology and its desktop applications, one could have anticipated that Adobe had a more ambitious outreach (and one could imagine an AIR store opening soon).

What this article is about
This article will explain some of the engineering behind the magic of an ActionScript project appearing on your desktop as an ipa. It will describe how what has changed under the hood affects your source code. It will go over some best practices to develop for devices with small CPUs such as the iPhone and other smartPhones.

This article is not about features (except for a few new ones specific to the device), nor current issues like performance or bugs, as both topics are in constant evolution while the team is working on the tool. Flash Professional CS5 Beta, which can publish a project to an ipa, should be available on Adobe labs by the end of the year.

Different toolchains
In order to understand the new toolchain, the set of software tools or programs to create a product, let's review the current one then discuss what has changed to create iPhone applications.

Typically, the compiler, which is a set of programs, converts a high-level language to machine code, a low level language (also called native code for a specific platform). Machine code instructions can then be passed directly to the Central Processing Unit. One of the job of the compiler is code optimization, in particular using less memory storage and executing commands quickly.

The toolchain for standard Flash, Flex or AIR applications is as follows:

When you publish your project, your source code is converted by the ActionScript compiler to ActionScript bytecode (ABC), a condensed, binary format. The bytecode is wrapped inside a Shockwave Flash File or swf, a binary container. In an AIR application, other included elements are external assets (app:/assets) and a configuration file (app.xml).

At runtime, the ActionScript Virtual Machine or AVM2 converts the bytecode to native machine code, process called bytecode compilation. It is highly portable because the process is done for a specific platform/hardware configuration. To improve performance, the Just-in-time compilation (JIT) technique is applied, evaluating and optimizing one line at a time (dynamic code execution). The AVM also works as an interpreter when it cannot do JIT.

The toolchain to create an iPhone application using the Flash tools is:

To create iPhone applications via the Flash tools, no interpreter or dynamic language are used. The toolchain uses the Low Level Virtual Machine architecture, an open source, modular compiler system capable of generating machine code for various targets (it is used by Apple for its desktop compilation). Adobe built a new compiler front end for LLVM to understand ActionScript 3. And LLVM uses its existing back end to output ARM assembly code. The optimization is done using the Ahead-of-Time compilation technique (AOT), compliant with Apple licensing terms.

The native ARM (iPhone CPU) code is wrapped in an iPhone executable along with a swf for some libraries and flash assets, external assets (app:/assets) and a configuration file (info.plist generated from app.xml by .plist gen) for information such as initial orientation.

The AIR Developer Tool (ADT) is used to add the certificate information (signature process required by Apple to validate developer and application) at the final step of creation. To test your application on your device and then to submit to the Apple store, follow Apple specifications. Nothing is changed there.

At the time of writing, it is not clear which libraries have been added by Adobe. We can assume the inclusion of garbage collection, audio play, video play, rendering engine and 2.5D calculation. Note that this is not final. Adobe may well make changes before Flash CS5 ships.

AOT impact on your source code
Even though ActionScript is a high-level language, it might be useful to understand some of the workings of AOT. This by no means implies that you need to understand a low-level language to develop for the iPhone.

• Except for your root swf, you cannot embed other swfs with bytecode at runtime (you will get an error in Flash CS5 that you are attempting to run un-compiled ABC). Using a SWC is fine. In simple terms, everything in your code must be accessible immediately.

• Unlike JIT in Flash Player which only compiles the functions that are called, AOT compiles all functions into machine code and generates one function for each AS3 function. Unused code increases the size of your application, particularly because the machine code for an AS3 function is much larger than its equivalent AS3 byte code. Go over your code carefully and remove all unnecessary properties, functions and classes.

• Currently AOT does not optimize Vector as well as JIT does. Use them carefully. Review your knowledge of these objects. Some methods, such as slice or concat, return a new Vector which reduces memory performance and increases garbage collection overhead.

• When a compiler runs through your code, it takes all your classes, methods and properties and store them in memory, typical in address tables. If a class is final, a function is final or a property is static, they are stored in memory address's fixed offset. Access to a fixed offset is immediate and saves time at runtime.

• Everything else is dynamic and stored in a dynamic address which requires one or more lookups at runtime. For instance, if a class is not final, the chain of subclasses is traversed to determine where a method or property is. The look-up process involves calculating the offset of where the property or method information is kept. Be careful not to confuse the notion of "dynamic" here with our AS definition which is to add or remove properties at runtime.

• Use type annotation. You may have heard this over and over since AS3 was introduced but indicating the data type as part of a variable declaration will reduce the look up at execution time. In short, if you use type annotation, the program doesn't need to verify the type when its value is changed or keep a list of functions from that type.

• Making a function call requires less memory and calculations than event listeners. It is not necessary to abandon everything you have learnt to use. The event model is familiar and convenient but be aware that it required several memory allocations for the event itself and other objects related to its specific structure.

• Inline is putting a function right where it is called rather than jumping to it. This avoids the consequences of function invocation (memory and RAM consumption using the program stack being one of them). This is particularly significant for a "for" loop where invocation may happen may times.

Adobe is currently researching ways to improve optimization. Some of the compiler techniques which are being investigated are: improvement of the performance of Array objects, identifying classes that are not overridden and marking them as final, optimization of the whole program to remove unused methods and classes.

Best practices
Some of what is discussed here could be applied to any project but is particularly significant for devices with small CPUs. On average, mobile CPU is a 10th of the speed of the desktop processor. RAM is also slower and limited. The program stack is reduced. However, many current iPhone applications work well so delivering a good experience should be your goal. Target the appropriate development environment for what you are trying to achieve (this article doesn't mean to negate that xCode is an ideal tool for iPhone development).

• Test often. If you find an issue or a bottleneck, fix it. Then move on to the next phase. Adobe is currently building tools to debug and trace. It is particularly difficult to fine tune touchEvents because they can only be testing on the device.

• Allocating new blocks of memory is expensive especially for a device with limited memory. For the iPhone in particular, declare your objects up front, right after you click on the default screen. Re-use objects instead of deleting them and creating new ones. If you delete an object, stop all its processes first or it may still execute code until it is garbage collected. The garbage collection overhead itself should be a focus. When a collection is triggered, it consumes memory and may delay time critical events, such as a targeted animation or catching touchEvents. On a side note, Adobe is working on improving the garbage collection although as an independent task from the CS5 build.

• Keep your displaylist depth small. Minimize nesting. If you don't want to show an object, do not make its visible property false as it will still update. Instead, remove it from the displayList.

• Beware of deep recursion. The stack consumes RAM which is precious and limited.

• Avoid using the drawing API all together. It is very taxing. Use bitmaps rather than vector graphics. The vector renderer imported from Flash currently performs poorly but bitmap manipulation and composition is very fast. Avoid masks, filters and blends.

• Note that if you want to develop an application for the desktop and the iPhone, you can check the NativeWindow.isSupported property. IPhone applications cannot use or create native windows and returns false.

• PixelBender is not available. It is a runtime only type of animation.

Augmented Rendering Pipeline
To supplement the Flash rendering model which is too slow for fast animation, a new property was added to take advantage of the device hardware acceleration and allow high performance composition.

CacheAsSurface is the property of a displayObject. When set to true, a bitmap representation of the object is cached and kept across various transformations including translation, rotation, scale, 3D transforms and alpha changes. It is stored in video memory as a texture and takes the load off of the CPU and puts it onto the GPU (Graphics Processing Unit). The property must be applied to the object itself and at the most discrete level.

GPU compositing takes a grab of your screen and keeps it as a GPU texture. Any images that don't change stay as textures. Changing content must be re-rendered. It is an expensive system so use it when fast rendering is needed.

It works best with fewer pixels than more graphics, in another word, lots of small objects will render better than several large objects. Avoid objects with edges of many details.

Some new features
The initial build does not support all the APIs we are familiar with but the list is growing as the product gets closer to a public beta launch and will be reported formally at that time. Note that some AIR specific APIs are also available such as the SQLite database and file system.

Some multi-touch specific events were added:

• flash.events.TouchEvent when the user touches the device. Unlike the click of a mouse, up to five touchEvents can be detected simultaneously. For that reason, each touch is assigned a touchPointID along with its x and y coordinates. The amount of pressure applied can also be measured.
• flash.events.GestureEvent captures familiar gestures on the device such as pinching, zooming in and out.
• flash.events.AccelerometerEvent displays updates from the device accelerometer sensor. It works with x, y and z axis to detect movement in space.
• flash.events.GeolocationEvent displays updates directly from the device location sensor. It contains latitude, longitude but also altitude, speed and heading (compass movement).
• flash.events.StageOrientationEvent displays orientation updates including right, left and upside down. Your application can be initialized as a specific orientation (landscape or portrait) then ignore orientation change.

In closing, I expect that this technology will bring mobile content to a new level by making the iPhone platform accessible to creative developers. I hope that this article will help you develop your applications.

Special thanks to Scott Peterson and Chris Brichford for their MAX session which inspired this article, Edwin Van Rijkom for the review on compilers, Ben Garney, Colin Holgate and Satyen Mehta for editing. Lastly I would like to thank Mike Chambers and Adobe for inviting me to participate in Notus (alpha pre-release for this product).

Read more from Veronique Brossier.