Charles Brian Quinn
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.
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.
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.
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.
ART means improvements for developers as well:
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.
Interested in learning more about our basic and advanced Android Courses?
Learn from the experts at a Big Nerd Ranch Bootcamp!
Interested in leveling up your coding skills from the same authors of the Big Nerd Ranch Guide? Subscribe to The Frontier today!
Charles Brian Quinn