本文主要介绍Android转包MultiDex策略的详细讲解，有一定的参考价值，有需要的朋友可以了解一下。

1.分包背景

首先我们来介绍一下MultiDex的背景。

安卓系统在安装应用的时候，有一步就是优化Dex。有一个叫做DexOpt的特殊工具来处理这个过程。第一次加载Dex文件时执行opt的执行过程。这个过程将生成一个ODEX文件，即优化的索引。执行ODex的效率远高于直接执行Dex文件。

然而，在早期的Android系统中，DexOpt出现了一个问题。DexOpt将检索每个类的方法id，并将其存储在一个链表结构中。但是，这个链表的长度由一个短类型保存，这导致方法id的数量不能超过65，536。当一个项目足够大的时候，显然方法数量的上限是不够的。虽然DexOpt在新版Android系统中修复了这个问题，但是我们还是需要兼容更低版本的Android系统。

为了解决方法数量超出限制的问题，需要将dex文件拆分成两个或更多。为此Google正式推出了multidex兼容包，并与AndroidStudio合作实现了一个APK包含多个dex的功能。

在Android的开发中，我们会不断地在App代码中加入新的功能，引入新的类库。如果我们不控制它，我们将在编辑器IDE中遇到一个错误：

错误：任务执行失败：TTT:transformClassesWithDexForDebug。

com . Android . build . API . transform . transform exception:com . Android . ide . common . process . process exception:Java . util . concurrent . execution exception:com . andro id . dex . dexindexoverflowexception:方法ID不在[0，0xffff]中：65536

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

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

2. 分包策略实现

梯度配置：

defaultConfig {

应用程序Id 'XXX '

minSdkVersion 14

目标版本23

多重可解真

}

.

依赖关系{

编译“com . Android . support:multi dex:1 . 0 . 0”

}

在应用的应用程序类中重写方法：

@覆盖

受保护的void attachBaseContext(Context base){

super . attachbasecontext(base)；

multi dex . install(this)；

}

3.分包效果说明

经过上面的配置，你的应用已经可以实现多个DEX文件了。当应用构建时，构建工具将分析哪些类必须放在第一个DEX文件中，哪些类可以放在其他DEX文件中。当它创建第一个dex文件时，如果需要，它会继续创建额外的dex文件，如classes2.dex，classes3.dex Multi-DEX的支持类库将包含在应用程序的第一个DEX文件中，帮助访问其他DEX文件。

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

将DEX文件安装到设备上的过程非常复杂。如果第二个DEX文件太大，可能会导致应用程序没有响应。这时应该使用ProGuard来减小DEX文件的大小。

由于Dalvik linearAlloc的Bug，应用在Android 4.0之前可能无法启动。如果您的应用程序要支持这些版本，您应该执行更多的测试。

由于Dalvik linearAlloc同样的限制，如果请求大量内存，可能会导致崩溃。Dalvik linearAlloc是一个固定大小的缓冲区。在应用程序的安装过程中，系统将运行一个名为dexopt的程序，为应用程序在当前模型中的运行做准备。Opt使用LinearAlloc来存储应用程序方法信息。Android 2.2和2.3的缓冲区只有5MB，Android 4.x增加到8MB或16MB。当方法数量超过缓冲区时，dexopt将崩溃。

-- multi DEX构建工具尚不支持指定哪些类必须包含在第一个dex文件中，因此某些类库(例如，类库需要从本机代码访问Java代码)可能不可用。

4.对开发者的建议

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

尽量使用专为移动应用设计的Lite/Android版本类库，或者用小型类库代替大型类库，比如用Google-gson代替Jackson JSON。对于Google协议缓冲区等数据交换格式，其标准实现会自动生成大量方法。方丝的实现可以很好的解决这个问题。

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

总结

关于本文中Android转包MultiDex策略的详细解释就这些了。希望对大家有帮助。感兴趣的朋友可以继续参考本站的其他相关内容。如有不足之处，欢迎留言指出。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。