Detailed explanation of Android virtual machine Dalvik and ART

Android applications are written in Java/Kotlin. The Android virtual machine does not use JVM bytecode. Instead, the Class file is compiled into a dex file through the DX compiler (now replaced by D8), and then executed by the virtual machine;

In the eyes of the bottom layer, whether it is Java or Kolin, it is ultimately machine code that runs;

No more nonsense, let’s start the introduction

1. A brief introduction to Dalvik

1. Introduction to Dalvik virtual machine

Dalvik is a virtual machine designed by Google for the Android platform. The Dalvik virtual machine is one of the core components of the Android mobile device platform developed by Google and other manufacturers. It can support the running of Java applications that have been converted to the .dex (Dalvik Executable) format. The .dex format is a compression format designed specifically for Dalvik and is suitable for systems with limited memory and processor speed. Dalvik is optimized to allow multiple virtual machine instances to run simultaneously in limited memory, and each Dalvik application is executed as an independent Linux process. Independent processes prevent all programs from being closed when the virtual machine crashes.

2. The birth and death of Dalvik

• Android 1.0 uses Dalvik as the Android virtual machine operating environment.
• In Android 2.2, Google added a JIT compiler (Just-In-Time Compiler) to the Android virtual machine.
• In Android 4.4, Google introduced a new virtual machine operating environment ART. At this time, ART and Dalvik coexist, and users can choose between the two.
• In Android 5.0, ART completely replaced Dalvik as the Android virtual machine operating environment, and Dalvik exited the stage of history.

3. Dalvik Features

• The Dalvik virtual machine runs Dalvik bytecode, which is converted from Java bytecode and packaged into a dex file. The JVM runs class files or jar files.
• Fast loading speed, compared with Jar files, dex will integrate all the information contained in it, reducing redundant information. This reduces I/O operations and improves the class search speed.
• The Dalvik virtual machine is based on registers, while the JVM is based on stacks (operand stacks). Although register-based execution has good efficiency, it has poor portability and is difficult to cross platforms.
• The Dalvik virtual machine allows multiple processes to run simultaneously in limited memory. Each application runs in a Dalvik virtual machine instance and has an independent process space.
• The Dalvik virtual machine has a sharing mechanism, and different applications can share the same classes at runtime, which has higher efficiency.

2. ART virtual machine

1. Introduction to the concept of ART

• The ART virtual machine replaced the Dalvik virtual machine in Android 5.0. The way it handles application execution is different from the Dalvik virtual machine. It does not use JIT but uses AOT (Ahead-Of-Time), which is the advance compilation technology. The garbage collector has also been improved and optimized.
• The ART virtual machine was introduced as an option in Android 4.4, replaced Dalvik after Android 5.0, and underwent a series of changes in Android 7.0 and 8.0 respectively.

2. Basic concepts and terms

• .dex file: After all the Java source code of the App is compiled, many class files are generated. DX/D8 compiles them into one/multiple (multiDex) dex files, which are compiled and executed by the Android virtual machine.
• .odex file: The product of dex file verification and optimization. The odex file under art contains the code compiled by AOT and the complete content of dex. However, after Android 8.0, the dex content in odex is moved to the .vdex file.
• .art file: When generating odex file according to the configuration file under art, .art file is also generated at the same time. It is mainly to improve the speed of loading hot code in odex at runtime. It contains class information and index of hot method in odex. When running App, it will first load the compiled code in odex according to this file.
• Interpreter: It is used to interpret the code line by line when the program is running and translate it into machine code for the corresponding platform for execution.
• JIT compilation (Just In Time): Because the interpreter mode is too slow to run, it is introduced to perform real-time compilation (method-based granularity under ART) for frequently running hot code (the judgment standard is generally that the number of executions within a certain period of time reaches a certain threshold), and cache the JIT-compiled code in memory for the next execution. Since it is compiled at the method-based granularity (ArtMethod), JIT compilation can generate more efficient code and run faster than interpreters.
• AOT compilation (Ahead-Of-Time): All code is fully compiled into local machine code when the application is installed, and the machine code is directly executed at runtime.

3. How does ART work?

(1) 4.4~7.0

At first, ART only used AOT compilation. When the App was installed, all the code was compiled and stored locally. The App could be run directly after it was opened. The advantage of this was that the application ran faster, but the disadvantages were also obvious. The App installation time was significantly longer and it took up more storage space.

(2) 7.0

After Android N, ART was modified and JIT compilation was reintroduced, combining AOT/JIT hybrid compilation. The main mechanisms are as follows:

• No compilation is performed during installation. The first few runs are only interpreted by the interpreter. At the same time, hot code is JIT compiled and the relevant information of these codes is recorded in a configuration file.
• When the device is idle or charging, the compilation daemon reads the configuration file to perform AOT compilation on the hotspot code and writes it to the odex file corresponding to the app.
• After starting the application again, use the AOT compiled code first, otherwise use the interpreter + JIT compilation and repeat the process
• For some large apps, such as Taobao, some functions may not be used in your life. According to the above strategy, this part of the code will not be compiled and saved, thus reducing the storage space occupied. In addition, when the system is upgraded, it also avoids the time and space consumption caused by fully compiling all existing applications.

(3) 8.0

Android 8.0 introduced the .vdex file, which contains the uncompressed DEX code of the APK and some metadata to speed up verification.

4. ART Garbage Collector Optimization

• There is only one GC pause (Dalvik needs two).
• Concurrent replication reduces background memory usage and fragmentation.
• The duration of GC pauses is not affected by the heap size.
• In the special case of cleaning up recently allocated short-lived objects, the collector's overall GC time is shorter.
• Improved garbage collection ergonomics to enable more timely parallel garbage collection, which makes GC_FOR_ALLOC events extremely rare in typical use cases.

5. ART Timeline

• In Android 4.4, ART and Dalvik coexist, and users can choose between the two.
• Android 5.0 officially replaced the Dalvik virtual machine as the Android virtual machine operating environment. Dalvik withdrew from the stage of history, and AOT replaced JIT.
• In Android 7.0, JIT returns and adopts a mixed compilation mode of JIT and AOP.
• ART continues to update and optimize

6. What is the difference between Dalvik VM and ART VM?

• ART used AOT technology in the early stage and AOT+JIT hybrid in the later stage, while Dalvik used JIT.
• ART supports 64-bit CPUs and is compatible with 32-bit CPUs, while Dalvik only supports 32-bit CPUs.
• ART has improved and optimized the garbage collector to increase throughput.

Summarize

The core content can be summed up in one sentence: When the App is installed, the code is not compiled but only the legality is verified. It is executed through the interpreter at runtime, and the frequently run code is compiled and put into the memory cache and recorded in the local configuration file. The background thread compiles the method recorded in the configuration file and stores it in the .odex file. When the App is run again, the compiled code in the .odex file is read first, and then the process is repeated.