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

Question

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

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

我应该付出很多努力(即通过微调我的 Proguard 配置以更积极地缩小，转储一些 3rd 方库等)以符合 64K 方法限制，还是应该只启用 Multidex？

documentation表明 Multidex 支持库可能会产生一些严重的副作用(参见 Multidex 支持库的限制)。

我应该期待什么？

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

非常感谢您对 Multidex 迁移的反馈。

Answer 1

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

Failed installs on some devices?

某些设备，特别是旧的 Gingerbread 手机(还有 ICS)，使用非常小的 LinearAlloc 缓冲区，这可能会在安装或冷启动具有 too many classes 的应用程序时导致错误或谁的class hierarchy is too complex .启用 MultiDex 不会直接导致这个问题，但允许开发人员继续“代码膨胀”，直到应用程序变得太大而无法在这些设备上运行......有时只有在数百名非常悲伤的用户开始时才会注意到调用您的客户支持。

Slow startup of the app (on 1st startup or always)?

安装或升级后第一次启动肯定比较慢，主要是因为从APK中提取二级dex文件到文件系统需要昂贵的I/O操作。后续启动也与必须加载的类的大小和复杂性成正比，以便启动您的第一个 Activity，因此最好使用 keep the main components of the app (specially activities) in the primary dex尽量减少启动时间，尽管并非总是可以这样做。

New crashes or ANRs on some devices?

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

Overall performance degradation?

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

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

Should I put a lot of effort (i.e. by fine tuning my Proguard configuration to shrink more aggressively, dumping some 3rd party libs etc.) to comply with the 64K methods limit, or should I just enable Multidex?

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

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

那么 MultiDex 可能是合适的，否则剥离不必要的代码是要走的路。