我已经阅读了很长时间的代码性能和调整参数。实际上，Android程序是我的重点之一。
首先让我们介绍一些基本或最重要的概念，这些概念可以帮助我们找到解决方案。
正如Android开发人员所说
该模块可以独立构建，测试和调试
因此，模块具有自己的Gradle和依赖项。您可以在project中进行探索Hierarchy Viewer。
实际上，模块化注重维护。不同于性能问题。因此，模块化具有以下重要影响：
这是我为清楚起见绘制的图表。如您所见，在使用离散模块时，为了调用方法A，将其2N micro secs与N micro secs没有离散模块的情况进行了比较。
我想到这个问题，即引用方法对继承深度有何影响？
答案是：尽管使用模块化会增加“引用方法”，但实际上并不会影响应用程序性能，主要的问题是继承深度，在大多数情况下，继承深度是可忽略的。
我确实强调，模块化中引用方法的增加归因于每个模块的Gradle和依赖项
应用程序模块化如何才能大幅提高引用方法的数量？
影响APK分析器的重要条件参考方法
还要注意，在编译源代码之后，压缩和代码收缩也可以极大地改变DEX文件的内容。
除了上述官方声明外，我还要添加另一个影响APK分析器的条件：
开发人员在模块化方面有多少经验？
模块化就像是一个家，建筑（开发人员）定义了哪里应该是厨房，哪里应该是洗手间，哪里应该是卫生间。
如果架构决定将WC和Kitchen结合起来怎么办？是的，这是一场灾难。
如果开发人员经验不足，则可能在模块化时发生这种情况。
除其他信息外，回答OP问题
在这里，我回答评论中的操作性问题
为什么将单独的Gradle添加到引用的方法计数中？对于单独的依赖关系，如果最终结果是单个APK，那么我认为'app'和功能模块中的重复依赖关系不会增加引用的方法计数。
因为模块可以被构建，测试和调试，所以它们必须具有自己的Gradle＆Dependencies。
在编译多模块项目时，编译器会生成几个.dex文件，包括：
依赖.dex文件是所有模块等级的集成
让我们看一下模块gradle如何影响最终的Reference Mothods Count ？！
有2 APK s的结果相同，但“引用方法”计数不同。
它们都是空的活动，它们1.7k在“引用方法计数”中的差异很大，这取决于它们的功能。他们的主要区别在于模块的Gradle，其中之一配置为
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}
另一个配置为
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-beta4'
}
尽管它们只是空的活动，但是Gradle的最小差异会导致1.7k引用方法计数的差异。
而App Gradle是
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation project(path: ':module')
}
主要关注的是为什么在Apk Analyzer中添加的单独引用的方法计数与总引用的方法计数不同？
这只是IDE过滤器。可以肯定的是，如果您仅选择一个.dex文件，则“引用方法计数”等于每行“引用方法计数”的SUM，但是如果您选择多个.dex文件，您将看到SUM和实际计数的差异，这是因为Analyzer首选的“引用”相等过滤它们。
在屏幕截图中，您选择了多个.dex文件，然后选择了分析器过滤器相等性。
在我们的项目中，我们使用集中化的dependencies.gradle文件，因此不会有使用不同版本的机会。因此，您是否认为即使我们在功能模块中具有相同/完全相同的依赖关系集及其版本，也会增加引用方法的数量吗？
理论上它应该不增加引用的方法计数。但是，正如我所解释的那样，开发人员体验会严重影响最终结果。
Team Analyzer应该在发布之前检查并修复性能问题，例如
- 保护规则
- 缩小和缩小资源
- androidManifest.xml
- gradle设置
现在，我想澄清一下开发人员体验和代码维护如何影响最终结果。即使您的APK使用集中式依存关系
在上面的示例中，即使我具有集中式依赖性，我的5.1k引用方法计数也增加了！
怎么可能？
答案是：我只是.jar在libs项目目录中添加了一个无用的隐藏文件。就像您看到的那样，我影响了最终结果。
如您所见，开发人员体验会影响最终结果。结果，实际上它可能是引用的方法计数虽然增加理论上是否应NOT。
当我通过禁用并行编译仅编译“ app”模块时，为什么引用的方法数量没有区别？它应该减少了，因为只使用了“ app”模块的依赖关系，对吗？
编译与引用的方法计数没有任何关系。它符合开发人员要编译的内容。
结论
我已经介绍了有关该问题的所有可能性。确实，它可以在不同情况下出现，并且开发人员可以使用此指南来解决此问题。
- 我希望您能找到为什么增加了引用方法以及为什么在某些情况下可能会大大增加引用方法的原因。
- 模块具有其Gradle＆Dependencies和模块化增加模块。因此，这些方法参考。
- 模块化实际上会影响应用程序的性能，但是可以使您的应用程序维护更好。
- 开发人员在模块化方面的经验也会极大地影响最终结果。
重要提示：几乎所有陈述都是我的调查和研究。实际上，可能存在错误和错误，并且会进行更新以在将来添加更多信息。
