ART: The New Android Runtime
At Google I/O 2014, presenters Brian Carlstrom, Anwar Ghuloum, and Ian Rogers (all from Google) discussed ART (the Android RunTime). ART replaces Dalvik as the default platform for the next Android release. (A preview of the next Android release, termed Android L, is available as a download for developers. Android L will go public sometime in the fall.)
Dalvik was created in the mid-2000s when mobile devices had relatively little processor speed and limited RAM. Accordingly, Dalvik doesn't take advantage of today's mobile hardware, which has better CPUs and GPUs, more RAM, and enhanced screen resolutions. In contrast, the newer ART platform is designed to take advantage of multicore architectures and 64-bit instruction sets.
Dalvik uses just-in-time (JIT) compilation -- a scheme in which parts of the code are translated during the run of an app. The advantage of JIT is that it keeps an app's memory footprint fairly small when the app isn't running. The disadvantage is that the simultaneous translating and running of an app slows the apps performance. The new ART platform sacrifices memory in favor of speed by using ahead-of-time (AOT) compilation. With ART, all the code belonging to an app gets compiled before the run of the app begins.
Another big improvement in ART is in the garbage collection algorithms. Dalvik does garbage collection in two phases. In the first phase, Dalvik pauses all threads in order to analyze the heap. In the second phase, Dalvik pauses threads again in order to clean up the heap. As a result, the typical pause for garbage collection in Dalvik is about 10 milliseconds -- enough to create jank in the application's performance. (The term "jank" refers to the jerky movement of elements on the screen. Often, an app compensates for its poor performance by dropping frames during an animation. This frame dropping is a significant cause of jank.)
ART's improved garbage collection algorithms pause threads only once. This reduces the typical slowdown from 10 milliseconds to about 3 milliseconds. In addition, ART's memory allocation routine (called rosalloc) does less locking than the allocator in Dalvik. The result is a lot less stuttering at runtime due to memory management.
Unlike Dalvik, ART supports 64-bit processors. About 85 percent of apps currently posted at Google Play are 64-bit ready because they contain no native (NDK) code.
In many scenarios, the primary reason for having 64-bit support is increased RAM size. This isn't a factor for Android because no mobile devices on the horizon have more than four gigabytes of RAM. But when ART runs in 64-bit mode, it uses some instructions that aren't available on 32-bit processors. These 64-bit instructions perform tasks faster than their simpler 32-bit counterparts.
The bottom line is that apps running on ART are faster than apps running on Dalvik. How much faster? During the sessions at Google I/O, I saw numbers ranging from 10 percent faster to 300 percent faster. For many benchmarks, a 30 to 80 percent speedup was the norm. But at an informal gathering sponsored by the Big Android BBQ folks, I saw the same app run on three devices. With all other things being equal, one device was running Dalvik, a second device was running 32-bit ART, and the third device was running 64-bit ART. On the Dalvik device, the performance wasn't tolerable. On the 32-bit ART device, the animation was better, but still somewhat "janky." On the 64-bit ART device, the animation was smooth, with no perceptible stuttering in the motion of any objects.
Mono from Xamarin is also an alternative runtime for Android
Subjectively, Mono feels much faster than Davlik. Anecdotally, I was able to process 10,000+ proto-buf messages / sec over Bluetooth (Samsung S3). Equivalent Java code, running on Davlik, does not seem to match that speed or come even close. In this case the BT stream connection was through Java but the rest of the processing was in Mono (F#).
I believe the Unity game engine also uses Mono under the covers.
Oh, just GO already