使用Multidex对应用程序性能，稳定性，兼容性的影响...? [英] Impact of using Multidex on app performance, stability, compatibility...?
问题描述
我的应用程序的下一版本大约有7万种方法.
The next version of my app has roughly 70K methods.
知道使用Multidex的确切含义(通常意味着使用Multidex支持库来支持API <21)对于我做出这一决定很重要:
Knowing the exact implications of using Multidex (which usually means using the Multidex support library to support API<21) is important to me to make this decision:
我应该付出很多努力(例如，通过微调Proguard配置使其更主动地收缩，转储一些第三方库等)以符合64K方法限制，还是应该启用Multidex?/em>
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支持库可能会有一些严重的副作用.(请参见 multidex支持库的限制).
The documentation suggests that the Multidex support library may have some serious side effects (see Limitations of the multidex support library).
我真正的期望是什么?
- 在某些设备上安装失败?
- 应用程序启动缓慢(第一次启动还是始终启动)?
- 某些设备上出现新的崩溃或ANR?
- 整体性能下降了吗?
从您自己的迁移到Multidex的反馈将不胜感激.
Feedback from your own migrations to Multidex would be greatly appreciated.
推荐答案
我不是Dalvik的专家，但是我从事过一些需要MultiDex的项目，这些是我学到的一些经验教训:/p>
I'm not a specialist in Dalvik but I've worked on several projects that at some point required MultiDex and these are some of the lessons I learned:
在某些设备上安装失败?
Failed installs on some devices?
某些设备，特别是旧的姜饼手机(也包括ICS)，使用很小的LinearAlloc缓冲区，这可能会在安装或冷启动具有类层次结构太复杂.启用MultiDex不会直接导致此问题，但允许开发人员继续进行代码膨胀"，直到应用变得太大而无法在这些设备上运行...有时只有在数百个非常悲伤的用户开始时才会注意到致电您的客户支持.
Some devices, specially old Gingerbread phones (but also ICS), use a very small LinearAlloc buffer which might cause errors while installing or cold-starting an app that has too many classes or whose class hierarchy is too complex. Enabling MultiDex doesn't contribute directly to this problem but allows developers to continue the "code bloat" up to the point where the app becomes too big to run on those devices... which sometimes only gets noticed when hundreds of very sad users start calling your customer support.
应用程序启动缓慢(是第一次启动还是始终启动)?
Slow startup of the app (on 1st startup or always)?
安装或升级后的首次启动肯定很慢，这主要是由于从APK将次要dex文件提取到文件系统中所需的昂贵的I/O操作.随后的启动也与为了启动第一个 Activity 而必须加载的类的大小和复杂性成比例地受到影响，因此
The first start after installing or upgrading is definitely slower, mainly due to the expensive I/O operations required to extract the secondary dex files from the APK into the file system. Subsequent starts are also affected proportionally to the size and complexity of classes that have to be loaded in order to bring up your first Activity, so it's good to keep the main components of the app (specially activities) in the primary dex to minimize startup time, although it's not always possible to do so.
某些设备上出现新的崩溃或ANR?
New crashes or ANRs on some devices?
我们已经看到，在Alcatel OneTouch(2.3.3)和Google Nexus One(2.3.6)手机中，由于dex提取而导致的ANR时间过长.在更现代的设备中，升级和冷启动Multidex应用程序可能会花费更长的时间，但通常不足以引起ANR.
We've seen ANRs in Alcatel OneTouch (2.3.3) and Google Nexus One (2.3.6) phones that were caused by the dex extraction taking too long. In more modern devices, upgrading and cold starting multidex apps might take a bit longer but usually not long enough to cause ANRs.
整体性能下降了吗?
Overall performance degradation?
类加载变得非常慢，这以不可预测的方式影响应用程序.如果您使用DI系统，Protobuf或其他生成数百个类的框架，则可能会发现某些应用程序工作流
Class loading becomes much slower and that affects the app in unpredictable ways. If you use a DI system, Protobuf or some other framework that generates hundreds of classes then you might find some of your application workflows becoming 20-25% slower after enabling multidex. One way to mitigate this is to load classes ahead of time via, for example, a background thread or a BroadcastReceiver but these, of course, will increate the memory footprint of the app and potentially slow down the device.
此外，如果dexopts发现主dex中缺少的类，则也可能会跳过一些安装时dex优化，因此，即使只有几个类最终在次要dex上，也可能会在CPU和内存使用方面造成可观的损失.dex文件.
Also, some install-time dex optimizations might also be skipped if dexopts finds classes missing from the primary dex, so there might be a considerable penalty in terms of CPU and memory usage even if only a couple of classes end up in secondary dex files.
我应该付出很多努力(例如，通过微调Proguard配置使其更主动地收缩，转储一些第三方库等)以符合64K方法限制，还是应该启用Multidex?
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方法的局限性，但这不是灵丹妙药，不应将恕我直言作为借口，以避免优化APK的大小，但是如果
MultiDex solves the 64K method limit but it's not a silver bullet and IMHO shouldn't be used as an excuse to avoid optimizing the size of the APK but if
- 您只针对现代设备(例如API 16 +)
- 性能/冷启动时间并不关键
- 您没有时间进一步优化应用程序
那么MultiDex可能是合适的，否则剥离不必要的代码是可行的方法.
then MultiDex might be suitable, otherwise stripping unnecessary code is the way to go.
这篇关于使用Multidex对应用程序性能，稳定性，兼容性的影响...?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
