Multidexing android 应用程序的缺点答案

【问题标题】：Disadvantages in Multidexing the android applicationMultidexing android 应用程序的缺点
【发布时间】：2017-01-23 00:31:23
【问题描述】：

最近我读到了有关 Dalvik 65K 方法限制的信息。我了解方法调用列表只能调用前 65536 个方法引用。为了解决这个问题，我们有许多解决方案。其中之一是多重索引，我们使用 android 的支持库将 .dex 文件拆分为多个类 [classes.dex, classes1.dex ...]。

我无法理解的是，Android 应用程序由于这种多重索引而遭受了哪些缺点，以及我们为什么要付出大量努力来最小化引用方法的数量。

在我的理解中，为了减少方法计数，我必须减少模块化，这使得我的代码可读性降低，除了剥离第三方库的代码所花费的小时数。减少方法计数值得吗？

【问题讨论】：

增加了构建时间，我建议避免使用多索引。
@MuhammadBabar 如果将应用程序划分为多个模块，可以减少构建时间。
@AkashKava 这不是更忙于管理吗，或者请举一些例子或好的帖子来解释原因？
@MuhammadBabar 模块是单独编译的，只有当模块内的任何文件被修改时，才会编译整个模块，这样已经编译的模块占用的时间更少。每个模块也可以预先索引，这意味着即使索引时间也会减少。
我们可以使用多个模块来构建一个应用程序吗？

标签： android performance dalvik

【解决方案1】：

您对 multidex 的考虑过多，相反，您应该通过分析您的应用程序来观察并确定您的应用程序是否存在任何性能问题。

Multidexing 几乎不会增加任何代码大小，主要的大小和性能问题是动画/图像/音频/视频资源，它们会增加大小并降低性能。

包括许多第三方库最终将超过 64k 限制，并且当今几乎所有应用程序都是多索引的，如今用户需要多功能应用程序，这需要与许多第三方库集成。

只有在您进行动画/游戏编程时，速度最重要，更多的方法调用可能是有害的，但这与多索引无关，即使写得不好的小型非多索引应用程序在任何设备上都会表现不佳。

启动时间会影响多重索引，但当然可以通过更改您的应用逻辑以延迟加载其他昂贵的库和资源来改善它。

减少方法计数是否值得？？

否

理想情况下，您应该使用更多方法并模块化您的代码，因为测试和更改移动应用程序在发布后是巨大的挑战。与 multidex 大小及其对性能的影响相比，调试和删除 bug 的成本更高。由于屏幕小、品牌不同、用户界面不同，与电脑相比，用户对手机应用程序的愤怒程度更高。如果将代码分成多个单独的测试库，那么跟上用户的需求会变得更容易。

【讨论】：

你确定它不会增加应用加载时间吗？实际如何使用 multi-dex/non-multi-dex 测量应用程序的加载时间？
我已经提到启动时间会影响，这意味着加载模块会很慢，但可能没有太大关系。
我同意@AkashKava。我们总是可以使用多种技术来解决启动时间问题，并且 android 用户习惯于使用闪屏技术。你的回答让我现在头脑清醒了。
如果您的应用不需要先同步任何远程数据，则不建议使用启动画面。开始时间很重要，如果你让他们等待使用应用程序，用户会很生气！
@MuhammadBabar 如果应用程序在启动后表现不佳，则启动时间无关紧要。没有人喜欢有缺陷的应用程序，不管它有多小，多快启动。

【解决方案2】：

主要缺点是更大的 dex/apk 大小。 dex 文件具有常量池，这些常量池在该 dex 文件中的所有类之间共享。当类被拆分到多个 dex 文件中时，这些共享常量必须在它们使用的每个 dex 文件中重复。

【讨论】：

所以你的意思是说android应用程序没有运行时缺陷。具有多个 dex 类的 android 应用程序的行为与只有一个类的应用程序完全相同。除了影响 APK 大小之外，在设备中的应用程序方面没有其他任何问题。保留开发阶段的缺点。
好吧，dex 文件确实必须加载到内存中，所以如果 dex 文件较大... :)
哦！因此，如果需要将dex文件加载到内存中，并且dex文件较大，则加载到内存中将花费更多时间，从而使应用程序的冷启动时间更长。所以应用程序需要更多时间才能启动。这是你的意思吗？
还有内存使用情况
@JesusFreke 你说“主要缺点”。 Dex 文件还有什么问题？

【解决方案3】：

Multidexing 本身是一个非执行术语，如果应用程序是 multidex，则意味着执行应用程序的 android 内部进程存在负担。

每个 android 应用程序都在单个进程（任务）中运行，当它被 multidexed 时，这意味着进程被分成几个部分，无论您如何编写代码，都会对小型 android 处理器造成性能问题。

我同意 aakash kava 的观点，几乎所有应用程序都是多索引的，因为现在 Android 处理器的性能非常好，而 android RAM 也非常出色，但事实并非如此，这意味着我们应该忽略多索引。

【讨论】：

我知道这有点老了，但是 - 对于您在此答案中提出的任何主张，您有任何参考资料吗？
@nasch : 观察 multidexed apk 的工作情况，检查内存工具及其性能，将其与正常 apk 执行和 multidexed apk 执行进行比较，然后你会发现不同之处，当然检查两个 apk 在相同配置的手机或模拟器（最好在真实设备上）
我不想仅仅为了好奇而花时间运行检测测试（我需要为我的应用程序进行多重索引，无论性能是否受到影响），但我做了一些阅读，我认为性能损失是为了在棒棒糖之前的设备上启动应用程序（他们使用 Dalvik，它本身不支持 multidex，而不是支持的 ART）。因此，如果您不支持这些，则无需担心。反正我的意见。

【解决方案4】：

一般来说，multidex 的缺点是：APK 大小增加、应用启动速度可能较慢和内存占用增加。

原因是某些数据（例如StringData）无法共享，因此需要同时部分存储在多个DEX文件中。 StringData 由从代码加载的字符串文字以及类、方法和字段名称组成，通常占 DEX 文件总数的 20%。

但实际缺点（除了 APK 大小）很大程度上取决于您运行应用的 Android 版本。

Google 优化了 Android 运行时 (ART) 以消除这些缺点。 Android O (API 26) 引入了 VDEX 容器来存储预先验证的 DEX 文件。借助 Android P，Google 进一步优化了预编译器（代号 CompactDex），并在 VDEX 容器中添加了共享数据部分，以对多个 DEX 文件中使用的数据进行重复数据删除。因此，在 Android P 运行时运行 multidex 应用程序几乎没有缺点。

来源：What's new in Android Runtime (Google I/O '18)

【讨论】：