ART vs. Dalvik runtimes in Android

Key takeaways:

• Dalvik was Android’s default runtime before version 5.0, using a just-in-time (JIT) compiler for on-demand code compilation.

• ART (Android runtime) replaced Dalvik as the default runtime from Android 5.0 onwards, using ahead-of-time (AOT) compilation for precompiling code during installation.

• Dalvik’s JIT approach was memory-efficient but slower due to runtime compilation, while ART’s AOT approach improves app startup and performance.

• Dalvik virtual machine (DVM) uses optimized .odex files to speed up app execution.

• ART generates .oat files that store precompiled machine code, resulting in faster app performance and reduced runtime lag.

A solid grasp of runtime environments is pivotal in Android development. Dalvik and ART stand out as two prominent runtimes, crucial in converting high-level language code into machine-level code.

Let’s discuss the differences between Dalvik and ART, highlighting what makes each unique and beneficial.

Dalvik

Before Android version 4.4 KitKat, the default runtime was Dalvik, which utilized a just-in-time (JIT) compiler. This compiler dynamically compiles only the necessary parts of the code when needed. This approach helped save memory space, making it ideal for devices with limited storage capacity. However, this on-demand compilation process could sometimes slow down performance since it happened during actual use. Despite this drawback, it remained a preferred option for devices with low storage. In contrast, Dalvik’s method of compiling after installation made it slower compared to JIT.

Dalvik virtual machine (DVM)

In Android development, we turn Java and Kotlin code into bytecode files. These files are then optimized to run smoothly on Android devices. The final step involves creating .odex files, which make apps faster and more efficient on Android’s Dalvik virtual machine (DVM). Let’s discuss each step in detail.

1. Java or Kotlin code compilation:

   1. Java code is typically compiled using javac, while Kotlin code is compiled using kotlinc.

   2. Both compilers generate Java bytecode files (.class files) from the source code.

2. Conversion to Dalvik bytecode:

   1. The Java bytecode .class files are then passed to the dx tool (Dex compiler) provided by the Android SDK.

   2. The dx tool converts the Java bytecode into Dalvik bytecode .dex files, which are optimized for execution on Android’s Dalvik virtual machine (DVM).

3. Optimization of Dalvik bytecode:

   1. The .dex files generated by dx are then optimized by dexopt.

   2. dexopt generates optimized Dalvik bytecode files, typically with a .odex (optimized Dalvik executable) extension.

   3. These optimized .odex files contain pre-compiled bytecode, improving the application’s performance by reducing the need for on-the-fly optimization by the DVM.

   4. These optimized files are stored in the /data/dalvik-cache directory on the device.

4. Handling of .odex files:

   1. The .odex files are used by the Dalvik VM when executing the application.

   2. They help speed up the application’s startup time and improve overall performance by reducing the overhead of bytecode optimization during runtime.

ART

ART, or Android runtime, marks a shift in runtime technology. Initially introduced experimentally in KitKat and later adopted as the default runtime in Android 5.0 Lollipop, ART utilizes an ahead-of-time (AOT) compiler. Unlike JIT, which compiles code on-the-fly during runtime, ART precompiles the entire code during installation. This proactive approach drastically enhances app startup times and eradicates the lag often encountered while running apps on the device. Therefore, rather than dealing with relatively concise Java code, we contend with larger bytecode or machine code.

ATR Runtime

The first two steps (Java or Kotlin code compilation and conversion to Dalvik bytecode) are the same.

1. Dex code processing:

   1. Dex code is passed to dex2oat for optimization and compilation.

   2. In the Android runtime (ART) environment, the integration of dex2oat is pivotal for optimizing and compiling .dex files into .oat files containing machine code in the ELF format. This process is initiated during app installation, where ART utilizes the on-device dex2oat tool to compile apps.

2. Generation of .oat files:

   1. dex2oat, found within Android devices, convert .dex files to compiled app executables, enhancing performance by translating bytecode to native machine code. OAT files, standing for “Optimized Android Translated,” store this precompiled code, improving app loading and runtime performance in ART.

3. Utilization by ART:

   1. These .oat files, also known as native code, are utilized by the Android runtime (ART) to improve app loading times and runtime performance.

The key difference lies in how Dalvik compiles on the go, whereas ART compiles everything upfront during installation, fundamentally altering Android’s app execution process. Now, let’s explore the comparison across various parameters.

The latest Android operating system versions typically support both runtime environments, Dalvik and ART. While Dalvik may still be available for compatibility reasons, newer Android devices and applications primarily leverage ART for its performance benefits and optimization capabilities. Users generally do not need to manually select a runtime, as ART is automatically used by default on compatible devices.

Quiz

A quick quiz to test your understanding of ART and Dalvik runtimes in Android.

Conclusion

In conclusion, while both Dalvik and ART have their advantages and trade-offs, ART’s ahead-of-time (AOT) compilation approach generally offers better performance and efficiency compared to Dalvik’s just-in-time (JIT) compilation. With AOT, ART can optimize code during installation, resulting in smoother app startup times and reduced memory consumption. Therefore, for modern Android devices and performance-critical applications, ART is often considered the better choice.