android - 应用模块化后引用的方法数量增加

Question

AS:3.5.3； Android Gradle 插件:3.5.0； Gradle :5.6.2；

在将“app”模块拆分为几个小模块后，我们观察到在我们的应用程序中引用的方法数量急剧增加。但奇怪的是，每个类所引用的方法的增加量都少于Android Apk Analyzer Tool中提到的总数。

出于测试目的，我已将 WebActivity.class 从“app”模块移动到“适配器”模块，并且引用的方法计数增加了 181 个方法。

总结:

应用程序/WebActivity = 63546 实际引用的方法但显示 65394 方法。
适配器/WebActivity = 63543 实际引用的方法但显示 65575 方法。

我们有 添加/拆分 4 个新模块后，观察到“引用方法计数”增加了近 10k。

确切的问题是什么？

应用程序模块化如何将引用的方法数量大幅增加到如此之高？

以下是我对两个不同 APK 截取的屏幕截图，唯一的区别是 WebActivity 从“app”模块移动到“适配器”模块，并增加了 181 个引用方法:

'app' 模块中的 WebActivity


将 WebActivity 移至“适配器”模块


在截图中，为什么每个类(用红色标记)添加的引用方法与 Apk Analyzer 中给出的总数不相等？

Answer 1

我一直在阅读有关代码性能和调优参数的文章。确实，Android 程序是我的重点之一。

让我们首先介绍帮助我们找到解决方案的基本或最重要的概念。

如 Android Developer有说明

module can be independently built, tested, and debugged

因此，模块有自己的 Gradle 和依赖项 .你可以在项目Hierarchy Viewer中探索它.

事实上，模块化强调维护问题。与性能问题不同。因为，模块化具有以下重要影响:

增加继承深度

这是我绘制的图表以使其清楚。如您所见。在使用离散模块时，为了调用方法 A，有 2N micro secs与 N micro secs 相比没有分立模块。



我想到了这个问题，引用方法计算与继承深度相关的内容？

答案是:虽然使用模块化增加了引用方法。但是，它实际上并不影响应用程序的性能，主要可能的问题是继承深度，大多数情况下是 可忽略 .

我强调模块化中增加的引用方法是由于每个模块 Gradle 和依赖项

How app modularization can increase the referenced method count drastically so high?

影响APK分析器重要引用方法的条件

Also note that minification and code shrinking can each also considerably change the contents of a DEX file after source code is compiled.

除了上述官方声明之外，我想添加另一个影响APK分析器的条件，即:

开发人员在模块化方面有多少经验？

模块化就像一个家架构(开发人员)定义哪里应该是厨房，哪里应该是休息室，哪里应该是卫生间。
如果架构决定将卫生间和厨房结合起来怎么办？是的，这是一场灾难。

如果开发人员没有太多经验，则在模块化时可能会发生这种情况。

回答 OP 问题以及额外信息

在这里，我在评论中回答 op 提出的问题

Why would separate Gradle add to the referenced method count? And for separate dependency, if the final result is single APK then I do not think duplicate dependencies in 'app' and feature module would add to referenced method count.

因为模块可以被构建、测试和调试，所以它们必须有自己的 Gradle 和依赖关系。

在编译多模块项目时，编译器生成多个 .dex文件包括:

.dex总集成依赖项的文件

模块 .dex s

依赖项 .dex文件是 的整合所有模块gradle

让我们看看模块 gradle 如何影响最终的引用方法计数？!

有 2 APK s 具有相同的结果，但引用方法计数不同。




它们都是具有 1.7k 的空 Activity 非常高的引用方法计数差异取决于它们的功能。
他们的主要区别在于他们的 模块的 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'
}

虽然它们只是空的 Activity ，但在 Gradle 中引起的最小差异 1.7k引用方法计数的差异。

和 应用 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')
}

major concern is why addition of individually referenced method count is different than total referenced method count in Apk Analyzer?

这只是 IDE 过滤器而已。当然，如果您只选择 .dex文件引用方法计数等于每行引用方法计数的总和，但如果您多选 .dex files ，您将看到 SUM 和实际计数的差异，因为分析器首选过滤它们的引用中的相等性。

在您的屏幕截图中，您选择了多个 .dex文件然后分析器过滤器相等。

in our project we are using centralized dependencies.gradle file so there is not chance of different version. So, do you think even if we have same/exact set of dependencies and their versions in feature modules, it will increase referenced method count?

理论上应该不是 增加引用的方法计数。 但是 ，正如我所解释的，开发者体验 高度影响最终结果。

团队分析器 应该在发布之前检查并修复性能问题，例如

proguard 规则

收缩和缩小的资源

androidManifest.xml

gradle 设置

现在我想澄清它是如何开发者体验 并且代码维护会影响最终结果。 即使 您的 APK 使用 集中依赖



在上面的例子中，我增加了 5.1k在引用方法计数中 即使我有 集中依赖 !!!!!!

怎么可能？

答案是:我刚刚添加了一个无用且隐藏的 .jar文件在 libs项目目录。正如您所看到的那样简单，我影响了最终结果。

如您所见 开发者体验 影响最终结果。因此，实际 尽管 引用的方法计数可能会增加理论上应不是 .

And why there is no difference in referenced method count when I compile only 'app' module by disabling parallel compilation? It should have decreased as only 'app' module's dependencies would have been used, right?

编译与引用的方法计数没有任何关系。它符合开发人员想要编译的内容。

结论

我已经涵盖了围绕这个问题的所有可能性。事实上，它可以从不同的情况出现，开发人员可以通过使用此指南来解决问题。

我希望你能找到引用方法增加的原因，并且
为什么在某些情况下它可能会急剧增加。

模块有自己的 Gradle & Dependencies 和模块化增加
模块。因此，这些方法引用。

模块化实际上对应用程序性能的影响可以忽略，但会使
您的应用程序维护更好。

开发人员在模块化方面的经验也极大地影响了最终
结果。

重要提示:几乎所有的陈述都是我的调查和研究。实际上，可能存在错误和故障，并将进行更新，以便将来添加更多信息。