DEX 方法超过64K限制和gradle编译OOM问题解决
2016-02-23 11:12
435 查看
如果你是一个android开发者,你至少听说过的Dalvik的蛋疼的64K方法限制。概括地说,在一个DEX文件,你可以调用很多的方法,但你只能调用它们最前面的65,536个 ,因为这是在方法调用集合中的所有的空间了。如果你的源代码和狂拽炫酷叼炸天的三方库中方法超过了这个限制。看这篇文章就对了。
点此查看更多相关话题
为了解决这个问题,Android开发社区有人想出了一些解决方案,比如dmarcato的这个,还有casidiablo的这个。他们都是可行的,但是需要一些比较严格的条件。
最终,Google决定提供一套官方的解决方案,在10月14日的时候发布了MultiDex 支持库,随后几周gradle在 v0.14.0版本中也支持了。
第1步
添加依赖于你的build.gradle支持MultiDex库
第2步
在buildType或productFlavor中开启multiDexEnabled。
现在,根据你的项目情况,你有3种选择:
如果你没有创建自己的Application 类,在你的清单文件AndroidManifest.xml中配置
如果你有自己的Application类了,让它继承
如果你的Application继承了其他的类,并且你不想改变或者没办法改变。按照下面的方法重写
不论你选择上面哪种,都会创建多个大小差不多的dex文件代替单个庞大的dex文件。运行的时候回同事加载所有的这些dex文件。
当年编译app的时候,Gradle会生成很多个dex文件和一个apk文件让你可以在设备或者模拟器上运行。
![](http://img3.07net01.com/upload/images/2015/08/01/1642190012038142.png)
你可以从这个项目看到上面的效果
对于有很多依赖的项目,编译可能因为下面的错误中断
在build.gralde android标签下面添加下面代码可以解决
应用启动缓慢
根据我们的经验,添加了这个支持库以后,大多数情况下都正常了。这对某些设备,比如Kindle Fire上面,应用启动会比之前慢很多。加载所有的类在应用一启动的时候会花费大量的时间。这就会导致黑屏一段时间,甚至导致ANR.
UNEXPECTED TOP-LEVEL EXCEPTION: com.android.dex.DexIndexOverflowException: method ID not in [0, 0xffff]: 65536 at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.Java:502) at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:277) at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:491) at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:168) at com.android.dx.merge.DexMerger.merge(DexMerger.java:189) at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:454) at com.android.dx.command.dexer.Main.runMonoDex(Main.java:302) at com.android.dx.command.dexer.Main.run(Main.java:245) at com.android.dx.command.dexer.Main.main(Main.java:214) at com.android.dx.command.Main.main(Main.java:106)
点此查看更多相关话题
为了解决这个问题,Android开发社区有人想出了一些解决方案,比如dmarcato的这个,还有casidiablo的这个。他们都是可行的,但是需要一些比较严格的条件。
最终,Google决定提供一套官方的解决方案,在10月14日的时候发布了MultiDex 支持库,随后几周gradle在 v0.14.0版本中也支持了。
使用MultiDex支持库
如果你在使用 Android Studio,这个用起来很简单。如果不是,强烈建议你迁移过来。因为Google很快就会不知处Eclipse插件和旧的基于Ant的系统构建方式。第1步
添加依赖于你的build.gradle支持MultiDex库
dependencies {
compile 'com.android.support:multidex:1.0.1'
}
第2步
在buildType或productFlavor中开启multiDexEnabled。
defaultConfig { ... multiDexEnabled true ...}
现在,根据你的项目情况,你有3种选择:
如果你没有创建自己的Application 类,在你的清单文件AndroidManifest.xml中配置
android.support.multidex.MultiDexApplication就可以了。
.... android:name="android.support.multidex.MultiDexApplication" ...
如果你有自己的Application类了,让它继承
android.support.multidex.MultiDexApplication而不是
android.app.Application
如果你的Application继承了其他的类,并且你不想改变或者没办法改变。按照下面的方法重写
attachBaseContext()
public class MyApplication extends FooApplication { @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this);}}
不论你选择上面哪种,都会创建多个大小差不多的dex文件代替单个庞大的dex文件。运行的时候回同事加载所有的这些dex文件。
当年编译app的时候,Gradle会生成很多个dex文件和一个apk文件让你可以在设备或者模拟器上运行。
![](http://img3.07net01.com/upload/images/2015/08/01/1642190012038142.png)
你可以从这个项目看到上面的效果
注意事项
Out of memory 问题对于有很多依赖的项目,编译可能因为下面的错误中断
Error:Execution failed for task ':app:dexDebug'. ... Error Code: 3 Output: UNEXPECTED TOP-LEVEL ERROR: java.lang.OutOfMemoryError: GC overhead limit exceeded at com.android.dx.cf.cst.ConstantPoolParser.parse0(ConstantPoolParser.java:326) ...
在build.gralde android标签下面添加下面代码可以解决
dexOptions { incremental true javaMaxHeapSize "4g"}
应用启动缓慢
根据我们的经验,添加了这个支持库以后,大多数情况下都正常了。这对某些设备,比如Kindle Fire上面,应用启动会比之前慢很多。加载所有的类在应用一启动的时候会花费大量的时间。这就会导致黑屏一段时间,甚至导致ANR.
相关文章推荐
- 利用runtime 实现自定义Model归档
- flv格式学习
- bzoj3561 DZY Loves Math VI 莫比乌斯函数
- iOS网络编程实践--NSStream实现TCP Socket iPhone客户端
- android限制edittext最大行数的方法
- Android学习笔记day4
- Oracle中的自治事务(一)
- 何时使用SpringAOP与aspectJ
- intellij idea中文变口口
- Jenkins进阶系列之——06更改Jenkins的主目录
- ActiveMQ
- bootstrap实现手风琴功能(树形列表)
- iOS的远程消息推送服务。
- Your binary is not optimized for iPhone 5
- sql newid()随机函数
- [Locked] 3Sum Smaller
- SpringMVC-Spring-Mybatis
- POJ 2763 Housewife Wind
- Character
- poj2823Sliding Window【单调队列经典题】