Difference between Dalvik and ART runtimes in Android

Background

If you own an Andorid device with Kitkat you would already know this. You have an option of choosing between the runtimes - 

• Dalvik
• ART

What is runtime you ask? -  Think of it as a library that takes care of converting the code that you write in a high level language like Java to machine code that the processor/cpu will understand. Android uses virtual machine as it's runtime (like JVM) which makes it "write once run everywhere".


From Android L (5.0) ART has been made as the default runtime (ART has completely replaced Dalvik).

For my device running Kitakat it looks like the following -

The goal of this post is to understand these runtimes so that you can choose the appropriate one (in Android kitkat). Before proceeding to the details I would recommend read more about JIT (Just in time) compilation. You can see the JIT section in my following post -

• Difference between Compiler, Interpreter and Assembler

 History

Lets step back a little and see how did we reached to ART. We all know Dalvik was used as the virtual machine. In it's simple form consider Dalvik as JVM optimized for mobile platforms. Later from Android 2.2 (Froyo) JIT compiler was launched (which Dalvik used) to further optimize and improve applications performance. JIT allows code to be directly compiled to native code (unlike interpreting it every time) and use the same thereafter. JIT did these only for so called "identified hotspots" (typically code snippets getting executed very frequently). So still major code was interpreted and need was felt to further optimize and improve performance of Android application and hence from Android 4.4 (kitkat) ART was introduced as a runtime and from Android 5.0 (Lollipop) it has completely replaced Dalvik. 

Android Architecture with ART looks like -

So Dalvik used JIT(Just in time) compilation where as ART uses AOT (Ahead of time) compilation. Lets see what that is.

 AOT (Ahead of time) Compilation and ART

We all know android apps come in .apk format. You essentially write you code in Java (.java classes) which are bundled in apk files. While application gets bundles your java classes are converted to bytecodes (.dex) files. This is common for both Dalvik as well as ART. Difference is what comes next.

In JIT/Dalvik every time an application is launched byte code is interpreted line by line. If a routine or function is identified as hotspot it is directly compiled to native code by JIT with optimization. This leads to time and memory footprint overhead as this is done on the fly when application is running. The JIT compiled code is then run directly everytime thereafter (no interpretation needed) which increases the performance.

In AOT/ART when application (.apk) file is installed entire byte code is converted to machine code and stored in the persistent storage. As this is on installation this happens only once. Every time the application is launched this machine code is directly executed. No need of interpreter. yes it takes more storage space as compiled native code is stored in the storage but takes less CPU and less RAM (memory footprint).

As per Wiki,

To maintain backward compatibility, ART uses the same input bytecode as Dalvik, supplied through standard .dex files as part of APK files, while the .odex files are replaced with Executable and Linkable Format (ELF) executables. Once an application is compiled by using ART's on-device dex2oat utility, it is run solely from the compiled ELF executable; this approach eliminates various overheads involved with JIT compilation, but it requires additional time for compilation when an application is installed, and applications take up slightly larger amounts of space to store the compiled code

Following diagram should clear everything I just explained above - 

Benefits of ART

• Reduces startup time of applications as native code is directly executed.
• Improves battery performance as power utilized to interprete byte codes line by line is saved.
• As JIT is not in the picture no on the fly compilation and native code storage. This significantly reduces memory footprint (less RAM is required for application to run).

Drawbacks of ART

• As dex bytecodes are converted to native machine code on installation itself, installation takes more time.
• As the native machine code generated on installation is stored in internal storage, more internal storage is required.

Related Links

• Android Programming Basics
• What does a just-in-time (JIT) compiler do?(SO)
• Difference between Compiler, Interpreter and Assembler
• ART Wiki