Android package MultiDex policy details, android package multidex

Android package MultiDex policy details, android package multidex

1. Subcontracting background

First, we will introduce the background of MultiDex.

When the Android system installs an application, one step is to optimize Dex. In this process, there is a dedicated tool for processing, called DexOpt. DexOpt is executed when Dex files are loaded for the first time. This process generates an ODEX file, Optimised Dex. Execution of ODex is much more efficient than direct execution of Dex files.

However, in the early Android system, DexOpt had a problem. DexOpt would retrieve the method IDs of each class and put them in a linked list structure. However, the length of the linked list is saved as a short type, so that the number of method IDs cannot exceed 65536. When a project is large enough, it is clear that the maximum number of methods is not enough. Although DexOpt fixes this issue in the new version of Android, we still need to be compatible with earlier versions of Android.

To solve the problem that the number of methods exceeds the limit, you need to split the dex file into two or more. Therefore, Google officially launched the multidex compatibility package, with AndroidStudio, an APK contains multiple dex functions.

During Android development, we will constantly add new features in the App code and introduce new class libraries. If no control is added, an error will occur in the editor IDE:

Error:Execution failed for task ':ttt:transformClassesWithDexForDebug'.com.android.build.api.transform.TransformException: com.android.ide.common.process.ProcessException: java.util.concurrent.ExecutionException: com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536

This error is caused by a limit on the total number of methods in the Android app. The Java Virtual Machine Dalvik on the Android platform uses the native short to index the methods in DEX files when executing Java applications in DEX format. This means that the total number of methods that can be referenced by a single DEX file is limited to 65536. Generally, an APK contains a classes. dex file. Therefore, the total number of methods of an Android application cannot exceed this value. This includes the Android framework, class library, and self-developed code.

This problem can be solved by splitting a DEX file into multiple DEX files.

2. subcontract policy implementation

Gradle Configuration:

defaultConfig {      applicationId "XXX"    minSdkVersion 14    targetSdkVersion 23    multiDexEnabled true}.......dependencies {  compile 'com.android.support:multidex:1.0.0'}

In the Application class rewrite method of the Application:

@Overrideprotected void attachBaseContext(Context base) {  super.attachBaseContext(base);  MultiDex.install(this);}

3. subcontract effect description

After the preceding configuration, your application can implement multiple DEX files. When an application is built, the build tool analyzes which classes must be placed in the first DEX file and which classes can be placed in the attached DEX file. After it creates the first DEX file, it will continue to create additional DEX files, such as classes2.dex and classes3.dex, if necessary. The Multidex Support class library will be included in the first DEX file of the application to help access other DEX files.

Although Google solves the limit on the total number of application methods, it does not mean that developers can expand the project scale at will. Multidex still has some restrictions:

The process of installing the DEX file to the device is very complex. If the second DEX file is too large, the application may not respond. In this case, use ProGuard to reduce the size of the DEX file.

Because of the Dalvik linearAlloc Bug, the application may not be able to start in versions earlier than Android 4.0. If your application needs to support these versions, perform more tests.
Similarly, because of the Dalvik linearAlloc restrictions, a large number of memory requests may cause a crash. Dalvik linearAlloc is a fixed-size buffer. During application installation, the system runs a program named dexopt to prepare the application for running on the current model. Dexopt uses LinearAlloc to store the method information of the application. The buffer for Android 2.2 and 2.3 is only 5 MB, and Android 4.x is increased to 8 MB or 16 MB. When the number of methods exceeds the buffer size, dexopt crashes.

-The Multidex build tool does not support specifying which classes must be included in the first DEX file. Therefore, some class libraries (for example, a class library needs to access Java code from the native code) may be unavailable.

4. Suggestions for developers

Developers should avoid using class libraries such as Google Guava, which contains more than 13000 methods.

Try to use Lite/Android class libraries designed for mobile apps, or use a small class library to replace a large class library, for example, Google-gson to replace Jackson JSON. For data exchange formats such as Google Protocol Buffers, the standard implementation will automatically generate a large number of methods. The implementation of Square Wire can solve this problem well.

If the mobile phone of the lower version cannot be used after application subcontracting and the higher version is used normally, check whether the configuration of the package is correct.

Summary

The above is all the details about the Android package MultiDex policy, and I hope to help you. If you are interested, you can continue to refer to other related content on this site. If you have any shortcomings, please leave a message.