我的应用程序的下一个版本大约有70K方法。
了解使用Multidex（通常意味着使用Multidex支持库来支持API＆lt; 21）的确切含义对我做出此决定非常重要：
我是否应该付出很多努力（例如通过微调我的Proguard配置以更积极地缩小，转储一些第三方库等）以符合64K方法限制，或者我应该只启用Multidex？< / em>的
documentation表明Multidex支持库可能会产生严重的副作用（请参阅Limitations of the multidex support library）。
我真正期待什么？
非常感谢您自己迁移到Multidex的反馈。
答案 0 :(得分：16)
我不是Dalvik的专家，但是我参与了几个项目，这些项目在某些时候需要MultiDex，这些是我学到的一些经验教训：
某些设备上的安装失败？
某些设备，特别是旧的Gingerbread手机（还有ICS），使用非常小的LinearAlloc缓冲区，这可能会在安装或冷启动具有too many classes或class hierarchy is too complex的应用时导致错误。启用MultiDex不会直接导致此问题，但允许开发人员继续“代码膨胀”，直到应用程序变得太大而无法在这些设备上运行...有时只有在数百名非常悲伤的用户启动时才会注意到致电您的客户支持。
应用程序启动缓慢（第一次启动或始终启动）？
安装或升级后的第一次启动肯定较慢，这主要是由于将二级dex文件从APK提取到文件系统所需的昂贵的I / O操作。后续启动也会因为为了调出您的第一个Activity而必须加载的类的大小和复杂性成比例地受到影响，因此keep the main components of the app (specially activities) in the primary dex最大限度地缩短启动时间是件好事，尽管并非总是可行这样做。
某些设备上的新崩溃或ANR？
我们在Alcatel OneTouch（2.3.3）和谷歌Nexus One（2.3.6）手机中看到了由dex提取耗时太久引起的ANR。在更现代的设备中，升级和冷启动multidex应用程序可能需要更长的时间，但通常不足以导致ANR。
整体性能下降？
类加载变得慢得多，并且以不可预测的方式影响应用程序。如果您使用DI系统，Protobuf或其他生成数百个类的框架，那么您可能会发现一些应用程序工作流becoming 20-25% slower after enabling multidex。减轻这种情况的一种方法是通过例如后台线程或BroadcastReceiver提前加载类，但这些当然会增加应用程序的内存占用量并可能减慢设备速度。
此外，如果dexopts发现主要dex中缺少类，那么也可能会跳过一些安装时dex优化，因此即使只有几个类在二级中结束，也可能会在CPU和内存使用方面造成相当大的损失。 dex文件。
我是否应该付出很多努力（例如，通过微调我的Proguard配置以更积极地缩小，倾倒一些第三方库等）以符合64K方法限制，或者我应该启用Multidex？
MultiDex解决了64K方法限制，但它不是银弹，不应该以恕我直言为借口来避免优化APK的大小但是如果
然后MultiDex可能是合适的，否则剥离不必要的代码是可行的方法。
答案 1 :(得分：4)
我最终选择了multidex，主要是因为我的应用程序的路线图最终会迫使我这样做（因为我计划在不久的将来集成大型库）。
已经超过一个月，数十万次安装/更新了多索引APK，所以我现在可以放心地说，在我的特定情况下，转向multidex并没有任何明显的副作用。
（注意：更新仅针对API 11+，所以我不能说Android 2.x的潜在问题。）