使用Multidex对应用性能,稳定性和兼容性的影响…?

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

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

我应该付出很多的努力(例如,通过微调我的Proguardconfiguration来更积极地缩减,倾销一些第三方库等)以符合64K方法的限制,还是应该启用Multidex?

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

我应该期待什么?

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

从您自己的迁移到Multidex的反馈将不胜感激。

Solutions Collecting From Web of "使用Multidex对应用性能,稳定性和兼容性的影响…?"

我不是Dalvik的专家,但是我曾经在几个项目上工作过,这些项目在某些时候需要使用MultiDex,这些是我学到的一些经验教训:

在某些设备上安装失败?

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

应用程序启动缓慢(第一次启动或总是)?

安装或升级后的第一次启动肯定比较慢,主要是由于将APK从辅助dex文件从APK提取到文件系统所需的昂贵的I / O操作。 随后的启动也会影响到为了显示第一个Activity而必须加载的类的大小和复杂性,所以最好将应用程序的主要组件(特别是活动)保留在主要的dex中,以尽量减less启动时间,尽pipe这并不总是可能的。

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

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

整体性能下降?

类加载变得非常慢,并以不可预知的方式影响应用程序。 如果您使用DI系统,Protobuf或其他一些产生数百个类的框架,那么在启用multidex之后,您可能会发现一些应用程序工作stream程变慢了20-25% 。 缓解这种情况的一种方法是通过后台线程或BroadcastReceiver提前加载类,但是这些会增加应用程序的内存占用空间,并可能使设备速度变慢。

另外,如果dexopts发现从主dex缺less的类,那么也可能会跳过一些安装时dex优化,所以即使只有几个类在secondary dex文件中结束,CPU和内存使用率也可能会受到相当大的损失。

我应该付出很多的努力(例如,通过微调我的Proguardconfiguration来更积极地缩减,倾销一些第三方库等)以符合64K方法的限制,还是应该启用Multidex?

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

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

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

最后,我用multidex,本质上是因为我的应用程序的路线图将迫使我最终这样做(因为我打算在不久的将来整合大型图书馆)。

已经有一个多月的时间,数十万次的多指数APK的安装/更新,所以我现在可以有信心地说,在我的具体情况下,多指标的转变没有任何明显的副作用。

(注意:更新只针对API 11+,所以我不能说与Android 2.x的潜在问题)。