Optimization of the first startup time of Android: Pre-compilation and extraction of Odex

Optimization of the first startup time of Android: Pre-compilation and extraction of Odex
Prompt! There are two scenarios for application installation: first, installation when the system is started for the first time; second, installation after the system is started. This blog post is based on the first installation scenario. In the scenario where the system is started for the first time, the system translates dex bytecode into the local machine code for all the APK files in the/system/app,/system/priv-app, And/data/app directories, the dex bytecode is also translated to the local machine code for the APK or JAR files in the/system/framework directory and the external JAR files referenced by these APK. This ensures that in addition to applications, the system services developed using Java in the system will also uniformly translate the local machine code from the dex bytecode. For details, refer to the Process Analysis of replacing the Dalvik Virtual Machine seamlessly during Android ART running on Lao Luo's blog.
I. JVM, DVM, and ART virtual machines

The JVM virtual machine runs java bytecode: java-> java bytecode (class)-> java bytecode (jar) note! The Java Virtual Machine is stack-based. The stack-based machine must use commands to load and operate data on the stack. More commands are required.
Dex bytecode executed by the Dalvik Virtual Machine: java-> java bytecode (class)-> dalvik bytecode (dex) Note: Compared with JVM, Dalvik is based on registers, the optimized and limited memory is allowed to run multiple virtual machine instances at the same time. Each Dalvik application is executed as an independent Linxu process. If there are many classes in an application, many class files will be generated after compilation, and there will be a lot of redundant information between class files. dex format files integrate all the contents of classs files into one file, this reduces the overall File Usage, IO operations, and improves the search speed of the class. In addition, the support for new operation codes is added to dex files, and the file structure is relatively simple. You can use long commands to increase the resolution speed. In addition, the dex file will try to increase the size of the read-only structure to speed up data sharing between processes.
Local machine code executed by the ART virtual machine: java-> java bytecode (class)-> dalvik bytecode (dex)-> optimized android runtime machine code (oat) Note: the AOT (Ahead-Of-Time) Compilation used by ART. When the application is installed for the first Time, the pre-encoding Of bytecode is translated into the machine code and stored locally, that is, it is compiled before the program runs. Dalvik is a typical JIT (Just_In_Time). In this mode, the application Each timeDuring running, the bytecode must be converted to the machine code by the real-time compiler before execution, that is, compilation during the running of the program. Therefore, when the App is running, the ART mode saves the process of interpreting bytecode compared with Dalvik, and reduces the memory usage, thus improving the App running efficiency.

Ii. Odex

From the above section, we know that when compiling and packaging APK, Java classes will be compiled into one or more bytecode files (. class), which is converted into a DEX (Dalvik Executable) file by using the dx tool CLASS file. In general, we can see that the androidapplication is a compressed file suffixed with .apk. We can decompress the apk by using a compression tool. The extracted content contains a file named classes. dex. At the first boot, the system needs to extract the package from the apk and save it in the data/app directory. If the instance is currently running on a Dalvik virtual machine, Dalvik performs the following operations on classes. dex performs a "Translation" and "Translation" process, that is, the dexopt function of the daemon installd, to optimize the dex bytecode. In fact, the dex file generates the odex file, finally, the odex file is stored in the VM cache directory data/dalvik-cache of the mobile phone (note! The generated odex file is still suffixed with dex in the format of system@priv-app@Settings@Settings.apk @ classes. dex ). If currently running in Art mode, Art will also call the/system/bin/dexopt tool to translate dex bytecode into local machine codes when it first enters the system, save it in data/dalvik-cache. It should be noted that, whether it is optimizing the dex bytecode or translating the dex bytecode to the local machine code, the final result is stored in an odex file with the same name, but the former corresponds to a dey file (indicating that this is an optimized dex ), the latter corresponds to an oat file (actually a custom elf file containing local machine commands ). In this way, you do not need to modify any code that references the odex file through an absolute path. Because the application will be installed when the system starts for the first time, the first startup time of the system will be greatly increased when there are many preset APK files. As described above, the optimization results for DEX are stored in an odex file with the same name, no matter whether it is DVM or ART, if we pre-extract the Odex files during ROM compilation, the first startup time of the system will be greatly optimized.

Iii. Pre-compile and extract Odex

Define WITH_DEXPREOPT: = true in BoardConfig. mk. After this macro is opened, odex files will be extracted during pre-Compilation of the preset apk with or without source code.

However, it should be noted that after the WITH_DEXPREOPT macro is opened, extracting Odex during pre-compilation will increase a certain amount of space. Too many apk presets will cause the system. img to be too large, but the compilation will fail. In this case, you can delete the dex file in the apk, increase the size limit of system. img, or skip the odex extraction of some apk during pre-compilation. For example, the method for skipping the helloworld application extraction is as follows:

Add the red flag code to the uildcoredex_preopt_odex_install.mk directory:

I Feq ($ (LOCAL_MODULE ),Helloworld)

LOCAL_DEX_PREOPT: =

Endif

Build_odex: =

Installed_odex: =

....

HelloworldYou can replace it with the LOCAL_MODULE name of the apk that needs to be extracted from odex, such as Settings.