Shulou(Shulou.com)06/02 Report--

This article focuses on "how to understand the Android virtual machine architecture", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the Android virtual machine architecture.

1. What is a Dalvik virtual machine

Dalvik is a Java virtual machine designed by Google for the Android platform. It is an important part of the Android platform and supports the operation of Java applications in dex format (Dalvik Executable). Dex format is a compression format specially designed for Dalvik, which is suitable for systems with limited memory and processor speed. Google optimizes it specifically, so that Dalvik has the characteristics of high efficiency, simplicity and resource saving. From the Android system architecture diagram, the Dalvik virtual machine runs at the runtime library layer of Android.

2. Functions of the Dalvik virtual machine

As a virtual machine designed for Linux and embedded operating system, Dalvik is mainly responsible for object life cycle management, stack management, thread management, security and exception management, and garbage collection. Dalvik makes full use of the specificity of Linux process management and makes an object-oriented design of it, so that multiple processes can be run at the same time, while traditional Java programs usually run only one process, which is why Android does not adopt JVM. In order to optimize Dalvik, most of the underlying operations are related to the system kernel, or directly call the kernel interface. In addition, Dalvik did not have a JIT compiler in its early days, and it was not until Android2.2 that it added technical support for JIT.

3. The difference between Dalvik virtual machine and Java virtual machine

In essence, Dalvik is also a Java virtual machine. But it is special in that it does not use the JVM specification. Most Java virtual machines are stack-based (see understanding the Java virtual machine architecture for details), while Dalvik virtual machines are register-based. Stack-based instructions are very compact, for example, the instruction used by the Java virtual machine is only one byte, so it is called bytecode. Register-based instructions need to take up more instruction space because they need to specify source and destination addresses. Some instructions of the Dalvik virtual machine take up two bytes. Stack-based instruction set and register-based instruction set have their own advantages and disadvantages. Generally speaking, to perform the same function, the former needs more instructions (mainly load and store instructions), while the latter needs more instruction space. The need for more instructions means more CPU time, and the need for more instruction space means that data buffers (d-cache) are more likely to fail. More discussion, virtual machine talk (1): interpreter, tree traversal interpreter, stack-based and register-based, hodgepodge gives a very detailed reference.

The Java virtual machine runs Java bytecode, while the Dalvik virtual machine runs the proprietary file format dex. In a Java program, the Java class is compiled into one or more class files, then packaged into a jar file, and the Java virtual machine gets the corresponding bytecode from the corresponding class file and jar file. Although Android applications also use Java language, after compiling into class files, all class files will be converted into a dex file through DEX tools, from which instructions and data will be read by the Dalvik virtual machine. Dex files not only reduce the overall file size and the number of IZP O operations, but also improve the speed of class search.

From the following figure, you can see the composition of jar and apk files, as well as the differences between class files and dex files. Dex format files use a shared, specific type of constant pool mechanism to save memory. The constant pool stores all literal constants in the class, including string constants, field constants, and so on.

In general, the Dalvik virtual machine has the following characteristics:

Use bytecode in dex format, not compatible with Java bytecode format

Low code density, high running efficiency and resource saving

Constant pools use only 32-bit indexes

Have memory limit

The default stack size is 12KB (3 pages, 4KB per page)

The default startup size of the heap is 2MB, and the default * value is 16MB.

The minimum startup size supported by the heap is 1MB, and the supported * * value is 1024MB.

Heap and stack parameters can be modified with-Xms and-Xmx

4. Dalvik system structure

In fact, Dalvik is based on part of the implementation of Apache Harmony (the Java SE project of the Apache Software Foundation) and provides its own set of libraries, that is, API used in the programming of upper-level Java applications.

The above illustration is from tech-insider. Apache Harmony is generally divided into three layers: operating system, Java virtual machine, and Java class library. Its characteristic is that the virtual machine and class library are highly modular, and each module has a certain interface definition. The interface between operating system layer and virtual machine layer is defined by Portability Layer, which encapsulates the differences of different operating systems and provides a set of unified API access underlying system calls for the local code of virtual machines and class libraries. In addition to JNI and JVMITI defined by Java specification, the interface between virtual machine and class library also adds a layer of virtual machine interface, which is composed of kernel classes and local code. Virtual machines that implement the virtual machine interface can be implemented using the class library of Harmony and can be started by the same Java startup program provided by Harmony.

The following is the structure diagram of the Dalvik virtual machine:

An application first converts class files into dex files that can be executed by Dalvik virtual machines through DX tools, then the class loader loads the native classes and Java classes, and then the interpreter interprets and executes the Dalvik bytecode according to the instruction set. Select the compiled target machine architecture according to the dvm_arch parameter.

4.1 dex file structure

There are many differences between dex file structure and class file structure, but dex and class files are consistent in terms of the information they carry.

Header: stores the starting address, offset and other information of each data type.

Proto_ids: describes the function prototype information, including return values and parameter information. For example, "test: () V"

Methods_ids: function information, including the class and the corresponding proto information.

For more information on dex format, Android Security-Dex file format is described in great detail in this article. Although the structure of the dex file is compact, the dex file needs to be further optimized in order to further improve the performance of the runtime. Optimization is mainly aimed at the following aspects:

Adjust the byte order of all fields and align each field in the structure

Verify all classes in the dex file

Optimize some specific classes and optimize the opcodes in the method

After optimization, the file size of the dex file will swell, about 1 / 4 times the original size. For built-in applications, an optimization file (odex: Optimized dex) is usually generated after the system is compiled. An Android application needs to go through the following process to run on the Dalvik virtual machine:

Compile Java source files into class files

Use the DX tool to convert class files into dex files

Use the aapt tool to combine dex files, resource files, and AndroidManifest.xml files (in binary format) into APK

Install APK to run on an Android device

The figure above (from the network) shows in detail how the final signed APK comes from.

4.2 Dalvik class loader

A dex file requires a class loader to load native classes and Java classes, and then interpret and execute Dalvik bytecode according to the instruction set through the interpreter. The Dalvik class loader uses the mmap function to map the dex file to memory, access the dex file through ordinary memory read operations, and then parse the contents of the dex file and load the classes into the hash table.

4.2.1 parsing dex

In general, the dex file can be abstracted into three parts: header, index, and data. Through the header, you can know the location and number of the index, as well as the starting position of the data area. After the dex file is mapped to memory, Dalvik calls the dexFileParse function to analyze it, and the results of the analysis are put into the DexFile data structure. The baseAddr in DexFile points to the start of the mapping area, and the pClassDefs points to the start of the class index. To speed up the lookup of the class, a hash table is also created to hash the class name and generate an index.

4.2.2 load class

After the parsing work is completed, the class is loaded, and the loaded classes need to be stored in the ClassObject data structure.

Typedef struct Object {ClassObject* clazz; / / Type object Lock lock; / / Lock object} Object

Where clazz points to the ClassObject object and also contains a Lock object. If another thread wants to acquire its lock, it has to wait for that thread to release. Each class loaded by Dalvik corresponds to a ClassObject object, and the loading process allocates several areas in memory, storing directMethod, virtualMethod, sfield, and ifield respectively. This information is read from the data area of the dex file. The field Field is defined as follows:

Struct Field {ClassObject* clazz; / / Type const char* name; / / variable name const char* signature; / / such as "Landroid/os/Debug;" U4 accessFlags; / / access tag # ifdef PROFILE_FIELD_ACCESS U4 gets; U4 puts; # endif}

After the class index is obtained, the actual loading is done by loadClassFromDex. First, it reads the specific data of class, loads directMethod, virtualMethod, ifield and sfield, respectively, and then allocates memory for the ClassObject data structure and reads the relevant information of the dex file. After loading, put the loaded class into the hash table through the dvmAddClassToHash function to facilitate the next search; * * find the superclass of this class through dvmLinkClass, and load the corresponding API class if there is an API class.

4.3 Dalvik interpreter

For any virtual machine, the interpreter is undoubtedly the core part, and all Java bytecodes are interpreted and executed by the interpreter. Because the efficiency of the Dalvik interpreter is very important, Android implements the C language version and various assembly language versions of the interpreter. The interpreter is usually executed in a loop, requiring an entry function call handler to execute * instructions, and then each instruction leads to the next instruction and calls the handler through the function pointer.

4.4 memory management

Garbage collection is the core of Dalvik virtual machine memory management. Only the garbage collection capabilities of the Dalvik virtual machine are described here. The performance of garbage collection greatly affects the efficiency of memory usage in a Java program. The Dalvik virtual machine uses the commonly used Mark-Sweep algorithm, which is divided into Mark phase (marking active objects), Sweep phase (garbage collection), and optional Compact phase (reducing fragmentation in the heap). The principle of Android memory management is explained in detail in this article.

The * step of garbage collection is to mark active objects, because there is no way to identify those inaccessible objects, so that all unmarked objects are garbage that can be recycled. When performing garbage collection, the Dalvik virtual machine needs to be stopped (except for garbage collection), so garbage collection is also known as STW (stop-the-world). During the operation of Dalvik virtual machine, some state information is maintained, including registers saved by each thread, static fields in Java classes, local and global JNI references, and all function calls in JVM correspond to a corresponding C stack frame. Each stack frame may contain references to objects, such as local variables and parameters that contain object references. All this reference information is added to a root collection, and then starting from the root set, the objects that can be accessed from the root collection are found recursively. Therefore, the Mark process is also called tracking, tracking all accessible objects.

The second step in garbage collection is to reclaim memory. During the Mark phase, all accessible object collections can be obtained through markBits bitmaps, while liveBits bitmaps represent all assigned object collections. By comparing the differences between liveBits bitmaps and markBits bitmaps, this is a collection of all recyclable objects. The Sweep phase calls free to free this memory to the heap.

In the underlying memory implementation, the Android system uses msspace, which is a lightweight malloc implementation. In addition to creating and initializing memory heaps for storing normal Java objects, Android creates three additional memory heaps:

"livebits" (bitmap index used to store memory usage on the heap)

"markbits" (bitmap index used to label living objects in GC)

"markstack" (traverses the annotation stack referenced by living objects in GC)

The virtual machine controls the GC memory heap through a global HeapSource variable called gHs, while the HeapSource can manage multiple heaps (Heap) through the heaps array to meet the requirement of dynamically resizing the GC memory heap. In addition, a bitmap index called "livebits" is maintained in HeapSource to track the memory usage of each Heap. The remaining two data structures, "markstack" and "markbits", are used in the garbage collection phase.

In the figure above, "livebits" maintains used memory information on the heap, while the bitmap index "markbits" points to living objects. A, C, F, G, H objects need to be preserved, so "markbits" points to them respectively (the H object of * * is still in the process of dimensioning, so there is no pointer to it). The "markstack" is the flag stack used to track the objects that currently need to be processed during the annotation process, when it saves the objects F, G, and H being processed.

Start-up process of 4.5 Dalvik

Dalvik process management depends on linux's process architecture. If you want to create a process for an application, it uses linux's fork mechanism to copy a process. Zygote is not only a virtual machine process, but also an incubator of a virtual machine instance, which is started by the init process. Previous articles have described this process in detail: Android system startup analysis (Init- > Zygote- > SystemServer- > Home activity). The process of starting the Dalvik virtual machine is analyzed here.

The AndroidRuntime class mainly does the following things:

Call startVM to create a Dalvik virtual machine, and JNI_CreateJavaVM actually creates and initializes the virtual machine instance

Call startReg to register the JNI method of the Android core class

Enter the Java layer through the Zygote process

In JNI, dvmCreateJNIEnv creates and initializes a JNI environment, a JNIEnvExt object, for the current thread. * call dvmStartup to initialize the previously created Dalvik virtual machine instance. The function dvmInitZygote calls the system's setpgid to set the current process, the process group ID of the Zygote process. Once this step is complete, the creation and initialization of the Dalvik virtual machine is complete.

5. Startup of Android

Start the power supply and load the bootstrap to RAM

BootLoader boot

Linux Kernel start

Init process creation

Init fork out the Zygote process, and the Zygote process creates a virtual machine; creates a system service

Android Home Launcher start

At this point, I believe you have a deeper understanding of "how to understand the Android virtual machine architecture". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.