Android Runtime Art Brief introduction and Learning Plan

The release of art has attracted attention because Andoid has been criticized for its fluency in comparison to iOS. One of the reasons for Android's fluency problem is that its applications and some of the system services are running on top of the virtual machine, which is running on top of the Dalvik virtual machine, while iOS applications and system services execute local machine instructions directly. In addition to using art to replace Dalvik, we should also see that Android, starting from 3.0, has spared no effort in improving the fluency of the system. For example, 3.0 adds hardware-accelerated rendering of the application 2D UI, which is GPU rendering. Until then, the application's 2D UI has been using software rendering, which is CPU rendering. As well as 4.1 through Project Butter, VSync, Triple buffer and Hwcomposer are introduced into the UI architecture, which greatly improves the fluency of the UI.

Art is faster than Dalvik because art executes local machine instructions, and Dalvik executes Dex bytecode, which is performed through an interpreter. Although Dalvik also JIT-generates local machine instructions for frequently executed code, translating Dex bytecode into local machine instructions during application run can also affect the execution of the application itself, so even if Dalvik uses JIT, Also, to a certain extent, it is not as straightforward as running the local machine instructions.

In the previous process analysis of the Android art runtime seamlessly replacing the Dalvik virtual machine, we mentioned that art, like Dalvik, implements the Java Virtual machine interface, as shown in 1:

Figure 1 Relationship of Dalvik, art, and Java VMS

The zygote process is started by creating a Dalvik or art virtual machine from the interface shown in Figure 1, so it seems that art executes a local machine instruction, but it appears to be a virtual machine. Because of this, art can directly load and run the APK without recompiling the APK. This is also how the art runtime can seamlessly replace the Dalvik runtime. Therefore, we can conclude that art is a virtual machine that executes local machine instructions. This conclusion seems a bit contradictory, since it is the implementation of local machine instructions, why is called a virtual machine? As you can see from the next article, art has a garbage collection mechanism in addition to the Java Virtual Machine interface, as well as a Java Core class library call, so with an in-depth analysis of art, we think this conclusion is not contradictory.

As mentioned above, art can load and run directly on the basis of not recompiling the APK, because the APK was executed in the AOT at the time of installation. The AOT (Ahead of time) is relative to JIT (Just in time). That is, before the APK runs, the Dex bytecode that it contains is translated and the corresponding local machine instructions are obtained, so it can be executed directly at run time. This technique not only allows us to make any changes to the original APK, but also allows the apk to be translated only once during installation, and can be run countless times as a local machine instruction. This technique is similar to the way that we write a program in C + + language and then compile an executable program with GCC, and finally the executable can be loaded countless times into the execution of the system.

In art, the Dex bytecode that is packaged in the APK is translated into local machine instructions by LLVM. LLVM is a framework system used to quickly develop its own compiler, and for its introduction, you can refer to one of its authors, Chris Lattner, who wrote this article: Http://www.aosabook.org/en/llvm.html. Speaking of Chris Lattner, he is the chief architect of the Swift language released by Apple this year, so we can feel how powerful LLVM is. Overall, LLVM contains three types of components, as shown in 2:

Figure 2 LLVM Components

The front end (Frontend) parses the input source code (source code), generates an abstract syntax tree (abstract Syntax tree,ast), and can further transform the resulting abstract syntax tree into an intermediate language called LLVM ir. LLVM IR is a programming language independent of the intermediate language, that is, whether it is the C language, or the FORTRAN, ADA language written source files, after the analysis of the syntax, the final can be obtained a corresponding LLVM ir file. This LLVM IR file can be used as an input file for the following optimizer (Optimizer) and back end (backend). The optimizer optimizes LLVM IR files, such as eliminating redundant computations within the code, to refer to the execution efficiency of the resulting code. The backend is responsible for generating the final machine instructions.

The above architecture of LLVM greatly simplifies the process of developing compilers, because developers need to focus on the front-end, then can use the out-of-the-box optimizer for code optimization, and leverage out-of-the-box backend to generate various architecture-related machine directives, as shown in 3:

Figure 3 Generating various architecture-related machine directives with ready-to-use language-agnostic optimizer and backend-language-related front end

In Figure 3, we developed three different front ends for the C, Fortran, and Ada three languages, and then optimized the LLVM IR language they generated using the out-of-the-box optimizer, and generated machine directives for X86, PowerPC, and arm three different architectures through off-the-shelf backend.

If we do not forget, during the Dalvik runtime, when the APK is installed, the installation service Packagemanagerservice will be installd through the daemon Using a tool dexopt to optimize the classes.dex that is packaged in the APK containing the Dex bytecode, the optimized file is saved in the/data/dalvik-cache directory, and the. Odex suffix indicates that this is an optimized Dex file. In the art runtime, when the APK is installed, the same installation service Packagemanagerservice will call another tool through the daemon Installd dex2oat to package in the APK contains Dex byte code into the translation. This translator is actually a compiler based on the LLVM architecture, and its frontend is a DEX parser. After the translation is an elf file, the elf file is also at the end of the. Odex suffix, and is also saved in the/data/dalvik-cache directory.

Elf is a Linux system using a file format, we usually touch the static libraries, dynamic libraries and executables are saved in this format, but the files generated by the Dexoat tool and the above three files are different, it has two special segments Oatdata and Oatexec, It is used to store the Dex files originally packaged in the APK and to translate the class method inside the Dex file to get the local machine instructions, as shown in 4:

Figure 4 the Elf file format obtained after art translation Classes.dex

In the dynamic segment (Dymanic section) of the Elf file, three symbols oatdata, oatexec, and Oatlastword are also exported, respectively, to describe the Oatdata and oatexec segments to the end-of-memory address. In the Oatdata section, contains two important information, one information is the complete content of the original Classes.dex file, another information guides art to find The local machine instructions corresponding to the class method inside the Classes.dex file are stored in the oatexec segment.

For example, we have a class A in the Classes.dex file, so when we know the name of Class A, we can get all the information of Class A, such as its parent class, member variables, and member functions, through the Dex file stored in the Oatdata segment. On the other hand, Class A has a corresponding oatclass structure in the Oatdata segment. This oatclass structure describes the location of the local machine instruction in the Oatexec segment for each method of Class A. That is, when we know the name (signature) of a class and one of its methods, we can find its local machine instruction in the OATEXEC segment through the contents of the Dex file of the Oatdata segment and the Oatclass struct, so that the class method can be executed.

Through the above analysis, we will briefly introduce the principles of the operation of Art, summarized as follows:

1. The zygote process created during the Android system boot process utilizes the Java Virtual Machine interface exported by the art runtime to create an art virtual machine.

2. APK is installed, the Classes.dex file that is packaged in it will be translated by the tool Dex2oat to the local machine instruction and eventually get a file in elf format.

3. APK runtime, the above generated elf file will be loaded into memory, and the art virtual machine can be found through the inside of the Oatdata and Oatexec section of the method corresponding to the local machine instructions to execute.

For the 1th, during the creation of the art virtual machine, you can refer to the process analysis of the previous Android art runtime to seamlessly replace the Dalvik virtual machine.

For the 2nd, the Dex bytecode inside the APK is translated by the Dex2oat tool to native machine instructions, and mastering it requires a solid knowledge of compiling. Because of the limited knowledge, ability, and time, this part of the content we have to skip the analysis, but this will not affect our understanding of the art runtime.

For the 3rd, we understand the key to the art runtime. Taking the boot process of the art virtual machine as an example, the process analysis of seamlessly replacing the Dalvik virtual machine from the previous Android art runtime can be understood, in the member function start of the Androidruntime class, after the creation and initialization of the art virtual machine is completed, The zygote process passes through the JNI interface Callstaticvoidmethod it exports, allowing it to formally enter the running state as a specified class method, as follows:

[CPP]View Plaincopy

2. void Androidruntime::start (const char* className, const char* options)
4. {
6. ......
10. / * Start the virtual machine * /
12. Jniinvocation jni_invocation;
14. Jni_invocation. Init (NULL);
16. jnienv* env;
18. if (STARTVM (&MJAVAVM, &env)! = 0) {
20. return;
22. }
26. ......
30. /*  
32. * Start VM. This thread becomes the main thread of the VM, and would
34. * Not return until the VM exits.
36. */
38. char* slashclassname = Toslashclassname (className);
40. Jclass Startclass = Env->findclass (slashclassname);
42. if (Startclass = = NULL) {
44. Aloge ("JAVAVM Unable to locate class '%s ' \ n", slashclassname);
46. / * Keep going * /
48. } Else {
50. Jmethodid Startmeth = Env->getstaticmethodid (Startclass, "main",
52. "([ljava/lang/string;) V");
54. if (Startmeth = = NULL) {
56. Aloge ("JAVAVM Unable to find main () in '%s ' \ n", className);
58. / * Keep going * /
60. } Else {
62. Env->callstaticvoidmethod (Startclass, Startmeth, Strarray);
66. #if 0
68. if (Env->exceptioncheck ())
70. Threadexituncaughtexception (env);
72. #endif
74. }
76. }
80. ......

This function is defined in the file frameworks/base/core/jni/androidruntime.cpp.

In the member function start of the Androidruntime class, the value of the parameter classname equals "Com.android.internal.os.ZygoteInit", The local variable env is the JNI interface obtained from the art virtual machine that was created by calling another member function STARTVM. The goal of the function is to find a class named Com.android.internal.os.ZygoteInit, and its static member function, main, and then use this function as a portal to start running the art virtual machine. To do this, the function performs the following steps:

1. Call the JNI interface findclass to load the Com.android.internal.os.ZygoteInit class.

2. Call the Jni interface Getstaticmethodid find the static member function of the Com.android.internal.os.ZygoteInit class main.

3. Call the Jni interface Callstaticvoidmethod to start executing the static member function of the Com.android.internal.os.ZygoteInit class main.

Note that in step 3rd, the Callstaticvoidmethod starts executing the static member function of the Com.android.internal.os.ZygoteInit class, main's local machine instruction, not the Dex bytecode. This leads to the following three key questions:

1. How does art find the Com.android.internal.os.ZygoteInit class?

2. How does art find the static member function of the Com.android.internal.os.ZygoteInit class main?

3. How does art find the static member function of the Com.android.internal.os.ZygoteInit class Main's local machine directive?

The information required to resolve the three above issues is found in the elf file generated by the Dex2oat tool. Therefore, in the next article, we will answer these three questions by analyzing the Elf files generated by the Dex2oat tool, so that we can better understand how art works.

As mentioned above, since art is looking for a class method, it needs to use the contents of the original Dex file stored in the Oatdata segment of the elf file, essentially parsing the Dex file to obtain the relevant information. This is the same process as the Dalvik virtual machine looks for class and method information in the Dex file. This means that to understand the art runtime, you must first understand the Dalvik virtual machine. Dalvik knowledge of virtual machines can refer to the Dalvik virtual machine Brief introduction and Learning plan for this series of articles. This tells us that the old knowledge is not obsolete, it is helpful for us to learn new knowledge, and sometimes it is necessary. So let's not think that the most up-to-date Android 2.3-based articles are useless. When we are learning something new, whether it is new knowledge or old knowledge, it is very helpful for us to understand its principle.

In addition to analyzing the art runtime with the elf files generated by the Dex2oat tool, we also combine the art runtime's garbage collection mechanism to demonstrate that the art runtime is a virtual machine as well as a dalvik virtual machine to deepen our understanding of the art runtime. The art runtime's garbage collection mechanism is more complex than the garbage collection mechanism of Dalvik virtual machines, resulting in higher garbage collection efficiency. So before we analyze the garbage collection mechanism of the art runtime, we first analyze the garbage collection mechanism of the Dalvik virtual machine. On the one hand, it is helpful for us to explain the principles of garbage collection in the art runtime in a gradual and simple way, and to compare the different garbage collection mechanisms between the art runtime and the Dalvik virtual machine, so as to better understand the efficiency of garbage collection in the art runtime.

To summarize, let's analyze how art works by following several scenarios:

1. Dalvik the process by which the virtual machine loads the Dex file and finds classes and methods from it.

2. The art runtime looks for the procedure for the local machine instruction of the class method.

3. Dalvik the garbage collection process for the virtual machine.

4. The Art runtime garbage collection process.

Android Runtime Art Brief introduction and Learning Plan