Dalvik vs. ART: Android Virtual Machines
A huge advantage that devices powered by the Android operating system have over virtually every other OS is the use of a virtual machine in which apps run. Yes, virtual machines, but we’ll get to those in just a moment. What makes all this relevant now is the decision by Google to include a new runtime in Android 4.4 KitKat — one that promises to make your device faster, your battery last longer, and give you thicker, more manageable hair. Wait, not that last one.
Before we jump into this brand new VM, and why it’s turned off by default, let’s make sure everyone understands what we’re talking about.
What’s a virtual machine?
Physical machines are just that: physical. They’re tangible, you can touch them. They’re the computer under your desk, the notebook on your lap, the server in the closet down the hall. When you think of a computer, this is what you’re probably picturing.
Virtual machines?! “Heyya! It’s all ball bearings nowadays!”
Virtual machines aren’t physical, but they do run on physical hardware. Confused yet? Say your desktop computer is a Mac and you’re running some flavor of OS X. You’ve got a couple programs that you want to run that don’t work in your OS. You might want to load up a couple virtual machines and install Windows into one and Linux into another. These virtual machines emulate all the hardware that is needed for you to install and run an operating system. You can literally run a complete Windows environment in a window on your Mac, and the same goes for Linux or almost any other operating system. Pretty cool, eh?
Other than the obvious, one of the main advantages of utilizing a virtual machine is the physical separation of each environment. Apps that run in the VM are separate from those running in the host environment. Viruses, malware, and even crashed apps are all kept apart from your main OS, insulating you from the implications of such occurrences. Another advantage of VMs is the ability to run programs written for one architecture on a box that runs something different. For example, the ability to run programs compiled to run on an ARM-based CPU when your computer is running an Intel-based processor.
To better illustrate that last point, let’s take a look back at Windows Mobile and Pocket PC. Back then developers would write their apps, then compile them for several platforms: ARM version 4, Intel XScale, MIPS, or SH3 CPUs. Each processor had its own advantages and disadvantages, but they all required separately compiled versions of every app that you hoped to run on any one of them. When Pocket PC 2002 was announced, Microsoft standardized on ARM.
Today’s Androids use a specialized virtual machine in which they run their apps. Developers write code which you, the end user, install from the Play Store or some other source. This code is mostly uncompiled. That means it’s slower than compiled code would be, but your device gets the “insulation” advantages that VMs provide, and developers don’t have to worry about re-compiling their code to run on some other CPU — like a new tablet, PC, TV, watch, or even a rice cooker.
JIT vs. AOT
When you install an app on your Android today it will use the Dalvik VM to compile and run it. This process utilizes a concept called just-in-time, or JIT. It’s a great concept, but one that has quite a bit of overhead when you first launch apps.
Let’s take the process apart and see how it works. You download and install an app to your phone or tablet. It sits there on your internal storage until you launch it. When you do, Android pulls all the uncompiled data together, compiles it, and loads the app into memory (RAM). As long as the app is there, after the initial load time, it’s pretty snappy. If you use a task killer, manually kill the app, or navigate away and load up other apps, the first app is unloaded, freeing up the RAM it had been using. When you go back to it, it’s got to go through the whole process all over again.
ART should increase performance by… “Moon River! … Yeah, breathe easy. Using the whole fist, Doc?!”
Android 4.4 KitKat, at least on the Nexus 5, includes a new runtime call “Android runtime”, ART. Though it’s not a very creative name, it is pretty creative in what it does. Unlike JIT, which must compile every app whenever it’s loaded, ART works on a concept called ahead-of-time (AOT) compilation. With ART, when you download and install an app it automatically pre-compiles. This takes up more space on your device and takes longer to initially install when compared to Dalvik. However, apps launch quicker and are arguably faster when run using ART rather than Dalvik. What’s more, since less time is required to run apps, your processor doesn’t get worked as hard and your battery life may benefit as a result.
All that sounds great, right? It is! Or, rather, it will be.
ART is experimental
Experimental? No more than a white guy with an afro playing for the Lakers!
The benefits? Some sources are reporting a 50% increase in speed. Others say it’s closer to 100%. Many claim they’ve seen their battery life increase by 25% or more! Still more say that all of this is likely just a placebo effect, and the reality is much less noticeable. So, we’re not going to go on the record with a bunch of synthetic benchmark scores between Dalvik and ART, nor are we going to claim you’ll see a huge improvement in everything. Not right now anyway.
Sure, I tried ART for a few days. It was fabulous, and horrible, and not noteworthy — all at the same time. Feel free to try it out yourself, just don’t expect that it will be fantastic. Not now.
AOT compilation is the future, and ART is the way Google is going to get us there. This is just the first little step toward a much more lofty goal. Perhaps ART will be the standard runtime in Android 5.0?
Your turn
Have you played with ART on your Nexus 5? Did you notice anything good, bad, or ugly? Let us know your experience with AOT compilation in the comments below!
CherryPickS"S" 