使用Multidex对app性能、稳定性、兼容性的影响.？

Question

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

了解使用Multidex (这通常意味着使用Multidex支持库来支持API<21)的确切含义对我来说非常重要：

我是否应该付出很大的努力(例如，通过微调我的前卫配置来更积极地收缩，抛掉一些第三方库等等)。要遵守64K方法的限制，还是应该启用Multidex？

文档建议Multidex支持库可能有一些严重的副作用(参见Limitations of the multidex support library)。

我真正期望的是什么？

• 某些设备安装失败？
• 应用程序的启动速度慢(在第一次启动时还是始终如此)？
• 新的崩溃或在某些设备上的ANR？
• 整体性能下降？

您自己迁移到Multidex的反馈将是非常感谢的。

Answer 1

我不是Dalvik的专家，但我从事过几个需要MultiDex的项目，这是我学到的一些经验教训：

某些设备安装失败？

有些设备，特别是旧的姜饼手机(也包括ICS)，使用一个非常小的LinearAlloc缓冲区，在安装或冷启动带有太多的课程或其类层次结构太复杂了的应用程序时可能会导致错误。启用MultiDex并不直接导致这个问题，但允许开发人员继续“代码膨胀”，直到应用程序变得太大以至于无法在这些设备上运行……有时只有当数百个非常悲伤的用户开始打电话给您的客户支持时才会注意到这一点。

应用程序的启动速度慢(在第一次启动时还是始终如此)？

安装或升级后的第一个启动肯定要慢一些，这主要是因为从APK提取辅助dex文件到文件系统需要昂贵的I/O操作。随后的启动也与类的大小和复杂性成正比，这些类必须加载才能打开第一个Activity，所以将应用程序的主要组件(特别是活动)保存在主dex中。可以最大限度地缩短启动时间，尽管这样做并不总是可能的。

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

我们在Alcatel OneTouch (2.3.3)和Google (2.3.6)的手机中看到过长时间由dex提取引起的and。在更现代的设备中，升级和冷启动multidex应用程序可能需要更长的时间，但通常不足以导致ANR。

整体性能下降？

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

另外，如果右旋机器人发现主dex中缺少类，那么一些安装时的dex优化也可能被跳过，因此在CPU和内存使用方面可能会有相当大的损失，即使只有几个类最终出现在辅助dex文件中。

我是否应该付出很大的努力(例如，通过微调我的前卫配置来更积极地收缩，抛掉一些第三方库等等)。要遵守64K方法的限制，还是应该启用Multidex？

MultiDex解决了64K方法的限制，但它不是一个银弹，IMHO不应该被用作借口来避免优化APK的大小，但是如果

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

然后MultiDex可能是合适的，否则剥离不必要的代码是可行的。

Answer 2

我最终使用了multidex，本质上是因为我的应用程序的路线图会迫使我最终这么做(因为我计划在不久的将来集成大型图书馆)。

一个多月以来，已经有数十万台APK安装/更新，所以我现在可以很有信心地说，在我的具体情况下，迁移到multidex并没有产生任何明显的副作用。

(注意:更新只针对API 11+，所以我不能谈论Android2.x的潜在问题)。