Android ART Mechanism Analysis

 

I. Improvement of Android system performance

 

As one of the core components of the Android platform, the Dalvik virtual machine allows multiple virtual machine instances to run simultaneously in limited memory resources. The Dalvik Virtual Machine improves performance in the following ways:

1. odex-based processing during DEX code installation or the first dynamic loading.

2. Android2.2 provides the JIT mechanism to improve performance, which is known as a performance improvement of 3 ~ 5 times.

3. Improve hardware configuration, such as multi-core CPU, higher-frequency CPU, and larger RAM.

 

However, there is still a gap between the smoothness of Android and IOS systems. Android code must run on the Dalvik virtual machine, while IOS code is local directly, and the performance gap is also reasonable. If the Android system wants to have the same system performance as the IOS system. The Dalvik virtual machine running mechanism becomes the only obstacle to improving the performance of the Android system.

Android Kitkat provides a different Runtime environment than Dalvik-ART (Android Runtime. Currently, you can select the running environment of the device. In the near future, ART will definitely replace Dalvik Runtime.

 

2. Dalvik vs ART

The Dalvik runtime environment uses JIT (Just-In-Time) for translation. Each Time an application runs, the bytecode needs to be converted to the machine code through JIT, which slows down the running efficiency of the application. However, ART uses AOT for processing (Ahead-Of-Time), and performs pre-basic compilation when the application is installed, this reduces the machine code conversion time during JIT running, and the application startup and execution will become faster.

Advantages of ART:
1. A significant improvement in system performance.
2. faster application startup, faster operation, smoother experience, and more timely touch feedback.
3. longer battery endurance.

4. Support lower hardware.

Disadvantages of ART:
1. A larger storage space may increase by 10%-20%.
2. Longer application installation time.

 

In general, the function of ART is to change the space for time ".

 

3. Initial awareness of ART

 

1. How to select an ART running environment for a device

 

To enable this function, perform the following steps: Set → about mobile phone → click the latest version 7 → developer mode appears → return → enter developer mode, and then select runtime-use ART

Currently the official Android simulator does not enable the ART mode, you can download the Android simulator image supporting the ART mode (http://blog.csdn.net/coolypf/article/details/17069015)

 

2. the system changes after the Dalvik switches the ART

 

2.1 The code optimization methods used for application installation are different:

Dalvik Runtime: dex2opt (http: // 124.16.139.131: 24080/lxr/source/dalvik/dexopt/OptMain. cpp? V = android-4.0.4 # f_OptMain.cpp)

ART Runtime: dex2oat (https://android.googlesource.com/platform/art/+/kitkat-release/dex2oat/dex2oat.cc)

 

2.2. the optimized file size and format are different:

The path and file name of the optimization code generated by the two runtime environments are:/data/dalvik-cache/app/data @ app @ {package name).apk @ classes. dex

The size of the optimization code file generated in the ART environment is significantly larger than that in the Dalvik environment:

 

Although they all end with a. dex file, the file format is quite different:

ART Environment File Format: ELF Shared Object

 

Dalvik Environment File Format:

 

Iii. Source Code of ART

 

Source code: (https://android.googlesource.com/platform/art/+archive/kitkat-release.tar.gz)

From the source code file directory name, you can clearly understand the functions of related files in various folders. We are most concerned with three folders: compiler, dex2oat, and runtime:

Compiler: mainly responsible for the conversion of Dalvik bytecode to local code, compiled into libart-compiler.so

Dex2oat: converts DEX files to ELF files. Compiled as dex2oat

Runtime: Android ART runtime source code, compiled as libart. so

 

Iv. dex2oat optimization process

 

During application installation, installd uses dex2oat to optimize the Dalvik bytecode of the APK installation package classes. dex as the local machine code. The overall optimization is:

 

 

 

For more information about LLVM compiler, see:

Http://llvm.org/

Http://www.ibm.com/developerworks/cn/opensource/os-createcompilerllvm1/

Http://www.chinaicexpo.com/market/1104-llvm.html

 

V. OAT File Format

 

An OAT file is actually a private file format based on the ELF format.

 

ELF segment information of OAT:

 

ELF export information of OAT:

 

The OAT file loading process is as follows:

1. Read the oatdata symbolic address to obtain the Oat data startAddress.

2. Read the oatlastword symbolic address to obtain the OAT data endAddress.

3. Locate Oat data through startAddress and endAddress.

4. parse Oat data. Build a method to locate the required data structure.

Then you can call the code to load the OAT file.

 

There is no big difference between the entire method Locating Process and the Dalvik runtime environment. Readers can learn how to locate a method of a class through (http://blog.csdn.net/androidsecurity/article/details/8664778.

You can simply think that the difference between ART and Dalvik is that the method that Dalvik locates is the Davlik bytecode, but the method that ART locates is the local code. Only the content of the method code has changed, but the process of locating the method is basically the same.

 

We split the OAT file data segment with key address points:

ELF header:

OAT data content starts: (Note the position 0x10BB and DexHeader starts)

Executable local code:

OAT data end location:

 

You can view the source code for the specific OAT file format.