使用Multidex对应用程序性能,稳定性,兼容性的影响......？

Question

我的应用程序的下一个版本大约有70K方法.

了解使用Multidex的确切含义(通常意味着使用Multidex支持库来支持API <21)对我做出这个决定非常重要:

我应该付出很多努力(例如通过微调我的Proguard配置以更积极地缩小,倾倒一些第三方库等)以符合64K方法限制,或者我应该只启用Multidex？

该文件表明,Multidex支持库可能有一些严重的副作用(见Limitations of the multidex support library).

我真的应该期待什么？

• 某些设备上的安装失败？
• 应用程序启动缓慢(第一次启动或始终)？
• 某些设备上出现新的崩溃或ANR？
• 整体性能下降？

我们将非常感谢您自己迁移到Multidex的反馈.

Answer 1

我不是Dalvik的专家,但是我参与了几个项目,这些项目在某些时候需要MultiDex,这些是我学到的一些经验教训:

某些设备上的安装失败？

有些设备,特别是旧的Gingerbread手机(还有ICS),使用一个非常小的LinearAlloc缓冲区,这可能会导致安装或冷启动具有太多类或类层次结构过于复杂的应用程序时出错.启用MultiDex不会直接导致此问题,但允许开发人员继续"代码膨胀",直到应用程序变得太大而无法在这些设备上运行...有时只有在数百名非常悲伤的用户启动时才会注意到致电您的客户支持.

应用程序启动缓慢(第一次启动或始终)？

安装或升级后的第一次启动肯定较慢,这主要是由于将二级dex文件从APK提取到文件系统所需的昂贵的I/O操作.后续启动也会因为为了提升你的第一个而必须加载的类的大小和复杂性成比例地受到影响Activity,所以最好将应用程序的主要组件(特别是活动)保留在主要dex中以最小化启动时间,虽然并非总能这样做.

某些设备上出现新的崩溃或ANR？

我们已经看到Alxate OneTouch(2.3.3)和谷歌Nexus One(2.3.6)手机中的ANR由于dex提取花费的时间太长.在更现代的设备中,升级和冷启动multidex应用程序可能需要更长的时间,但通常不足以导致ANR.

整体性能下降？

类加载变得慢得多,并且以不可预测的方式影响应用程序.如果您使用DI系统,Protobuf或其他生成数百个类的框架,那么您可能会发现在启用multidex后,您的某些应用程序工作流程会慢20-25%.缓解这种情况的一种方法是通过例如后台线程或者提前加载类,BroadcastReceiver但是这些当然会增加应用程序的内存占用并可能减慢设备速度.

此外,如果dexopts发现主要dex中缺少类,也可能会跳过一些安装时dex优化,因此即使只有几个类最终出现在辅助dex文件中,CPU和内存使用方面也可能会受到相当大的损失.

我应该付出很多努力(例如通过微调我的Proguard配置以更积极地缩小,倾倒一些第三方库等)以符合64K方法限制,或者我应该只启用Multidex？

MultiDex解决了64K方法限制,但它不是一个银弹,恕我直言不应该作为借口,以避免优化APK的大小,但如果

1. 您只针对现代设备(例如API 16+)
2. 性能/冷启动时间并不重要
3. 您没有时间进一步优化应用程序

然后MultiDex可能是合适的,否则剥离不必要的代码是可行的方法.

Answer 2

我最终选择了multidex，主要是因为我的应用程序路线图最终迫使我这样做（因为我计划在不久的将来集成大型库）。

已经有一个多月的时间，并且有数十万次安装/更新了多义APK，所以我现在可以很自信地说，在我的特定情况下，转向多义并没有任何明显的副作用。

（注意：此更新仅针对API 11+，因此我无法谈论Android 2.x的潜在问题）。