最近我读到了有关Dalvik 65K方法限制的内容。我已经知道方法调用列表只能调用第一个65536方法引用。 为解决这个问题，我们提供了许多解决方案。其中一个是多索引，我们通过使用android的支持库将.dex文件拆分为多个类[classes.dex，classes1.dex ...]。
我无法理解的是，由于这种多重索引，Android应用程序有什么缺点，为什么我们应该花费大量精力来减少引用方法的数量。
基本上在我的理解中，为了减少方法计数，我必须减少模块化，这使得我的代码可读性降低，从而消除了在删除第三方库代码时消耗的小时数。减少方法计数值得吗？
答案 0 :(得分：22)
您正在考虑使用multidex，而应通过分析应用程序来观察并确定您的应用是否存在任何性能问题。
多索引几乎不会增加任何代码大小，主要尺寸和性能问题与动画/图像/音频/视频资源有关，它们会增加尺寸并降低性能。
包括许多第三方库最终将通过64k限制，而今天几乎所有应用程序都是多索引的，用户今天需要多功能应用程序，这需要与许多第三方库集成。
只有在你进行速度最重要的动画/游戏编程时，更多的方法调用可能是有害的，但这与多索引无关，即使写得不好的小型非多索引应用程序也会在任何设备上表现不佳。 / p>
启动时间会影响多索引，但通过更改应用程序逻辑来延迟加载其他昂贵的库和资源，肯定可以改善它。
减少方法计数值得 ??
否
理想情况下，您应该使用更多方法并模块化您的代码，因为测试和更改移动应用程序是一个巨大的挑战。调试和删除错误比multidex大小及其对性能的影响更昂贵。由于屏幕较小，品牌不同，用户界面不同，用户对手机上的应用程序比计算机更加生气。如果将代码分成多个单独的测试库，那么跟上用户需求将变得更加容易。
答案 1 :(得分：5)
主要缺点是dex / apk尺寸较大。 Dex文件具有在该dex文件中的所有类之间共享的常量池。当类跨多个dex文件分割时，这些共享常量必须在它们所使用的每个dex文件中重复。
答案 2 :(得分：2)
通常说来，multidex的缺点是：APK大小增加，应用程序启动可能较慢以及内存占用增加。
这样做的原因是某些数据（例如StringData）无法共享，因此需要同时部分存储在多个DEX文件中。 StringData由从代码加载的字符串文字以及类，方法和字段名称组成，通常占DEX文件总数的20％。
但是（除了APK大小以外）的实际缺点在很大程度上取决于您运行该应用程序的Android版本。
Google优化了Android运行时（ART），以消除这些缺陷。 Android O（API 26）引入了VDEX容器来存储预先验证的DEX文件。 Google借助Android P进一步优化了预编译器（代号CompactDex），并将共享数据段添加到VDEX容器中，以对多个DEX文件中使用的数据进行重复数据删除。因此，在Android P运行时上运行multidex应用程序时几乎没有缺点。
答案 3 :(得分：1)
Multidexing本身是一个非执行术语，如果应用程序是multidex，则意味着执行应用程序的android内部进程有负担。
每个Android应用程序都在一个进程（任务）内部运行，当它的多索引时，它意味着该进程被分成几个部分，这些部分会在小型android处理器中产生性能问题，无论你如何编写代码。
我同意aakash kava，几乎所有的应用程序都是多索引的，因为现在有一天Android处理器的性能非常好，并且Android内存非常出色，但它并不意味着我们应该忽略多索引。