What is the Dalvik VIRTUAL Machine
Dalvik is a Java virtual machine designed by Google for the Android platform. As an important part of the Android platform, Dalvik Executable supports the running of Java applications in DEX format. Dex is a compression format designed specifically for Dalvik, suitable for systems with limited memory and processor speed. Google has made specific optimization for Dalvik, making it efficient, concise and resource-saving. As can be seen from the Android system architecture diagram, Dalvik VIRTUAL machine operates in the Runtime library layer of Android.
As a Linux-oriented virtual machine designed for embedded operating system, Dalvik is mainly responsible for object life cycle management, stack management, thread management, security and exception management, and garbage collection, etc. Also, Dalvik didn’t have a JIT compiler in the early days, and it wasn’t until Android2.2 that JIT support was added.
Ii. Characteristics of Dalvik VIRTUAL Machine
Small size, small memory space;
Proprietary DEX executable file format for smaller size and faster execution;
Constant pool uses 32-bit indexed values, addressing class method names, field names, constants are faster;
Register based architecture, and has a complete instruction system;
It provides important functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.
All Android programs run in the Android system process, and each process corresponds to an instance of Dalvik VIRTUAL machine.
Third, the difference between Dalvik VM and Java VM
There are many differences between Dalvik VIRTUAL Machine and traditional Java virtual machine. The two are not compatible. Their significant differences are mainly reflected in the following aspects:
The Java virtual machine runs Java bytecode, and the Dalvik virtual machine runs Dalvik bytecode.
Traditional Java programs are compiled, generate Java bytecode and store it in a class file. The Java VIRTUAL machine runs the program by decoding the contents of the class file. Dalvik VIRTUAL machine runs Dalvik bytecode. All Dalvik bytecode is converted from Java bytecode and packaged into a DEX (Dalvik Executable) file. The Dalvik virtual machine executes these bytecodes by interpreting the DEX file.
Dalvik executables are small in size. The Android SDK has a tool called DX that converts Java bytecode to Dalvik bytecode.
The DX tool rearranges the Java class files to eliminate all redundant information in the class files and avoid repeated file loading and parsing during vm initialization. Under normal circumstances, the Java class file contains a number of different method signatures, if other class file references the class files in the method, the method signature will also be copied to the class file, that is to say, a number of different classes will also contain the same method signature, in the same way, a lot of string constants also be reused in multiple class files. The redundant information directly increases the size of files and seriously affects the file parsing efficiency of VMS. Remove the redundant information and recombine to form a constant pool, which all class files share. Because the dx tool compresses the constant pool, the same string and constant appear only once in the DEX file, reducing the size of the file.
For each Class file, it consists of the following formats:
Dex format files use a shared, type-specific constant pool mechanism to save memory. The constant pool stores all literal constants in a class, including string constants and field constant equivalents.
Simply speaking, dex format files are uniformly stored in the public parts of multiple class files to remove redundant information.
** The Java virtual machine is different from the Dalvik Virtual Machine architecture. ** This is the biggest difference between Dalvik and the JVM.
The Java VIRTUAL machine is based on the stack architecture. When the program is running, the VIRTUAL machine needs to read or write data frequently from the stack. This process requires more instruction dispatch and memory access times, which consumes a lot of CPU time, which is a considerable overhead for devices with limited resources like mobile phones. The Dalvik VIRTUAL machine is based on a register architecture. Data access is passed directly between registers, which is much faster than stack-based access.
Iv. Dalvik VIRTUAL Machine structure
An application first converts the class file into a DEX file that can be executed by the Dalvik VM through the DX tool. Then the class loader loads the native classes and Java classes, and the interpreter interprets and executes Dalvik bytecode according to the instruction set. Finally, the compiled target architecture is selected according to the DVM_ARCH parameter.
5. Android APK compilation and packaging process
1. The Java compiler compiles the Java code of the project itself, which comes from three sources: app source code, R files generated from resource files (AAPT tool), and Java interface files generated with AIDL files (AIDL tool). The output is a.class file.
Compiling r.java files with AAPT ② compiling AIDL Java files ③ compiling Java files into class files
2.. The class file and the dependent tripartite library file are used to generate the executable. Dex file of the Delvik VM, which contains all the class information, including the class of the project and the dependent class. The output is a. Dex file.
3. The apkBuilder tool generates an APK file without signature alignment from the. Dex file and the compiled resource file. The compiled resource file here includes two parts, one is compiled resource file generated by AAPT compilation, the other is the resource file of the dependent third-party database. Output is an unsigned. Apk file.
4. Jarsigner and Zipalign respectively sign and align apK files to generate the final APK file.
Summary: compile –>DEX–> pack –> Sign and align
Vi. Differences between ART vm and Dalvik VM
What is the ART:
ART stands for Android Runtime and handles application execution In a completely different way than Dalvik, which relies on a just-in-time (JIT) compiler to interpret bytecode. Application code compiled by developers needs to run on users’ devices through an interpreter, which is not efficient, but makes it easier for applications to run on different hardware and architectures. ART changes this completely by precompiling the bytecode into the machine language at application installation, a mechanism called Ahead-of-time (AOT) compilation. By removing the process of interpreting code, the application executes more efficiently and starts faster.
ART strengths:
1. Significant improvement of system performance. 2. Faster startup, faster running, smoother experience, and more timely tactile feedback. 3. Longer battery life. 4. Support lower hardware.
ART faults:
1. Larger storage footprint may increase by 10%-20%. 2. Longer application installation time.
The improvement of the ART vm relative to the Dalvik VM
** Precompiled **
In Dalvik, as in most other JVMS, JIT is used for just-in-time translation (dynamic translation), translating the dalvik Code (or SMali instruction set) runtimes side-by-side in DEX or ODEX into native code for execution. The introduction of JIT improved dalvik’s performance by three to six times.
In ART, Dalvik JIT is completely abandoned, and AOT is used to translate it into native code directly during installation. The introduction of this technology, virtual machine execution instructions speed and a significant improvement
① Garbage collection mechanism
First, the process of DALvik’s GC is introduced. There are four main processes: 1. When the GC is triggered, it will look for all live objects, at which point the entire program and all threads within the virtual machine will hang, so as to find the referenced objects in fewer stacks. It is important to note that this reclaim action is not concurrent with the application.
2. Gc marks qualified objects
3. Gc collects the marked objects
4, restore the execution of all threads to continue running
The advantage of Dalvik’s approach is that, when paused,GC is bound to be fairly fast. However, if GC is frequent and memory is tight, the UI will get stuck and frames will be dropped. The operation is not smooth.
Later ART improved on this GC approach, with the main improvement being to change its non-concurrent processes to partially concurrent ones. There is also the management of memory reallocation.
When ART GC occurs:
1. GC will lock the Java heap, scan it and mark it
Unlocks the Java heap and suspends all threads
3. GC collects the marked objects
4, restore the execution of all threads to continue running
5. Repeat 2-4 until the end
You can see that the whole process is partially concurrent and the time is reduced. According to official test data, GC efficiency is increased by 2 times
Improved memory usage and reduced fragmentation
Dalvik memory management is characterized by severe memory fragmentation, which is also a disadvantage of Mark and Sweep algorithm
You can see that after each GC, the memory is very porous, and the blocks that had been continuously allocated become very fragmented, and it becomes difficult to reallocate the incoming objects and then address them.
ART solution: In ART, it divides Java into a Space named large-object-space, and the introduction of this memory Space is used to store Large objects. At the same time, ART also introduced the moving Collector technology, which is the alignment of discontinuous physical memory blocks. With alignment, memory fragmentation is resolved nicely. The reason for the introduction of large-object-space is that the moving collector has a high cost of moving Large chunks of memory and improves the memory utilization. According to official statistics, the memory utilization of ART has increased by about 10 times.