In this tutorial, we’ll be discussing the runtime environments used in Android. We’ll see the differences and how it is improving for the betterment of android applications execution.
Runtime Environment consists of software instructions(generated from the code) that are used while executing the programming.
JVM is the component that is used to convert bytecode into machine code in order to run Java-based programs.
Why is a Virtual Machine need to run any Application?
- A Virtual Machine isolates the execution of the program from the OS. Thus protecting malicious code from affecting the system files.
- Virtual Machines execute code independent of the CPU architecture
Dalvik Virtual Machine (DVM) was specifically designed to run Android applications initially.
Why Android uses DVM and not JVM?Mobile Environment is not as powerful as your computer systems(majorly). There are battery and ram constraints. DVM was specifically optimized in order to run on Android.
JVM uses a Stack-based model.
DM uses a Register based model.
Difference between Stack-based and Register-based Models
Stack-based Virtual Machines have the memory structure of the type Stack.
Register-based uses registers of the CPU to store the operands. So along with the operands, their address is also stored.
A Register based model does not require any pushing and popping of instructions. Hence instructions execute faster.
Register-based models are good at optimizing as well. They can store common subexpression results which can be used again in the future without the need to calculate. This is not possible in a Stack-based model.
Before looking at the Dalvik Virtual Machine, let’s look at the JVM:
Following is the flow of JVM:
Following is the flow of DVM:
We know that DVM is specifically used for low memory devices.
The Dex compiler (
dx tool) converts the .class files generated from the javac compiler to .dex file.
These .dex files are then converted to machine code.
Note: dexopt tool which is a part of the DVM converts the dex file into .odex file format.
JVM runs the bytecode of pure java classes while DVM runs the bytecode of the dex formatted .dex file that was recompiled from the Java bytecode.JVM dynamically loads the bytecode for each class from the corresponding .class file. While Dalvik bytecode is only composed of one .dex file, containing all the classes of the application.
How is the dex bytecode converted into machine code?
Using JIT(Just In Time).
Just In Time is a component that takes application code, analyzes it, and actively translates it into a form that runs faster, doing so while the application continues to run. This leads to increased launch time for applications since it needs to be done everytime the application is launched.
As the execution progresses, more bytecode is compiled and cached. This leads to faster boot times.
DVM and JIT were replaced by ART and AOT respectively since Android Lollipop.
dx tool was responsible for it.Since Android Studio 3.1.0, D8 tool has released. It goes a step ahead of dx and builds faster and the .dex file generated would be smaller. Thus APK size would be smaller.
Since Android Studio 3.2.0 R8 tool has been released as a code shrinker. It’s a step ahead of Proguard and is used to convert Java bytecode to dex whilst shrinking and obfuscating code.
android.enableR8=true in gradle.properties.
Android Runtime has replaced DVM since Android Lollipop. ART uses Ahead of Time Approach (AOT) instead of JIT.
Using AOT, the dex files are compiled before they are needed. Usually, they are done at installation time only and then stored in phone storage.
Let’s look at the change in flow using ART:
ART vs DVM
ART uses AOT based approach and DVM uses JIT.
Increased installation time, increased reboot time, increased storage.
- Battery Performance: ART largely increases the battery performance compared to DVM since the dex bytecode is not interpreted every time.
- Storage : On installation, the AOT stores the precompiled binary in phone storage directly. Hence DVM is more suited for phones with low storage.
- Boot Time: ART causes a slower reboot time since the cache is built at first boot, hence rebooting device takes significantly longer.
- Application Launch Time: DVM has a slower launch time for the applications. ART has the native code ready to execute thanks to AOT. Hence is super fast.
- Garbage Collection: ART has much better Garbage collection than DVM. In DVM the heap is more fragmented. Whereas ART uses a different heap for storing large objects such as Bitmaps. Moreover, ART has a concurrent compacting Garbage collector and is able to compact the heap easier compared to DVM
Android Nougat reintroduced Just In Time Compilation with code profiling along with AOT, and an interpreter in the ART thus making it hybrid.
This is done in order to tackle problems such as initial installation time and memory.
Using the Hybrid Runtime, there won’t be any compilation during install, and applications can be started right away, the bytecode is interpreted.
Now with ART and the new JIT the application installation is faster.
The new JIT constantly does profiling and improves applications as they run.
In Android P ART, Kotlin optimisations are also enhanced.
That brings an end to this tutorial.