What Is ART & How Is It Different From Dalvik Virtual Machine On Android?

In the world of technology, new terminologies and abbreviations are nothing new, and at times, with every new release of even existing software, you might see a new term coining up that everyone seems to use and understand. The problem for beginners and even a lot of casual users, however, is that they neither fully understand what the new connotation means, nor can they easily find out about it on their own from official sources, primarily owing to the fact that developers aren’t too keen on explaining many such terminologies and their technical details. At best, you’ll get pointed to an official link that does provide an explanation, but in such technical terms that it’s pretty much useless to a non-techie.

We at AddictiveTips have always taken pride in dumbing down technical concepts and providing answers in terms that are agreeable to the casual user and the tech beginner. Hence, when Google decided to introduce ART with Android 4.4 KitKat, we saw this as an opportunity to introduce our readers to the new runtime environment and help everyone understand what all of this is about, and how is it different from the Dalvik virtual machine that ART is being built to replace.

What is a Runtime Environment?

Before we get to answering the actual question, we need to understand what a runtime environment actually is. To put in simplest terms, runtime comprises of software instructions that execute when your program is running, even if they’re not essentially are a part of the code of that piece of software in particular. These instructions basically translate the software’s own code into the code that the computer is capable of running. Therefore, all computer languages require some sort of runtime environment that can properly execute the code written in that language.

Android makes use of a virtual machine as its runtime environment in order to run the APK files that constitute an Android application. The advantage of using a virtual machine is twofold – firstly, the app code is isolated from the core operating system, ensuring that should something go wrong, it’s contained in an isolated environment and does not effect the primary OS. And secondly, it allows for cross-compatibility, meaning even if an app is compiled on another platform (such as a PC, as is usually the case with developing mobile apps) , they can still be executed on the mobile platform using the virtual machine.

For Android, the virtual machine-based runtime environemnt in use so far is known as the Dalvik Virtual Machine, which, I’m sure anyone who’s ever digged into the details of the OS, is more than familiar with.

Why Use a Virtual Machine at All?

That’s actually the point that we touched just above. Virtual machines are slow, there’s no denying that, but they actually hold a couple of advantages that make them a favored choice.

• Virtual machines supply an isolated environment for code execution. Hence, even if an app contains a malicious piece of code that can damage the core OS, it won’t directly affect the system files, and thus the core OS will be kept from getting corrupted. The large scale benefit is more stability and reliability for the operating system.
• The app APKs that are supplied through Play Store (or any other source, for that matter) are uncompiled instructions that developers rely on the virtual machine to compile before execution and run on the device. This provides more compatibility; if the developer were to provide already compiled code and it was compiled for a Snapdragon-based processor, it might not run correctly on a Tegra chip, for instance. Hence, this on-the-device compilation addresses this issue.

So, What’s Dalvik, and What’s Wrong With It?

That is the question to ask, isn’t it? Dalvik has been there since Android started back in 2007, and it hasn’t changed much since then, apart from the Just-In-Time (JIT) compilation approach approach introduced in Android 2.2 Froyo, which basically compiles apps right when they’re launched, or when the user supplies the necessary instructions. It’s useful, as well as an improvement over the previous conventional interpreter approach that compiled and ran code line by line as it ran, but the downside is a huge overhead when the app is being launched for the first time.

This is because the system needs to pull together all the necessary files, compile the app and load it to RAM. As long as the compiled app stays within the RAM, it will continue to respond snappily, but when you load more apps and the RAM runs out, the first one gets unloaded and hence, upon subsequent launch, the whole process starts over. The approach makes sense on paper, and in fact, has been working fine until now for the platform. However, older devices with limited RAM suffer the most, because the loading/unloading cycle continues more often, and hence, the system feels slow in terms of overall responsiveness. That’s where the new virtual machine, ART, comes in.

What is ART & How Does It Improve Things?

ART, or Android RunTime (pretty lame name, yeah, we know) is a new experimental virtual machine that Google has introduced with Android 4.4 KitKat as a developer option (with Dalvik still being the one set as default for now). The primary difference between ART and Dalvik is the compilation approach that both of these use – ART employs a new Ahead-Of-Time (AOT) concept contrary to Dalvik’s JIT, which basically compiles apps before they are even launched. What this means is that first-time installs will take longer, and apps will occupy more space on internal storage, but at the same time, since the app will be fully compiled as soon as it’s installed, launch times will be much faster. Likewise, since the compilation part is taken care of just once at the time of install, processor taxing is lower, which results in better battery life and overall performance.

Dalvik Vs. ART – Comparison

Let’s just do a quick comparison of both the virtual machines before moving ahead.

You Say ART is Experimental…

Yes, and right now, it’s available only on devices with Snapdragon chipsets and running Android 4.4 KitKat. You have the option to switch from Dalvik to ART from the hidden Developer options, should you desire, but be advised that some of your apps might not work properly. Also, if there’s an app cache already built under Dalvik, the first reboot after making the switch may take up to half an hour.

Google has primarily made ART available with KitKat for developers to play around with, and establish the grounds for a permanent switch in the future. And this by no means implies that ART is ready for use today. It will be in the future, but for now, it’s experimental and not fit for daily use by the end user.

As for the benefits of ART, there are mixed reports. For most reviewers, the test devices comprise of quad-core processors with over 2 gigs of RAM, which is a more than adequate setup to truly observe the speed gains from ART. Still, random users report gains upwards of 50% in speed and more than 30% in battery life. Still others claim it’s nothing more than a placebo effect.

In all fairness, nothing can be said before it becomes available to masses and loses the experimental tag. Hence, we’ll save that debate for later. What can be said at this point with certainty is that ART is the future. Google is going to go with ahead of time compilation in order to truly match iOS, it’s biggest counterpart, and ART is going to pave the way. No matter how silly the name might seem or how incomplete it is right now, we’ll continue to see ART more and more.

Read Full Bio

Aatif Khan

Follow me on Google+

Latest from Author

This Tweak Lets You Customize How Screenshots Are Saved In iOS [Jailbreak] Enable T9 Input On iPhone 5s Dialer [Jailbreak]