Android App solves 65K method limit

Android developers recently announced a new Multidex support library on Google +, providing official support for Android apps with a total of over 65K.

If you're a lucky Android app developer and you're developing a promising app that's constantly adding new features and adding new libraries, one day you'll unfortunately encounter this error:

Conversion to Dalvik format failed:unable to execute Dex:method ID not in [0, 0xFFFF]: 65536

This error is caused by the total number of methods for Android apps. Android platform Java Virtual machine Dalvik uses the native type short to index the methods in the Dex file when executing a Java application in Dex format. This means that the total number of methods that a single DEX file can be referenced is limited to 65536. The APK usually contains a classes.dex file, so the total number of methods for Android apps cannot exceed this amount, including Android frameworks, class libraries, and your own developed code.

This problem can be solved by splitting a Dex file into multiple Dex files. Facebook introduced the Dalvik patch developed for Android apps, and the Android Developers blog describes how to fix this problem by customizing the class loading process. But these methods are somewhat complex and not elegant.

With the release of the new Multidex Support Library, Google officially provides official support to address this issue. An application that builds more than 65K methods describes how to build a multi-Dex application using Gradle.

First Use Android SDK Manager to upgrade to the latest Android SDK Build tools and Android support Library R21. Then do the following two steps:

1. Modify the Gradle configuration file, enable Multidex, and include Multidex support:

Android {compilesdkversion buildtoolsversion "21.1.0"

Defaultconfig {

...

Minsdkversion 14

Targetsdkversion 21

...

Enabling Multidex support.

multidexenabled true

}

...

}

dependencies {compile ' com.android.support:multidex:1.0.0 '}

2. Let the app support multiple Dex files. Three optional methods are described in Multidexapplication Javadoc:

Declare android.support.multidex.MultiDexApplication in the application of androidmanifest.xml;

If you already have your own application class, let it inherit multidexapplication;

If your application class has been inherited from another class and you do not want/can modify it, then you can override the Attachbasecontext () method:

@Override

protected void Attachbasecontext (Context base) {

Super.attachbasecontext (base); Multidex.install (this);

}

With the above steps, your app can already implement multiple Dex files. When an app 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 (Classes.dex), it continues to create additional Dex files, such as Classes2.dex, Classes3.dex, if necessary. Multidex's support class library will be included in the application's first Dex file to help implement access to other Dex files.

The paper also describes the test methods for improving development efficiency and multi-dex applications by setting productflavors when developing multi-dex applications.

Android 5.0 and later versions use the runtime named Art, which natively supports loading multiple Dex files from the apk file. When the app is installed, it performs precompilation, scanning classes (. N). dex files are then compiled into a single. oat file for execution. Learn more about art.

While Google solves the problem of applying the total number of methods, it does not mean that developers can scale their projects arbitrarily. Multidex still have some limitations:

Dex files are very complex to install to a device, and if the second Dex file is too large, it can cause the app to be unresponsive. You should use Proguard to reduce the size of the Dex file.

Due to Dalvik linearalloc bugs, apps may not start in versions prior to Android 4.0, and if your app wants to support these versions, it will run more tests.

Also because of the limitations of Dalvik Linearalloc, requests for large amounts of memory can cause crashes. Dalvik Linearalloc is a fixed-size buffer. During the installation of the app, a program called Dexopt is run to prepare the app for running in the current model. Dexopt uses Linearalloc to store the application's method information. Android 2.2 and 2.3 buffers only 5mb,android 4.x increased to 8MB or 16MB. Dexopt crashes when too many methods result in exceeding the buffer size.

The Multidex build tool also does not support specifying which classes must be included in the first Dex file, so it is possible that some class libraries (such as a class library that needs to access Java code from native code) cannot be used.

Avoiding too much application and too many methods is still a concern for Android developers. Mihai Parparita's Open source project dex-method-counts can be used to count the number of methods for each package in the APK.

Usually the developer's own code is hard to reach, but with the addition of a third-party class library, the number of methods expands rapidly. So choosing the right class library is especially important for Android developers.

Developers should avoid using a class library like Google Guava, which contains more than 13,000 methods. Try to use a Lite/android version class library designed for mobile apps, or replace a large class library with a small class library, such as replacing the Jackson JSON with Google-gson. For data interchange formats such as Google Protocol buffers, the standard implementation automatically generates a number of methods. The implementation of square wire is a good solution to this problem.

Android App solves 65K method limit