We all know that a platform without many apps isn’t very attractive. As far as mobile computing platforms are concerned, Android is somewhat uniquely positioned when it comes to apps. Most platforms require their apps to be compiled for the particular processor tucked neatly inside the device. This has some significant advantages, not the least of which is speed. Programs that are written and compiled for one particular architecture are generally much faster, more responsive, and a lot less “laggy” than devices that go through a middle-tier — like Android does. Google’s working on that with a new runtime for Android. When talking about ART versus Dalvik, the switch-over may happen sooner than you might think.
Some of you might remember with fondness the early days of Windows CE and Pocket PC. Back then “apps” were called “programs”, and we didn’t get them from a central Play Store or market place. Instead, we had to find them on our own, then download them from the author’s website. But we had to know which version to get. No, I’m not talking about version “3.0″ versus “2.0″, or anything like that. Instead, we all had to know what kind of chip ran inside our PDA. It could be a RISC-style MIPS, SH3, or ARM CPU.
These mobile processors were a significant change in infrastructure from the CISC-style chips that powered our desktop computers. Even today we have x86 and x64 that run our desktop computers (not to mention some more exotic flavors like i64). If you want your program to take advantage of everything x64 brings, for example, you have to recompile and redistribute it. Your users have to remove the x86 version, and replace it with the x64 version. (These two are a bit interesting in that x64 can run x86 programs, but in a sort of “compatibility mode”.)
On our mobile devices, if you switched from one device to another, you could very possibly switch from MIPS to ARM or SH3. Doing so meant you’d need to go back and re-download your programs for the chip in your new device. (Hopefully the author didn’t “go out of business” in the meantime.) It was a painful inconvenience not only for users, but for authors, too.
Instead of writing and compiling code for a specific chip, Java introduced a new concept: a virtual machine. Okay, so it wasn’t particularly “new”, but the way Java presented its “write once, run anywhere” approach was pretty novel — and very appealing. Android took this idea and ran with it, over time developing the Dalvik VM. Think of this as a layer that sits between the code and your system. Sure, a bit of overhead is added, but the flexibility and future-proofing of this approach is well worth it!
Over time Dalvik, which served its purpose well, has started to show its age and is in need of an overhaul. Google decided to re-write rather than simply “improve” upon its solution, and came out with ART in Android 4.4 KitKat.
ART is a bit faster and somewhat gentler on power use (and therefore battery consumption) than Dalvik, but it’s an early beta. At least that’s what we were led to believe!
I’ve been running ART since almost the first day that KitKat was released for my devices. It’s not groundbreaking, but it is an improvement. It’s still rough around the edges, and most of us didn’t expect that ART would replace Dalvik anytime soon.
However, looking at recent commits to the AOSP (Android Open Source Project), there’s some pretty strong evidence that ART could become the default runtime when the next version of Android lands.
The change in the commit is a simple one, it sets ART as the default and downgrades Dalvik to the alternate — the opposite of what we see today. This change to the master branch of the Android sourcecode is a good one and could mean that ART is almost ready for primetime. Sure, the commit could be reverted, and the next version of Android is still some way off in the future, but I’m still hopeful that Google’s new ART could be giving Dalvik the boot sooner than you might think!