关于android:AGP正确使用dependsOn

6次阅读

共计 2218 个字符，预计需要花费 6 分钟才能阅读完成。

简而言之，Gradle 通过计算工作依赖关系图来工作。假如您要构建一个 JAR 文件：您要调用 jar 工作，而 Gradle 将确定构建 jar，它须要编译类、解决资源等……确定工作依赖项，也就是说还须要执行哪些其余工作，是通过查看 3 个不同的货色来实现的：

 工作取决于依赖项。例如，assemble.dependsOn(jar) 示意如果运行 assemble，那么 jar 工作必须先执行

工作传递依赖关系，在这种状况下，咱们不是在议论工作，而是在议论“出版物”。例如，当你须要编译我的项目 A 时，你须要在 classpath 我的项目 B 上，这意味着运行 B 的一些工作。最初但并非最不重要的是，工作输出，也就是说，它须要什么来执行它的工作

看看上面的代码：[图片上传失败 …(image-afd61c-1648820700726)]

用与其余构建工具（如 Maven 或 Ant）雷同的形式思考是很迷人的，尤其是当您不习惯 Gradle 时。你在想“有一个工作，jar，它基本上将它在 classes/groovy/main 中找到的所有内容打包，所以如果我想在 jar 工作中增加更多内容，让咱们在 classes/groovy/main 中增加更多内容”.

因为不同的起因，这是谬误的，最显著的是：

当 docsFilesJar 工作将被执行时，它会向“classes”目录奉献更多文件，然而，等等，那些不是咱们放在那里的类，对吧？它只是一个罐子，资源。咱们不应该改用 resources/groovy/main 吗？或者是 classes/groovy/resources？要不然是啥？好吧，你不应该关怀，因为你不关怀 Java 编译工作将其输入放在哪里！

它毁坏了可缓存性：Gradle 有一个构建缓存，多个工作奉献于同一个输入目录是毁坏缓存的典型示例。事实上，它突破了各种最新的查看，也就是说，Gradle 可能了解它不须要在没有任何变动的状况下执行工作。

它对 Gradle 是不通明的：下面的代码在 doLast 块中执行一个正本。没有什么能通知 Gradle“类”有额定的输入。

设想另一个只须要类的工作。依据它执行的工夫，它可能蕴含也可能不蕴含它不关怀的 docsFileJar。这使得构建不可重现（请留神，这正是 Maven 构建不可信并且您须要运行洁净的起因，因为任何“指标”能够随时写入任何目录，因而无奈推断谁奉献了什么）。

它须要申明 jar 工作和 docsFileJar 工作之间的显式依赖关系，以确保如果咱们执行 jar，咱们的“docs jar”文件存在

它没有阐明为什么会有依赖关系：是因为你想订购货色，还是因为你须要依赖工作产生的工件？还有什么？

很容易遗记这些：因为您可能常常运行构建，您可能认为您的构建工作，因为 jar 是工作图的一部分，并且偶尔地，docsFileJar 会在之前执行

它会产生意外的额定工作：大多数状况下，dependsOn 会触发过多的工作。Gradle 是一个智能构建工具，它能够准确计算每个特定工作须要执行的内容。通过应用 dependsOn，你有点像应用锤子并强制它在图中整合一些不必要的货色。简而言之：你做的工作太多了。

很难解脱它们：当您看到 dependsOn 时，因为它没有阐明为什么须要它，因而在优化构建时通常很难解脱这种依赖关系

咱们的问题的答案实际上更容易推理：颠倒逻辑。与其想“我应该把这些货色放在哪里，以便被 jar 拾取”，不如想想“让咱们通知 jar 工作它也须要拾取我的资源”。

总而言之，这是对于正确申明您的工作输出。

与其修补另一个工作的输入（说真的，遗记这个！），每个工作都必须被认为是一个承受输出并产生输入的函数：它是隔离的。那么，咱们的 docsFileJar 的输出是什么？咱们要打包的资源。它的输入是什么？罐子自身。没有对于咱们应该把罐子放在哪里的问题，咱们让 Gradle 为咱们抉择了一个正当的中央。

那么 jar 工作自身的输出是什么？好吧，这是惯例输出加上咱们的 jar。它更容易推理，而且作为处分，它甚至更短！

因而，让咱们将下面的代码重写为：

您看得出来差异吗？咱们解脱了 docFilesJar 工作中的正本，咱们不想这样做。相同，咱们想要的是说“当你构建 jar 时，还要抉择这个 docsFileJar。这就是咱们通过 docsFileJar 通知咱们正在做的事件。Gradle 足够聪慧，晓得它什么时候须要执行 jar 工作，首先，它须要构建 docsFilesJar。

这样做有几个长处：