Understanding how code is executed on the Android platform requires a closer look at the various runtime environments and bytecode formats that power its applications. At the heart of this system are three key components: the Java Virtual Machine (JVM), the Dalvik Virtual Machine (DVM), and the Android Runtime (ART). Each plays a distinct role in how Android apps are compiled, optimized, and run on devices.
What Is Bytecode?
Before diving into these execution environments, it’s important to understand what bytecode is. Bytecode is a low-level set of instructions designed for efficient execution by software interpreters. It serves as an intermediate representation of source code after compilation, allowing programs to be platform-independent . In Android development, Java code is typically compiled into bytecode before being translated into a format suitable for mobile execution.
The Role of the Java Virtual Machine (JVM)
The JVM is the traditional environment for executing Java applications. When developers write Android apps using Java, their code is first compiled into Java bytecode, which runs on the JVM during development or testing. However, JVM bytecode isn’t directly compatible with Android devices, so additional translation steps are necessary before execution on mobile hardware .
Enter the Dalvik Virtual Machine (DVM)
Android initially relied on the Dalvik Virtual Machine (DVM) as its runtime environment. Unlike the JVM, which uses Java bytecode, the DVM executes Dalvik bytecode stored in .dex (Dalvik Executable) files. These files are optimized for mobile environments with limited memory and processing power. The DVM was specifically designed to handle multiple virtual machine instances efficiently, making it well-suited for resource-constrained devices .
However, one notable drawback of the DVM was its reliance on Just-In-Time (JIT) compilation, which translated bytecode into native machine code at runtime. While this approach saved storage space, it could lead to slower app performance due to repeated translation processes .
The Shift to Android Runtime (ART)
With the release of Android 5.0 Lollipop, Google replaced the DVM with ART (Android Runtime), bringing significant improvements in performance and efficiency. Like the DVM, ART executes .dex files, but it uses Ahead-Of-Time (AOT) compilation to convert bytecode into native code during app installation rather than at runtime . This results in faster app launches and smoother execution since the translation process occurs only once.
Additionally, ART introduced better garbage collection mechanisms and enhanced debugging features, further improving the developer experience and end-user satisfaction . Although ART initially required more storage space due to precompiled code, subsequent updates have introduced hybrid compilation models combining AOT and JIT techniques to optimize both speed and storage usage.
Key Differences Between DVM and ART
| Feature | DVM | ART |
|---|---|---|
| Compilation Model | Just-In-Time (JIT) | Ahead-Of-Time (AOT) |
| Performance | Slower app startup due to runtime translation | Faster execution due to precompilation |
| Garbage Collection | Frequent pauses during memory cleanup | Improved GC with fewer pauses |
| Storage Usage | Lower storage footprint | Higher initial storage use |
| Compatibility | Limited support for modern Java features | Better support through improved toolchains |
Conclusion
The evolution from JVM to DVM and finally to ART reflects Android’s journey toward optimizing performance while maintaining compatibility across a diverse ecosystem. Developers today benefit from ART’s advanced compilation strategies and runtime enhancements, ensuring a smooth and responsive user experience across a wide range of devices . Understanding these underlying technologies not only demystifies how Android apps execute but also highlights the platform’s continuous innovation in mobile computing.
