64k of various anomalies
When your application and library references reach a certain scale, you encounter build errors that show that your application has reached the limits of an Android application build architecture. Earlier versions of the build system reported this error as follows:
Conversion to Dalvik format failed:
Unable to execute Dex:method ID No in [0, 0xFFFF]: 65536
Or
Unexpected top-level EXCEPTION:
Java.lang.IllegalArgumentException:method ID not in [0, 0xFFFF]: 65536
At Com.android.dx.merge.dexmerger$6.updateindex (dexmerger.java:501)
At com.android.dx.merge.dexmerger$idmerger.mergesorted (dexmerger.java:282)
At Com.android.dx.merge.DexMerger.mergeMethodIds (dexmerger.java:490)
At Com.android.dx.merge.DexMerger.mergeDexes (dexmerger.java:167)
At Com.android.dx.merge.DexMerger.merge (dexmerger.java:188)
At Com.android.dx.command.dexer.Main.mergeLibraryDexBuffers (main.java:439)
At Com.android.dx.command.dexer.Main.runMonoDex (main.java:287)
At Com.android.dx.command.dexer.Main.run (main.java:230)
At Com.android.dx.command.dexer.Main.main (main.java:199)
At Com.android.dx.command.Main.main (main.java:103)
The latest version of the Android build system shows a different error, but the same problem:
Trouble writing output:
Too many field references:131000, Max is 65536.
The May try using--multi-dex option.
Or
Error: The number of method references in a. dex file cannot exceed 64K.
The error above shows a common number: 65536. This number is important, it represents the total number of references that can be invoked in a single code Dalvik executable (DEX) bytecode file. If your Android application has this error, congratulations, your code has reached a certain amount! This article explains how to resolve this limitation and continue building the application.
About the K reference limit
The android Application (APK) contains executable bytecode file (DEX) files in the form of a Dalvik executable file that contains compiled code to run your application. Dalvik executable specification limit a Dex file contains 65,536 methods: The Android Framework method, the total number of library methods, and the total number of your own code methods. Because 65536 equals 64x1024, this limit is referred to as a "64k reference limit."
This limit requires us to configure the application build process, need to generate multiple Dex files, so called Multidex configuration.
Analysis of causes and precautions
Solution divided into Android 5.0 and above systems and 5.0 of the following system how to do. Sir do not worry, first look at me to analyze the reasons, after all, I want to install the force haha.
One, the version of Android 5.0 below
The system before the Android 5.0 (API leve 21) uses Dalvik to execute application code. By default, Dalvik restricts one apk to only one Dex file. To circumvent this limitation, we can use the Multidex support library, which is part of our APK main dex file, which manages our APK access to other Dex files and code.
Note: If our project minsdkversion is 20 or lower, run to the Android 4.4 (API leve 20) or a lower version of the device, you need to disable Androidstudio for immediate operation
II, Android 5.0 and later
Android 5.0 (API leve 21) and higher system use runtime is art, native support loads multiple Dex files from the applied apk file. Art compiles applications when the application is installed, scanning multiple classes (... N). dex files are compiled into a. oat file. For more information on Android5.0 runtime, see Running-instant-run immediately.
Note: If you use instant running, Androidstudio automatically configures your application, your application's minsdkversion should be set to 21 or higher. Because you're only working on the debug version of your app, you still need to configure your release version to avoid the 64k limit with Multidex.
Try to avoid 64k restrictions
Before configuring our app to enable 64k or more method references, we can reduce the total number of schedules in the application code, including our own application methods and third-party libraries, and the following strategies may help you:
• Check the direct and indirect dependencies of your app: Sometimes the library is very large when we use some of the methods or functions of a libaray, and reducing this dependency can be very effective against 64k problems.
• Use the code obfuscation Proguard to confuse the removal of unused code in the formal packaging build, that is, not to package unused code into our apk.
Using the above methods can help us avoid generating too many useless methods in our applications and reduce our APK size, which is very helpful for students who upgrade their apps with their own servers.
Here to recommend the next Ningyugang students plug-in Development framework:HTTPS://GITHUB.COM/SINGWHATIWANNA/DYNAMIC-LOAD-APK, Joint participation in the developer: Tian Xiao, Song Siyu.
Solve 64k problem
Android Plugin Gradle in the Android SDK build tools 21.1 or later. Make sure you update the Android SDK build tools and Android support to the latest version, and then configure the application with Multidex. We have to do two steps.
The first step is to modify the Build.gradle file for the main module
Rely on Multidex in Gradle, and enable multidexenable:
Android {
compilesdkversion
buildtoolsversion
defaultconfig {
...
Minsdkversion
targetsdkversion ...
enabling Multidex support.
multidexenabled true
}
dependencies {
compile ' com.android.support:multidex:1.0.1 '
}
Step two , Inherit Android.support.multidex.MultiDexApplication class
Two situations
In the first case, if our app does not rewrite the application class, we inherit multidexapplication directly and then register application in Manifest.xml.
In the second case, if we have rewritten the application class, rewrite the Attachbasecontext (context) method, and call Multidex.install (this);
protected void Attachbasecontext (context base) {
super.attachbasecontext (base);
Multidex.install (this);
Because I have turned over the source code of Multidexapplication, inside is rewrite this method just haha:
public class Multidexapplication extends application {public
multidexapplication () {
}
protected void Attachbasecontext (context Base) {
super.attachbasecontext (base);
Multidex.install (this);
}
Register Application
<?xml version= encoding=?>
<manifest xmlns:android=
package=>
...
android:name= "Just rewrite the application full class name" > ...
</application>
</manifest>
Some limiting factors of Multidex library
The process of installing a dex file into a device is very complex, and if the second Dex file is too large, it may cause the application to be unresponsive. You should use Proguard to reduce the size of the Dex file at this time.
• Due to Dalvik linearalloc bugs, apps may not start up before Android 4.0, and if your application supports these versions, you need to perform more tests.
• Similarly, because of the limitations of Dalvik Linearalloc, requesting large amounts of memory can cause crashes. The Dalvik Linearalloc is a fixed size buffer. During the installation of the application, a program named Dexopt is run to prepare for the application to run in the current model. Dexopt uses Linearalloc to store the applied method information. The Android 2.2 and 2.3 buffers only have 5mb,android 4.x raised to 8MB or 16MB. A dexopt crash occurs when the number of methods is too large to exceed the buffer size.
The Multidex build tool also does not support specifying which classes must be contained in the first Dex file, and may cause some class libraries (for example, a class library to access Java code from native code) to be unusable.
After using the Multidex construction optimization
One, so if the application contains Lirary engineering, the following error may occur:
Unexpected top-level EXCEPTION:
Com.android.dex.DexException:Library dex files are not supported in Multi-dex mode
This time we need to disable precompilation:
Android {
...
dexoptions {
predexlibraries = False
} ...
}
If you encounter the following error at run time:
Unexpected top-level ERROR:
Java.lang.OutOfMemoryError:Java Heap Space
We need to increase the size of the Java heap memory:
Maxprocesscount 4//This is the default value
Javamaxheapsize "2g"
Third, improve the running speed
The Android Leve 21 or higher SDK version. Using the art-supported format to generate Multidex output is faster, saving us time, so we don't have to debug the use is also compatible to 5.0 below, so we configure the minimum version of when to do the following compatibility:
Android {
Productflavors {
//custom preferences.
dev {/
/build Faster
minsdkversion
}
prod {//
real production environment
in Android Leve 21 or later. Minsdkversion}
}
dependencies {
compile ' com.android.support:multidex:1.0.1 '
}
What about Android plugin Gradle version less than 1.1?
You need to add the following dependent multidex-instrumentation:
dependencies {
androidtestcompile (' com.android.support:multidex-instrumentation:1.0.1 ') {
exclude group: ' Com.android.support ', module: ' Multidex '
}
}
Eclipse jar Pack Download: Http://xiazai.jb51.net/201609/yuanma/androidsupportmultidex (jb51.net). rar
Official Reference documents: https://developer.android.com/tools/building/multidex.html
The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.