Before we talk about this feature, let me give an overview of Shared and Captive runtimes.
- Shared Runtime – A runtime that is installed as a separate application and can be used by multiple applications.
- Captive or Embedded Runtime – A runtime that is embedded within the application and is only used by that one application.
With shared runtime when an AIR Android application is launched a dialog is shown to install/update the runtime if AIR runtime is not installed or not updated, and this being an extra step is not a great experience for the application users.
Starting with AIR 3.7, application developers will be able to host their secondary SWFs on an external server and load them on demand as per their application logic.
Till AIR 3.5, loading of only assets such as images, videos and SWFs without actionscript code, commonly referred as Actionscript Byte Code(ABC Code), from external server was supported. The workflow for the application developer for loading such assets from server resembles the diagram below :
With AIR 3.6, the feature for loading of locally packaged secondary SWFs containing ABC code was introduced. The detailed description about this feature and its usage can be found at this blog – “Packaging and loading of multiple SWFs for AIR apps on iOS“. The workflow for the application developer using this feature is described in the diagram below:
In AIR SDK 3.6 for iOS, there is a new feature that allows application developers to be able to package and load secondary SWFs that contain ActionScript byte code (or ABC) in their apps. Presently, due to certain restrictions on iOS, AIR on iOS requires that all the ActionScript code of an application be present in the main SWF or the root SWF. With this feature, an application developer can have ActionScript code in local secondary SWFs and package them along with the main SWF.
This post will talk about a small optimization that developers can do within their code to reduce the amount of time taken for AOT compilation of their application I would recommend developers to read this post to understand what is meant by AOT compilation.
One of the intermediate steps in AOT compilation requires LLVM to process the LLVM bytecode and to optimized LLVM bytecode. In case one of your function has a lot of actionscript code (~30000 lines) then the corresponding LLVM code is around 1.3 million lines. LLVM is known to perform badly (compilation time) on large functions. As a recommendation, actionscript developers should break down on large function into smaller functions to reduce the AOT compilation time. They need not change any code, just break a large function into many smaller functions to reduce AOT compilation time significantly.
Traditionally, computer programs can be executed in three possible ways – interpreted, static (ahead-of-time) compilation and Just In time (JIT). In interpreted mode, the code is translated from high-level language to low level language during execution whereas in ahead-of-time compilation the high-level language code is converted to low-level machine code before hand. JIT (Just in time) compilation is a hybrid approach of the two. Here the code translation into native code occurs during the execution time and the translated code is cached so that this conversion need not be done every time. Obviously there is a small penalty when compared to ahead-of-time compilation as there is a cost associated with this translation.
After this brief introduction lets get into the Adobe AIR world and what is there in it for an iOS AIR developer. SWF content on all platforms other than iOS is JIT compiled, whenever possible. The swf is downloaded locally and JIT compiled where possible. Continue reading…