Android分包MultiDex策略详解

概述1.分包背景这里首先介绍下MultiDex的产生背景。当Android系统安装一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过

1.分包背景

这里首先介绍下MultIDex的产生背景。

当AndroID系统安装一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。

但是在早期的AndroID系统中，DexOpt有一个问题，DexOpt会把每一个类的方法ID检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的，导致了方法ID的数目不能够超过65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的AndroID系统中，DexOpt修复了这个问题，但是我们仍然需要对低版本的AndroID系统做兼容。

为了解决方法数超限的问题，需要将该dex文件拆成两个或多个，为此谷歌官方推出了multIDex兼容包，配合AndroIDStudio实现了一个APK包含多个dex的功能。

我们在AndroID开发中，会不断的在App代码里面增加新功能，引入新的类库，如果不加控制的话，那么会碰到编辑器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

这个错误是AndroID应用的对方法总数有限制造成的。AndroID平台的Java虚拟机Dalvik在执行DEX格式的Java应用程序时，使用原生类型short来索引DEX文件中的方法。这意味着单个DEX文件可被引用的方法总数被限制为65536。通常APK包含一个classes.dex文件，因此AndroID应用的方法总数不能超过这个数量，这包括AndroID框架、类库和你自己开发的代码。

这个问题可以通过将一个DEX文件分拆成多个DEX文件解决。

2. 分包策略实现

Gradle 配置：

defaultConfig {      applicationID "XXX"    minSdkVersion 14    targetSdkVersion 23    multIDexEnabled true}.......dependencIEs {  compile 'com.androID.support:multIDex:1.0.0'}

在应用的Application 类重写方法：

@OverrIDeprotected voID attachBaseContext(Context base) {  super.attachBaseContext(base);  MultIDex.install(this);}

3.分包效果说明

经过以上的配置，你的应用已经可以实现多个DEX文件了。当应用构建时，构建工具会分析哪些类必须放在第一个DEX文件，哪些类可以放在附加的DEX文件中。当它创建了第一个DEX文件后，如果有必要会继续创建附加的DEX文件，如classes2.dex,classes3.dex。MultIDex的支持类库将被包含在应用的第一个DEX文件中，帮助实现对其它DEX文件的访问。

虽然Google解决了应用总方法数限制的问题，但并不意味着开发者可以任意扩大项目规模。MultIDex仍有一些限制：

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代码）无法使用。

4.对开发者的建议

开发者应该避免使用Google Guava这样的类库，它包含了13000多个方法。

尽量使用专为移动应用设计的lite/AndroID版本类库，或者使用小类库替换大类库，例如用Google-gson替换Jackson JsON。而对于Google Protocol Buffers这样的数据交换格式，其标准实现会自动生成大量的方法。采用Square Wire的实现则可以很好地解决此问题。

在出现应用分包后低版本手机无法使用，高版本正常使用的问题时，可以考虑检查一下分包的配置是否正确。

总结

以上就是本文关于AndroID分包MultIDex策略详解的全部内容，希望对大家有所帮助。感兴趣的朋友可以继续参阅本站其他相关内容，如有不足之处，欢迎留言指出。

总结

以上是内存溢出为你收集整理的Android分包MultiDex策略详解全部内容，希望文章能够帮你解决Android分包MultiDex策略详解所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。