咱们在Android开发中,会不断的在App代码里面增长新功能,引入新的类库,若是不加控制的话,那么会碰到编辑器IDE爆出一下错误:html
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
这个错误是Android应用的对方法总数有限制形成的。Android平台的Java虚拟机Dalvik在执行DEX格式的Java应用程序时,使用原生类型short来索引DEX文件中的方法。这意味着单个DEX文件可被引用的方法总数被限制为65536。一般APK包含一个classes.dex文件,所以Android应用的方法总数不能超过这个数量,这包括Android框架、类库和你本身开发的代码。
这个问题能够经过将一个DEX文件分拆成多个DEX文件解决。java
defaultConfig { applicationId "XXX" minSdkVersion 14 targetSdkVersion 23 multiDexEnabled true } ....... dependencies { compile 'com.android.support:multidex:1.0.0' }
@Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); }
配置好相关方法后,必须Clean或者Rebuild下项目,不然可能看到的仍是存在问题的现象。android
通过以上的配置,你的应用已经能够实现多个DEX文件了。当应用构建时,构建工具会分析哪些类必须放在第一个DEX文件,哪些类能够放在附加的DEX文件中。当它建立了第一个DEX文件后,若是有必要会继续建立附加的DEX文件,如classes2.dex, classes3.dex。Multidex的支持类库将被包含在应用的第一个DEX文件中,帮助实现对其它DEX文件的访问。api
虽然Google解决了应用总方法数限制的问题,但并不意味着开发者能够任意扩大项目规模。Multidex仍有一些限制:app
- DEX文件安装到设备的过程很是复杂,若是第二个DEX文件太大,可能致使应用无响应。此时应该使用ProGuard减少DEX文件的大小。
- 因为Dalvik linearAlloc的Bug,应用可能没法在Android 4.0以前的版本启动,若是你的应用要支持这些版本就要多执行测试。
- 一样由于Dalvik linearAlloc的限制,若是请求大量内存可能致使崩溃。Dalvik linearAlloc是一个固定大小的缓冲区。在应用的安装过程当中,系统会运行一个名为dexopt的程序为该应用在当前机型中运行作准备。dexopt使用LinearAlloc来存储应用的方法信息。Android 2.2和2.3的缓冲区只有5MB,Android 4.x提升到了8MB或16MB。当方法数量过多致使超出缓冲区大小时,会形成dexopt崩溃。
-Multidex构建工具还不支持指定哪些类必须包含在首个DEX文件中,所以可能会致使某些类库(例如某个类库须要从原生代码访问Java代码)没法使用。
- 开发者应该避免使用Google Guava这样的类库,它包含了13000多个方法。
- 尽可能使用专为移动应用设计的Lite/Android版本类库,或者使用小类库替换大类库,例如用Google-gson替换Jackson JSON。而对于Google Protocol Buffers这样的数据交换格式,其标准实现会自动生成大量的方法。采用Square Wire的实现则能够很好地解决此问题。
- 在出现应用分包后低版本手机没法使用,高版本正常使用的问题时,能够考虑检查一下分包的配置是否正确。