ART vs Dalvik Introducing the New Android Runtime in KitKat

As a part of Android 4.4 KitKat, Google decided to introduce a new way of executing apps on top of the Android operating system. Let’s take a closer look at what this new runtime, called ART, brings to the table.

ART is Google’s 2-year-long ongoing secret project, which aims to boost the performance of our Android devices. It’s based on the premise that modern devices are pretty powerful in terms of CPU speed and memory capacity, especially in comparison with the first generation of Android devices.

ART is a new Android runtime being introduced experimentally in the 4.4 release KitKat. This is a preview of work in progress in KitKat. It is available for the purpose of obtaining early developer and partner feedback. – Android developers

In other words, ART is still an ongoing project, considered too unstable to be introduced as a standard runtime. Luckily, there is no special hacking involved to get it running.

You can choose to use it by going to “Settings> Developer Options> Select Runtime” and choosing ART.

Hmmm, but why would I want to make the switch?

Android apps are deployed in Dalvik bytecode, which is portable, unlike native code. In order to be able to run the app on a device, the code has to be compiled to machine code.

Dalvik is based on JIT (just in time) compilation. It means that each time you run an app, the part of the code required for its execution is going to be translated (compiled) to machine code at that moment. As you progress through the app, additional code is going to be compiled and cached, so that the system can reuse the code while the app is running. Since JIT compiles only a part of the code, it has a smaller memory footprint and uses less physical space on the device.

ART, on the other hand, compiles the intermediate language, Dalvik bytecode, into a system-dependent binary. The whole code of the app will be pre-compiled during install (once), thus removing the lag that we see when we open an app on our device. With no need for JIT compilation, the code should execute much faster.

Except for the potential speed increase, the use of ART can provide an important secondary benefit. As ART runs app machine code directly (native execution), it doesn’t hit the CPU as hard as just-in-time code compiling on Dalvik. Less CPU usage results in less battery drain, which is a big plus for portable devices in general.

Let’s take a look at the downsides of AOT compilation.

First of all, the generated machine code requires more space than the existing bytecode. Moreover, the code is pre-compiled at install time, so the installation process takes a bit longer. Furthermore, it also corresponds to a larger memory footprint at execution time. This means that fewer apps run concurrently.

When first Android devices hit the market (like HTC Magic shown in the picture), memory and storage capacity were significantly smaller and presented a bottleneck for performance. This is the reason why a JIT approach was the preferred option at that time. Today, memory is much cheaper and thus more abundant, even on low-end devices, so ART is a logical step forward.

The guys at Android Police made some nice benchmarks, and if you are interested in the exact numbers, check out the following link for more info.

Let’s take a quick overview of the results of their benchmarks:

Pretty neat, don’t you agree? There is one more hidden, but very important benefit of ART. When you ask iPhone users how they feel about the look and feel of Android smartphones, they often complain that Android feels laggy, despite the fact that hardware on both phones is top notch. Perceived lag/delay is the result of JIT compilation and it more or less disappears after switching to ART.

At the moment, there are reports that some apps are currently not working when you switch to ART, such as Whatsapp and Titanium Backup. I personally witnessed Whatsapp crashing each time on app startup, so I switched back to Dalvik again.

Being an Android developer, each time I make some changes that I want to test, I have to install a new app instance on the device. As stated before, ART uses AOT compilation, which prolongs the install times of applications because the Dalvik bytecode gets compiled to machine code. Therefore, each time I deploy a new version of the app on my device, I have to wait for this additional time to pass so that the app optimizes for the ART runtime. This causes a significant delay in the deployment process.

Install times on my Nexus 4, for one of our larger projects, jumped from ~17 s to ~25 s.

Personally, I saw an improvement in the speed and smoothness of scrolling in apps. ART makes the UI feel more responsive. At this time, Android ART is not fully optimized. I expect even better results in the future, after Google acquires more feedback and makes additional optimizations. As I see it, end users will definitely benefit from the switch, once ART matures and gets more stable. However, developers, who frequently deploy apps, will feel more intensively the negative impact of prolonged install times.

Android 5.0 with ART fully functional? I surely hope so!