Android runtime ART brief introduction and learning plan, androidart

Android runtime ART brief introduction and learning plan, androidart

Android has launched a new runtime ART in 4.4 to replace Dalvik, which has been used for some time. However, it was still a test version and the main character was Dalvik. It was not until this year's Google I/O conference that ART officially replaced Dalvik. This news has aroused a sensation in the scientific and technological field, and has also attracted many technical personnel to "analyze technology ". Unfortunately, these "Technical Analysis" only references official data and charts. This series of articles will conduct real technical analysis on ART. Old Rules: give a brief introduction and develop a learning plan before analysis.

Lao Luo's Sina Weibo: http://weibo.com/shengyangluo. welcome to the attention!

The reason why the release of ART attracted everyone's attention is that Andoid has been criticized for its smoothness compared with iOS. Android fluency is partly due to its applications and some system services running on virtual machines, that is, running on Dalvik virtual machines, iOS applications and system services directly execute local machine commands. In addition to replacing Dalvik with ART, we should also see that Android has spared no effort to improve the smoothness of the system since 3.0. For example, 3.0 adds hardware accelerated rendering for the application's 2D UI, that is, GPU rendering. Prior to this, the 2D UI of the application was always rendered using software, that is, CPU rendering. For example, in Project Butter 4.1, technologies such as VSYNC, Triple Buffer, and HWComposer are introduced in the UI architecture to greatly improve the smoothness of the UI.

ART is faster than Dalvik because ART executes Local Machine commands, while Dalvik executes Dex bytecode, which is executed through the interpreter. Even though Dalvik also generates local machine commands for frequently executed code by JIT, however, after all, when the application is running, the local machine commands that translate Dex bytecode will also affect the execution of the application. Therefore, even if Dalvik uses JIT, to a certain extent, it cannot be used to execute commands on local machines directly.

In the previous analysis article about seamless replacement of the Dalvik Virtual Machine During Android ART runtime, we mentioned that ART implements Java virtual machine interfaces like Dalvik, as shown in 1:

Figure 1 Relationship Between Dalvik, ART and Java VM

During the startup of the Zygote process, the Dalvik or ART virtual machine is created through the interface shown in Figure 1. In this case, although the local machine commands executed by ART appear to it, it is a real virtual machine. In this way, ART can directly load and run the APK without re-compiling the APK. This is also the principle that Dalvik can be seamlessly replaced during ART runtime. Therefore, we can conclude that ART is a virtual machine that executes commands on a local machine. This conclusion seems a bit contradictory. Since it is executing commands on a local machine, why is it also called a virtual machine? According to the analysis in the following article, apart from implementing Java virtual machine interfaces, ART also has a garbage collection mechanism and Java core class library calls. Therefore, with the in-depth analysis of ART, we believe that this conclusion is not contradictory.

As mentioned above, ART can load and run the APK without re-compiling it. This is because the APK is installed with AOT. AOT (Ahead Of Time) is relative to JIT (Just In Time. That is, before running the APK, You need to translate the Dex bytecode contained in it to obtain the corresponding local machine command, so you can directly execute it at runtime. This technology not only enables us to not make any changes to the original APK, but also enables these APK to run in the form of commands on the local machine only once during installation. This technology is similar to writing a program in C/C ++ language, and then compiling an executable program with GCC. Finally, this executable program can be loaded to the system for execution countless times, it is similar.

In ART, the Dex bytecode packaged in the APK is translated by LLVM for local machine instructions. LLVM is a framework system used to quickly develop your own compilers. For more information, see the article by Chris Lattner, one of its authors: http://www.aos?k.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. In general, LLVM contains three types of components, as shown in Figure 2:

Figure 2 LLVM Components

The Frontend analyzes the Syntax of the Source Code and generates an Abstract Syntax Tree (AST ), the abstract syntax tree can be further transformed into an intermediate language called llvm ir. Llvm ir is an intermediate language unrelated to programming languages. That is to say, the source files written in C, Fortran, and Ada are analyzed by syntax, finally, we can get a corresponding llvm ir file. This llvm ir file can be used as an input file for later Optimizer and Backend. The optimizer optimizes the llvm ir file, such as eliminating redundant computing in the code to mention the execution efficiency of the final generated code. The backend is responsible for generating final machine commands.

The above architecture of LLVM greatly simplifies the process of developing compilers, because developers only need to focus on the front-end, and then they can use the ready-made optimizer for code optimization, and use the ready-made backend to generate machine commands related to various architectures, as shown in 3:

Figure 3 using a ready-made language-independent optimizer and a backend to generate machine commands related to various architectures for language-related front-ends

In Figure 3, we develop three different front ends for the C, Fortran, and Ada languages, and then use the ready-made optimizer to optimize the llvm ir language they generate, in addition, machine commands of X86, PowerPC, and ARM architectures are generated through the ready-made backend.

If we do not forget that during Dalvik runtime, when APK is installed, the installation service PackageManagerService calls a tool dexopt through the daemon installd to package the classes containing the Dex bytecode In the APK. dex is optimized to save the optimized files in the/data/dalvik-cache directory. odex is the suffix, indicating that this is an optimized Dex file. During the ART runtime, when APK is installed, the PackageManagerService will call another tool dex2oat through the daemprocess installd to package the APK with Dex bytecode for translation. This translator is actually a compiler based on the LLVM architecture. Its front end is a Dex syntax analyzer. The translated ELF File ends with the. odex suffix and is saved in the/data/dalvik-cache directory.

ELF is a file format used by Linux systems. The static libraries, dynamic libraries, and executable files we usually access are stored in this format, however, files generated by the dexoat tool are different from the above three files. It has two special sections: oatdata and oatexec, these commands are used to store the dex file originally packaged in the APK and to translate the class methods in the dex file to obtain local machine commands, as shown in Figure 4:

Figure 4 ELF File Format obtained after ART translation classes. dex

In the dynamic section of the ELF File, oatdata, oatexec, and oatlastword are also exported to describe the starting and ending addresses after the oatdata and oatexec segments are added to the memory. The oatdata section contains two important information: one is the original classes. the complete content of the dex file, and the other information guides ART to find the classes. the Local Machine commands corresponding to the class methods in the dex file are stored in the oatexec segment.

For example, in classes. the dex file has A class A, so when we know the name of Class A, we can get all the information of Class A by saving the dex file in the oatdata segment, for example, its parent class, member variables, and member functions. On the other hand, Class A has A corresponding OatClass struct in the oatdata segment. This OatClass struct describes the location of Local Machine commands corresponding to each method of Class A in the oatexec segment. That is to say, after we know the name (Signature) of a class and a method, we can find the local machine commands in the oatexec segment through the dex file content of the oatdata segment and the OatClass struct, in this way, you can execute this class method.

Through the above analysis, we will briefly introduce the operating principle of ART, which is summarized as follows:

1. the Zygote process created during Android startup uses the Java Virtual Machine Interface exported during the ART runtime to create the ART virtual machine.

2. When the APK is installed, the classes. dex file in it will be translated by the tool dex2oat to get an ELF file.

3. when the APK is running, the above generated ELF file will be loaded into the memory, in addition, the ART virtual machine can use the oatdata and oatexec segments to find the local machine commands corresponding to the methods of any class for execution.

For the creation process of the ART virtual machine at, refer to the Process Analysis article on seamless replacement of the Dalvik virtual machine during the previous Android ART runtime.

For, The Dex bytecode In the APK is translated by the dex2oat tool to generate commands on the local machine and requires a solid compilation knowledge. Due to limited knowledge, ability, and time, We will skip this part of content, but this will not affect our understanding of ART runtime.

The 3rd point is the key to understanding the ART runtime. Taking the Startup Process of the ART virtual machine as an example, we can see from the analysis of the process of seamlessly replacing the Dalvik virtual machine during the previous Android ART runtime, in the member function start of the AndroidRuntime class, after the ART virtual machine is created and initialized, the Zygote process uses the JNI interface CallStaticVoidMethod that it exports to officially enter the running status using the specified class method as the entry, as shown below:

void AndroidRuntime::start(const char* className, const char* options)  {      ......            /* start the virtual machine */      JniInvocation jni_invocation;      jni_invocation.Init(NULL);      JNIEnv* env;      if (startVm(&mJavaVM, &env) != 0) {          return;      }            ......            /*      * Start VM.  This thread becomes the main thread of the VM, and will      * not return until the VM exits.      */      char* slashClassName = toSlashClassName(className);      jclass startClass = env->FindClass(slashClassName);      if (startClass == NULL) {          ALOGE("JavaVM unable to locate class '%s'\n", slashClassName);          /* keep going */      } else {          jmethodID startMeth = env->GetStaticMethodID(startClass, "main",          "([Ljava/lang/String;)V");          if (startMeth == NULL) {              ALOGE("JavaVM unable to find main() in '%s'\n", className);              /* keep going */          } else {              env->CallStaticVoidMethod(startClass, startMeth, strArray);        #if 0              if (env->ExceptionCheck())                  threadExitUncaughtException(env);  #endif          }      }                ......  }  

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 className parameter is equal to "com. android. internal. OS. zygoteInit ", the local variable env is the JNI interface obtained from the ART virtual machine created by calling another member function startVM. The purpose of the function is to find a function named com. android. internal. OS. zygoteInit class, as well as its static member function main, and then uses this function as the entry 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 to find the static member function main of the com. android. internal. OS. ZygoteInit class.

3. Call the JNI interface CallStaticVoidMethod to run the static member function main of the com. android. internal. OS. ZygoteInit class.

Note: in step 1, CallStaticVoidMethod is executed to start executing the local machine command of the static member function main of the com. android. internal. OS. ZygoteInit class, instead of the Dex bytecode. This raises the following three key issues:

1. How does ART find the com. android. internal. OS. ZygoteInit class?

2. How does ART find the static member function main in the com. android. internal. OS. ZygoteInit class?

3. How does ART find the local machine instruction of the static member function main of the com. android. internal. OS. ZygoteInit class?

The information required to solve the preceding three problems is stored in the ELF file generated by the dex2oat tool. Therefore, in the following article, we will answer the above three questions by analyzing the ELF file generated by the dex2oat tool, so that we can better understand how ART works.

As mentioned above, because ART needs to use the original dex file content stored in the oatdata segment of the ELF file when searching for class methods, it is essentially to parse the dex file to obtain relevant information. This is the same as the process in which the Dalvik Virtual Machine searches for class and method information in the dex file. This means that you must understand the Dalvik Virtual Machine before performing ART. For more information about Dalvik virtual machines, see the Dalvik Virtual Machine introduction and learning plan series. This tells us the truth that old knowledge is not outdated. It is helpful for us to learn new knowledge, sometimes even necessary. Therefore, do not think that the previous articles based on Android 2.3 are useless. When we learn something new, whether it's new knowledge or old knowledge, it's very helpful for us to understand its principles!

In addition to using the ELF file generated by dex2oat as the starting point to analyze the ART runtime, the garbage collection mechanism during the ART runtime will be used to demonstrate that the ART Runtime is also a virtual machine like the Dalvik virtual machine, so as to deepen the understanding of the ART runtime. Compared with the garbage collection mechanism of Dalvik virtual machine, the garbage collection mechanism during ART operation is more complex, resulting in higher garbage collection efficiency. Therefore, we will analyze the garbage collection mechanism of the Dalvik Virtual Machine before analyzing the garbage collection mechanism during ART runtime. On the one hand, it is helpful for us to explain the garbage collection principles during the ART operation step by step and in a simple manner. On the other hand, it is also convenient for us to compare the garbage collection mechanisms of the Dalvik Virtual Machine During the ART operation with those of the Dalvik virtual machine, in this way, the garbage collection efficiency during the ART operation can be better understood.

To sum up, we will analyze the working principle of ART in the following scenarios:

1. The process of loading Dex files on the Dalvik Virtual Machine and searching for classes and methods from them.

2. The process of searching for Local Machine commands of class methods during ART running.

3. Garbage collection process of the Dalvik virtual machine.

4. Garbage collection process when ART is running.

The above scenario will be analyzed based on the Android 4.4 source code. On the one hand, it is because the source code of the Android L version has not been released, and on the other hand, it is believed that the ART Implementation of the Android L version has changed, however, the basic principles are the same. Stay tuned! For more information, refer to Lao Luo's Sina Weibo: http://weibo.com/shengyangluo.

What is the android art mode?

What is the ART mode? The ART mode is short for Android runtime. What is the difference between it and the traditional Android Dalvik model? Where is it? In fact, before Android 4.2, Android mobile phone system applications were all running on Dalvik Java virtual machines. This running mode relies on a compiler to communicate with applications. Each time an application runs, the code in the program must be converted into a machine code to run. This is an additional procedure, this results in relatively fast power consumption, high memory usage, and severe freezing even if the flagship machine is used for a long time.
In comparison, the ART mode solves this problem well. By automatically pre-reading and compiling the program code during application installation, the program can be directly compiled into a machine language, the Dalvik mode eliminates the need to convert code from time to achieve high efficiency, power saving, lower system memory usage, and smooth operation of mobile phones. However, there are always two sides in everything. ART solves this problem while at the same time: it will occupy a slightly higher storage space, and it takes some time for the installation program to implement pre-compilation than the ordinary Dalvik mode. Now let's try the ART mode to see if it deserves our expectation.
With the popularization of P and other in-depth optimizations, the APK of Android applications is becoming larger and larger, while in the ART mode, storage usage (ROM) or running memory (RAM) the usage is more obvious. However, this margin is completely acceptable. After all, our mobile phones are basically 8 Gbit/s, which is not a problem at all.
In fact, the overall response speed of the ART and Dalvik modes is not much different. Most of the differences are within one second or less than one second. Of course, this is also the reason why there are currently few applications optimized for the ART mode. In the benchmark run-point test, the advantages of the ART model are displayed, which is indeed much more efficient than Dalvik.
A new underlying running mode, after all, relies on application APP adaptation to maximize the biggest advantage. However, because Android 4.4 is not widely used and only available on some models, compatibility in the ART mode is still a problem, and many applications are not compatible, there will be forced shutdown, or simply no response, all of which need to be followed up by the Follow-Up Optimization of mobile phone manufacturers.
Let's look at the differences between the ART model and Dalvik. The Dalvik model is like a folding bicycle. It must be assembled before each ride. The ART model is a bicycle that has been installed, and you can just get on the bus and leave. Therefore, the efficiency of the ART model must be better than that of Dalvik. There is no suspense. What we can do now is to patiently wait for the application vendor to optimize the program to adapt to the ART model, there is a brand new experience.

What is the android art mode?

The ART mode is short for Android runtime.
Compared with the Dalvik mode of Android phones, the running memory consumption is reduced, and the power consumption is reduced, but the software package is increased. However, currently, mobile phones are generally 8 GB of storage space, so it is not a problem.
In general, the ART model is the new underlying framework of Android mobile phones, which can speed up the running of your mobile phone and make the Android mobile phone running more smoothly and closer to the running speed of IOS Mobile Phone, it is not a small innovative technology.