The Android Open Source Project has recently seen commit activity indicating that the Android Runtime (ART), included in KitKat, is going to very soon replace Dalvik, which has been executing your apps since the beginning of Android. If everything goes according to plan, users will not notice a thing. Developers shouldn’t have to do anything at all if they only use the Android SDK, and make minor updates if they use the NDK improperly.

Here’s a bit of history of the two, and some ideas of what Android “L” may contain.

Dalvik’s Sunset

Let’s go back to 2009, when Dalvik was a brand-new virtual machine. Phones had small amounts of disk space, and even less RAM, so bytes were at a premium. At this point, 64-bit architectures were not ubiquitous, and virtualization as a whole was just beginning to take off. Full ahead-of-time compilation wasted valuable space in memory and on disk, especially when a largely touted feature of Android at the time was that each app could run in a completely independent virtual machine. Java-style .class files would be converted into one .dex file, which, when it was installed on the device, would be optimized, or “odex’d,” for that specific device. This allowed completely unused sections of code to be no-opped out, saving even more space. There were also various other optimizations generally involving trimming off unneeded bits here and there in the bytecode.

Today, all of this optimization for space is finally coming back to “byte” us. Now that devices have gigabytes of RAM, and many tablets have more space than my first laptop, all of this optimization is for naught. Dalvik no longer provides advantages against the traditional Java virtual machine, and is no longer being worked on.

ART Theory

If we get to go back and reinvent a virtual machine that is fed Java, what should we do? The optimal VM would run Java code just as fast as its functionally equivalent native code. It would also need to completely break away from the traditional JVM in response to the Oracle lawsuit.

To meet this need, the Android team has come up with ART: the Android Runtime Environment. The biggest change from Dalvik is ahead-of-time compilation. On installation, ART compiles the bytecode down to machine code that can be run on the bare metal of the device. Floating point performance and UI responsiveness are the most noticeable improvements resulting from this process. Everything else is still up in the air until ART matures.

Why Should Consumers Care?

Android Runtime will mean a faster experience for users:

• Ahead-of-time compilation = speed. Overhead has been moved to install time and is no longer needed while the app is running.

• Improved garbage collection = speed. Eliminating interruptions in the UI thread of apps, even when they are tiny, makes the UI feel much smoother.

• Development and debugging improvements = speed. Once developers are able to profile their apps on ART devices, they will be able to find sections of code in need of attention way more accurately than before, which should result in those sections being fixed more quickly.

In summary, ART = more speed. Theoretically, ART could also improve battery life, but right now it is on par with Dalvik.

Why Should Developers Care?

ART means improvements for developers as well:

• Apps should not get paused for garbage collection before ALLOC, even in low-memory situations.
• Better messages when a NullPointerException is encountered: ART tells you what method the code tried to access.
• Fewer interruptions from garbage collection in general.
• Better performance in Java SDK code for floating points (Linpack performs ~10% better) and integers (Machin’s Formula for Pi calculation performs ~10% better). Here’s a full report on ART performance. Traditionally, if you were bottlenecked on performance, the only way to improve would be to switch to the NDK. Now, you might get a free speed boost when ART becomes default.

Possible Issues with ART

• Apps that consist of large amounts of NDK code, especially if the Java-NDK boundary is crossed often, will likely need fine tuning in order to avoid impacting performance.
• Dalvik didn’t complain when performing illegal storage of pointers to Java objects, but with ART, your app will now force close.
• OpenGL/3D performance has taken a slight hit in the current iteration.

I’m looking forward to ART. Just remember to take everything here with a grain of salt, as it is still very much under active development and can change largely at any time. I hope to find out more at Google I/O, and publish future posts with more info.

Kurt Nelson and Kristin Marsicano will be attending Google I/O. Meet them at the conference or at our Android Community Party tonight.