BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

ART: The New Android Runtime

by Barry Burd on Jul 04, 2014 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Mono from Xamarin is also an alternative runtime for Android by Faisal Waris

Mono is a separate VM running in the same process as ART or Davlik (through some magic that I don't fully understand).

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 by J Davenport

I know this would be a breaking change, but honestly Google should just move to GO. If they dropped Java, they would free themselves of all the litigation issues they face from Oracle. GO would work perfectly well here. Apps would migrate. Abstraction frameworks like Titanium would paper over the issues. It would be better all around.

Re: Oh, just GO already by Dave Wieneke

You can lead the Javanians to GO but you can't make them to code..

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT