First, what is the Dalvik virtual machine
Dalvik is Google's own Java Virtual machine designed for Android, an important part of the Android platform that supports the operation of the DEX format (Dalvik executable) Java application. The DEX format is a compression format designed specifically for Dalvik and is suitable for systems with limited memory and processor speed. Google has specifically optimized it, making Dalvik a highly efficient, concise, and resource-saving feature. From the Android system architecture diagram, the Dalvik virtual machine runs on the Android Runtime Library layer.
As a virtual machine designed for Linux and embedded operating systems, Dalvik is primarily responsible for the completion of object lifecycle management, stack management, thread management, security and exception management, and garbage collection. In addition, Dalvik did not have a JIT compiler in the early days until Android2.2 added technical support for JIT.
Second, the characteristics of Dalvik virtual machine
Small size, small memory footprint;
Proprietary DEX executable file format, smaller size, faster execution;
The constant pool uses 32-bit index values, addressing class method names, field names, and constants faster;
Based on the register architecture, and has a complete set of instruction system;
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, each of which corresponds to a Dalvik virtual machine instance.
Iii. differences between Dalvik virtual machines and Java virtual machines
Dalvik virtual machines have many different points from traditional Java virtual machines, they are not compatible, and their significant differences are mainly manifested in the following aspects:
The Java virtual machine is running Java bytecode, and the Dalvik virtual machine is running Dalvik byte code.
Traditional Java programs are compiled to generate Java bytecode stored in the class file, and the Java Virtual machine runs the program by decoding the contents of the class file. While the Dalvik virtual machine is running Dalvik bytecode, all Dalvik bytecode is converted from Java bytecode and packaged into a Dex (Dalvik executable) executable file. The Dalvik virtual machine executes these bytecode by interpreting the Dex file.
Dalvik executable file size is small. There is a tool called DX in the Android SDK that is responsible for converting Java bytecode to Dalvik byte code.
The DX tool rearranges the Java class files, eliminating all redundant information that appears in the class file, and avoids repeated file loading and parsing during initialization of the virtual machine. In general, Java class files contain several different method signatures, and if other class files refer to methods in the class file, the method signature is also copied to its class file, that is, many different classes contain the same method signature, and as such, a large number of string constants are reused in multiple class files. These redundant information directly increases the volume of the file, and it can seriously affect the efficiency of the virtual machine parsing files. Eliminate the redundant information and regroup to form a constant pool, where all class files share the same constant pool. Because the DX tool compresses the constant pool so that the same string, the constants appear only once in the Dex file, reducing the size of the file.
For each class file, it is made up of the following format:
The DEX format file uses a shared, specific type of constant pooling mechanism to conserve memory. A constant pool stores all literal constants in a class, including string constants, field constants, and so on.
In simple terms, the Dex format file is the common part of multiple class files to be stored uniformly, removing redundant information.
The **java virtual machine differs from the Dalvik virtual machine architecture. * * This is also the biggest difference between Dalvik and the JVM.
Java Virtual machine based on the stack architecture, the program at run time the virtual machine needs to read or write data frequently from the stack, this process requires more instruction allocation and memory access times, it will take a lot of CPU time, for devices such as mobile devices with limited resources, this is a significant cost. The Dalvik virtual machine is based on the register schema. Access to data is passed directly between registers, which is much faster than a stack-based approach.
Iv. structure of the Dalvik virtual machine
An application first passes the DX tool to convert the class file into a Dex file that the Dalvik virtual machine can execute, and then the class loader loads the native class and Java classes, followed by the interpreter to interpret and execute the Dalvik bytecode based on the instruction set. Finally, according to the Dvm_arch parameter, select the compiled target machine architecture.
V. Android APK Compilation Package Process
The 1.Java compiler compiles the Java code of the project itself, which has three sources: the source code of the app, the R file generated by the resource file (AAPT tool), and the Java Interface file (Aidl tool) that has the Aidl file generated. Output is a. class file.
①. Compiling R.java files with AAPT
② compiling aidl java files
③ compiling Java files into class files
2..class files and dependent three-party library files generate a. dex file for the Delvik virtual machine through the Dex tool, which contains all the class information, including the project's own class and the dependent class. Output is a. dex file.
The 3.apkbuilder tool generates an unsigned-aligned apk file for the. dex file and the compiled resource file. The compiled resource file consists of two parts, one is compiled resource file compiled by AAPT, and the other is the resource file in the three-party repository. The output is an unsigned. apk file.
4. The apk file is signed and aligned by Jarsigner and Zipalign, respectively, and the final APK file is generated.
Summary: Compile-->dex--> Package--Signature and alignment
Vi. the difference between art virtual machine and Dalvik virtual machine what is art:
Art stands for Android Runtime, which handles application execution in a completely different way than Dalvik,dalvik relies on a just-in-time (JIT) compiler to interpret bytecode. Developer-compiled application code requires an interpreter to run on the user's device, which is not efficient, but makes it easier for applications to run on different hardware and architectures. Art has completely changed this approach by pre-compiling bytecode to machine language when the installation is applied, called Ahead-of-time (AOT) compilation. After removing the process of interpreting the code, application execution is more efficient and faster to start.
Art Benefits:
- Significant improvement in system performance.
- Apps start faster, run faster, experience smoother, and feel more responsive to feedback.
- Longer battery life.
- Support for lower hardware.
Art Disadvantages:
- Larger storage footprint may increase by 10%-20%.
- Longer application installation time.
Upgrade of art virtual machine vs. Dalvik virtual machine
Pre-compilation
In Dalvik, like most other JVMs, the JIT is used for timely translation (dynamic translation), and the run state of Dalvik code (or Smali instruction set) that is parallel to Dex or Odex is translated into native code to execute. The introduction of JIT makes Dalvik improve the performance of 3~6 times.
In art, Dalvik's JIT was completely discarded, and the AOT was completely translated into native code when it was installed. The introduction of this technology makes the speed of executing instructions for virtual machines a significant improvement
Garbage collection mechanism
The process of GC in the next Dalvik is introduced first. There are four main processes:
- When the GC is triggered, it will go to find all active objects, and this time the entire program and all the threads inside the virtual machine are suspended, so that the object referenced is found in fewer stacks. It is important to note that this recycle action and application are non-concurrent.
- GC Flags objects that match a condition
- GC Reclaims tagged objects
- Resumes execution of all threads on-site to continue running
The advantage of Dalvik is that when you pause, the GC is bound to be quite fast. But if GC is frequent and memory crunch is bound to cause UI kaka, drop frames. The operation is not smooth and so on.
Later, art improved the GC approach, and the main improvement point was to change its non-concurrent process to partial concurrency. There is the redistribution management of memory.
When the art GC occurs:
- GC will lock the Java heap, scan and tag
- Flag to release the lock on the Java heap and suspend all threads
- GC Reclaims tagged objects
- Resumes execution of all threads on-site to continue running
- Repeat 2-4 until the end
It can be seen that the whole process is done partly by concurrency, which shortens time. According to official test data, GC efficiency is twice times higher.
Increase memory usage and reduce fragmentation
Dalvik Memory management features: Memory fragmentation is serious, of course, this is the mark and sweep algorithm brings the drawbacks
It can be seen that after each GC the memory is riddled with fragmentation, and the memory blocks that were allocated continuously become fragmented, and then allocating the incoming objects for memory addressing becomes difficult.
Art's solution: in art, it places Java in a space named Large-object-space, a memory space introduced to store large Object specifically. At the same time, art introduced the technology of moving collector to align the discontinuous blocks of physical memory. After the alignment, the memory fragmentation is well resolved. The introduction of Large-object-space is because moving Collector The displacement time cost of large chunks of memory is too high, and increase the utilization of memory root official statistics, art memory utilization increased by about 10 times times.
Vii. Articles of Reference
Https://github.com/LRH1993/android_interview/blob/master/android/basis/dalvik-art.md
Android Interview collection Android virtual machine and compilation process