Android development initially used Java as the primary development language, but Google now officially recommends using Kotlin for copyright reasons. But both Java and Kotlin need to be compiled into bytecode, optimized for Android, and run in an Android virtual machine. The JVM was designed primarily for computers, and running it directly on mobile devices has many problems, such as power consumption. The Android VIRTUAL machine has also been optimized for mobile devices.

This article briefly compares the JVM to the Android virtual machine.

There are two types of virtual machines.

  1. System VIRTUAL machine: A complete VIRTUAL machine (VM) that simulates real hardware, such as VirtualBox and VMware.

  2. Processing virtual machines: Execute programs by parsing instructions. The main goal is to provide a platform-independent environment.

JVM vs DVM

Java virtual machines fall into the second category and provide a platform-independent Java code execution environment, one of which is run by parsing bytecode.

The JVM workflow can be referred to primarily in the article “A Brief Introduction to JVM 4: Classloading Mechanisms,” which will not be detailed here.

The Android system uses VMS to run upper-layer applications for two reasons:

  1. Security: The application layer code runs in the VM and is completely isolated from other system codes to ensure the security of the application and system.

  2. Platform independent: The same code can run on different architectures (ARM, MIPs, x86).

The Android Virtual Machine is called Dalvik Virtual Machine (DVM), which can execute Dalvik EXecutable bytecode and convert it from Java bytecode using dx/ D8 tool. During the conversion process, the memory and processing speed were optimized. This is equivalent to compiling.dex files from multiple.class files into APK.

Stack vs register

As we’ve analyzed in previous articles, the JVM is a stack-based virtual machine, while the DVM is register-based. Register-based virtual machines use fewer instruction sets, less code, and fewer memory operations, so they also perform better.

This difference means that the Android VIRTUAL machine’s instruction set is more like move instructions in assembly language than push and pop instructions in JVM.

DVM vs ART

ART is used to replace the earlier DVM, and ART also uses dex bytecode for compatibility with previous programs. However, dex bytecode is converted to OAT local code using dex2OAT during installation.

Among other things, ART has optimized garbage collection mechanisms, faster local method calls, greater power savings, faster application launches, better runtime performance, and more.

You can look at the following figure to see how apK files differ after installation on different virtual machines.

JIT vs AOT

Just In Time (JIT) has a mechanism In the JVM that was added to the virtual machine In Android 2.2. This is a mechanism for runtime optimization of hot code, which means that when the VIRTUAL machine finds that some code has been run enough times, it compiles the code to machine code and runs the machine code the next time it executes the code. This optimizes program performance.

Ahead of Time (AOT) compiles bytecode to local machine code at application installation Time. This reduces runtime compilation time and improves runtime performance. However, the installation time and storage space are increased.

conclusion

We briefly compare the similarities and differences between the two virtual machines. Now that you have the knowledge covered in this series, you have the theoretical knowledge to write your own virtual machine. How to write a VIRTUAL machine? We’ll have a chance to talk.

Expand the data

  • Android runtime
  • Dex File Format
  • Dalvik instruction set