In android, dalvikchecks and optimizes the process of .apk/. jar.

Dalvik's target platform is a small ram such as Android, low-speed flash memory, and a device running standard Linux systems. To achieve better performance of such a platform, we need to consider the following points:
1. To reduce system memory usage, bytecode can be shared among multiple processes. For security reasons, such bytecode cannot be edited.
2. To ensure the response speed, loading a new app takes as little time as possible.
3. Storing multiple class files in standard Java results in a large amount of redundancy. To save app space, this problem must be solved.
4. parsing the field members of the class will cause extra consumption when loading the class. It would be better to directly access it like C.
5. bytecode verification is necessary, but it is very slow. We need to separate verification from app execution.
6. bytecode optimization (such as command optimization and method pruning) can greatly affect execution speed and battery consumption.
Both standard VMSProgramAt startup, extract each class file into heap, and each process has a copy. This method causes a loss in both memory usage and time, but facilitates the optimization of commands.
Now let's take a look at how Dalvik works:
1. Multiple classes are integrated into a single Dex file.
2. Dex files are shared read-only among processes.
3. byte ordering and word alignment are adjusted according to the local system.
4. Use bytecode verification as early as possible.
5. Optimization for bytecode modification must be performed in advance.
The benefits of doing so are described below.

VM operation

APPLICATIONS IN THE SYSTEMCodeThe file .jaror .apk exists. All of them are. ZIP files, but some file header information is added. The dexfile also decompress the .apk file classes. Dex. Classes. the bytecode in Dex is compressed, and the file header is not necessarily word aligned. Therefore, you cannot directly execute MMAP to the memory, but decompress it first, and then perform realignment, optimization, verification operation. The following describes the process in detail.

preparation

optimize Dex files before execution (the optimized Dex is called odex and optimization Dex). There are at least three methods:
1. JIT Technology of VM. The optimized files are stored in the/data/Dalvik-cache directory. This method is valid in the system compiled in the simulator and ENG mode. Only in these two cases can the Dalvik-cache directory be operated without permission issues.
2. Optimize the system installer when installing the application. This requires the write permission of the Dalvik-cache directory.
3. Optimize the system source code compilation. In this way, the JAR/APK file will not be modified, but the classes. Dex will be optimized. The optimized DEX and the original file will be written to the system image together in the same directory.
The/data/Dalvik-cache directory in the system belongs to system/system, and the permission is 0771. The odex file stored in this directory is owned by the system and the group to which the application belongs. The permission is 0644. The DRM-locked application uses the 640 permission. The bottom line is that you can read your own Dex files and most other applications, but cannot create, modify, or delete them.
the preparation of DEX files using JIT and system installer is divided into three steps:
1. The Dalvik-Cache folder is created by system installer, this program runs in the root-authorized installd process.
2. Extract classes. DEX and reserve some space in the file header to store odex header information.
3. In order to facilitate usage and make some minor adjustments to a specific system, MMAP it. Such as byte-swapping and structure realigning. We will also perform basic checks such as the file offset and whether the data index is out of bounds.
the compilation system uses a complicated process to do these tasks: Start the simulator and forcibly execute JIT Optimization on all related Dex files, finally, the optimized results are extracted from Dalvik-cache. Instead of using a tool on the PC, you can see the reason for optimization later.
when Byte-swapping and align of the Code are completed, our preparation is completed. After verification and optimization are completed, we will add the calculated information to the header of the odex file and start execution.

Dexopt

In fact, if we want to optimize the class files in Dex, the simplest and safest way is to load all the classes into the VM and run them again, if the operation fails, verification and optimization are not found. However, this will allocate resources that are difficult to release. For example, when a local database is loaded. Therefore, you cannot use the VM that runs the program.
Our solution is to use the dexopt program, which will initialize a VM, load the DEX file and execute verification and optimization. After completion, the process exits and all resources are released. In this process, you can also use the same Dex for multiple VMS. File lock allows dexopt to run only once.

Verification

The verification process of bytecode involves instructions in all classes and methods in each Dex file. The goal is to check the invalid command sequence. After this is done, you don't have to worry about the operation. Many calculations involved in this process also exist in the GC process.
For efficiency, the optimization mentioned in the next section assumes that verification has been successfully run. By default, Dalvik verification is performed on all classes, and optimization is executed only for classes with verification success. When the verification process fails, we may not report it (for example, calling a class within the package in different packages). We will throw an exception during execution. Because it is slow to check the access permissions of each method.
Verification-successful classes have a flag set in the odex file. Verification is not performed when they are loaded. The security mechanism of Linux system will prevent this file from being damaged, but if you can bypass it, you can still destroy it. The odex file has a 32-bit checksum, but only one quick check can be performed.

Optimization

The VM interpreter performs some optimization when running a piece of code for the first time. For example, replace a constant pool reference with a pointer to an internal data structure, and replace some permanently successful operations or fixed code with a simpler form. Some of the information required for the optimization can only be obtained at runtime, and some can be inferred.
The optimization made by Dalvik includes the following:
1. Modify the method index to vtable index for calling virtual methods.
2. Modify the get/put field to the byte offset. Merge Boolean, byte, Char, short, and other types of variables into a 32-bit format. Less code can use the I-cache of the CPU more effectively.
3. perform inline using a large number of simple methods, such as string. Length (). This reduces the overhead of method calls.
4. Delete the empty method.
5. Add some computed data. For example, if the VM needs a hash table to find the class name, we can perform computation in the optimization phase, instead of loading the dex.
All command modifications use commands not defined in the Dalvik standard to replace the original commands. In this way, we can freely combine optimization and unoptimized commands. The specific operation is related to the VM version.
The optimization process has two points to note:
1. If the VM is updated, the vtable index and byte offset may be updated.
2. If the two Dex indexes are mutually trusted and one of them is updated, make sure that the optimized index and offset are valid.

Dependencies and limitations

The optimized Dex contains a list of DEX files it trusts, and adds CRC-32 and modification time. The file list contains the file path under the Dalvik-cache directory and the corresponding SHA-1 signature. However, the timestamp of files on the device cannot be trusted or used. There are also VM version numbers.
If the DEX currently depends on is updated, we also need to update the current Dex. If we can make a JIT dexopt call, the update process is very easy. But if you can only rely on installer daemon, or the Dex is installed in odex, the VM can only reject it.

The output of dexopt is related to the platform version and Vm version. It is difficult to compile a dexopt running on the PC, and the optimized output is hard to use on other devices. Therefore, dexopt runs on the target device or the simulator of the target device.

The source address of the document is here:

Http://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html