使用 Gradle (Android Studio) 构建极长的时间答案

【问题标题】：Extremely long build with Gradle (Android Studio)使用 Gradle (Android Studio) 构建极长的时间
【发布时间】：2014-07-28 23:43:54
【问题描述】：

现在我们处于构建时间为 2 分 30 秒的情况，非常简单的更改。这（与 ANT 相比）速度非常慢，正在扼杀整个团队的生产力。我正在使用 Android Studio 并使用“使用本地 gradle 分发”。我试图给 gradle 更多的内存：

org.gradle.jvmargs=-Xmx6096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

更多的内存。而且它仍然不时地给内存带来错误。

线程“pool-1-thread-1”java.lang.OutOfMemoryError 中的异常：超出 GC 开销限制

太棒了。我正在使用并行选项和守护进程：

org.gradle.parallel=true

org.gradle.daemon=true

这并没有真正的帮助。

我已经将上述参数放在 ~/.gradle/gradle.properties 中（我什至怀疑 Android Studio 是否忽略了它，所以我测试了它 - 它没有忽略它）。

仍然从终端我得到 1:30 的构建时间和 2:30 在 Android Studio 中，所以不确定那里有什么问题。与 Ant 相比，1:30 仍然很疯狂。如果您知道 Android Studio 在做什么（或忽略或重写为 gradle 配置），我将不胜感激。

所以只需 CMD + B（简单编译）在更改后超级快，比如 7 秒。但是在运行应用程序时，它会启动任务 dexXxxDebug，这简直是在扼杀我们。我试过把

dexOptions {
    preDexLibraries = false
}

没用。

我知道 gradle 可能还没有为生产环境做好准备，但我开始后悔我们决定这么早迁移到它。我们有很多模块，这可能是问题的一部分，但这不是 Ant 的问题。

任何帮助表示赞赏，丹

更多关于执行时间的信息：

描述持续时间

Total Build Time    1m36.57s
Startup 0.544s
Settings and BuildSrc   0.026s
Loading Projects    0.027s
Configuring Projects    0.889s
Task Execution  1m36.70s

时间吞噬者： :app:dexDebug 1m16.46s

【问题讨论】：

当您从 IDE 进行 Cmd-B 构建时，它不会一直构建到 APK 的完整构建——这就是为什么当您运行时它会慢得多，因为那里它正在制作一个完整的 APK，并且正在制作 dex，这可能需要很长时间。在 adt-dev 邮件列表中查看此线程，该线程讨论构建时间 groups.google.com/forum/#!topic/adt-dev/a-zmpJ6yCuI 并收集在那里讨论的信息并扩充您的问题，看看我们是否可以进一步阐明它。
我知道它只是编译源代码，没有构建 dex。但是Ant怎么能在不到20秒的时间内完成这个任务，而我这里需要大约2.5分钟呢？
这是一个很好的问题，但如果你能收集到更多信息，我就不必做出这么多错误的猜测了 ;)
关于添加到问题的时间的信息。
这有帮助吗？ groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ

标签： gradle android-studio

【解决方案1】：

我不太清楚为什么 Android Studio 比命令行慢，但您可以通过打开增量 dexing 来加快构建速度。在模块的构建文件中，将此选项添加到您的 android 块中：

dexOptions {
    incremental true
}

在那个dexOptions块中你还可以指定dex进程的堆大小，例如：

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

这些选项取自 adt-dev 邮件列表 (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ) 上的一个线程，该线程有更多上下文。

【讨论】：

javaMaxHeapSize 在编译代码时帮助了我很多（将我的编译时间从 1 分钟以上减少到 19 秒），但之前没有尝试过增量选项 - 稍后会尝试。
谁能解释一下“4g”是什么意思
@sincerekamal 4g 在 4GB 内存中。文档在这里 - google.github.io/android-gradle-dsl/current/…
添加 'incremental true' 和 'javaMaxHeapSize "2g"' 为我解决了这个问题
警告：DSL 元素“DexOptions.incremental”已过时，将于 2018 年底删除。

【解决方案2】：

我们的团队也面临同样的问题。我们的项目超过了 dex(>65k) 的方法限制。因此，在 out library 项目中，我们在 build.gradle 中添加了以下选项：

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

在我们的项目build.gradle中：

 dexOptions {
    jumboMode = true
//  incremental true
}

以前我们有增量 true。在评论后它需要大约 20 秒才能运行，而 2 分 30 秒。我不知道这可以解决你的问题。但它可以帮助别人。 :)

【讨论】：

我发现 Eclipse ADT 更快。我知道 AA 有很酷的功能，但没有 Eclipse 快。
@JuanMendez 我也更快地接受 eclipse.. 但是 android studio 是官方的并且有很多功能.. 这就是我们留在这里的原因

【解决方案3】：

免责声明：这不是解决方案 - 它声明没有解决方案，相关链接来源可以证明这一点。

由于这里的所有答案都不能解决自 2014 年以来一直存在的问题，我将继续发布几个链接，这些链接描述了一个非常相似的问题，并展示了可能会或可能不会有帮助的特定于操作系统的调整，因为 OP 似乎没有指定它，并且解决方案在它们之间有很大差异。

首先是actual AOSP bug-tracker issue referring to parallelization，有很多相关的东西，仍然开放，仍然有很多人抱怨版本 2.2.1 关闭。我喜欢那个注意到这个问题的人（一个高优先级的那个）id，包括“666”，这不是巧合。大多数人在构建过程中描述音乐程序和鼠标移动口吃的方式感觉就像在照镜子......

您应该注意到人们报告了使用 Windows 进程套索的好东西，而我看到没有人真正报告任何在 *nix 变体中使用 renice'ing 或 cpu-limiting 的好东西。

This guy（他说他不使用 gradle）实际上在 Ask Ubuntu 中提供了一些非常好的东西，不幸的是在我的情况下不起作用。

Here is another alternative 限制了 gradle 执行的线程，但这在我的场景中并没有真正改善，这可能是因为有人在另一个链接上说关于工作室产生多个 gradle 实例（而参数只影响一个实例的并行性）。

请注意，这一切都可以追溯到最初的“666”，高优先级问题...

我个人无法测试许多解决方案，因为我在托管（无 root 权限）Ubuntu 机器上工作并且无法 apt-get/renice，但我可以告诉你我有一个 i7-4770、8GB 内存和混合 SSD，即使经过大量内存和 多年来的 gradle 调整，我也遇到了这个问题。这是一个诱人的问题，我无法理解 Google 为何没有为 gradle 项目提供必要的人力资源，以解决他们构建的最重要平台的开发核心问题。

在我的环境中需要注意的一点是：我在一个多依赖的工作室项目中工作，有大约 10 个子项目，所有这些子项目都是自己构建的，并填充了 gradle 管道。

【讨论】：

当然，所有这些都是主观的，因为很多人都在解决巨型模式和增量模式的问题，但这是他们的场景。需要注意的一点是，即使使用那些（在我的情况下），大多数构建第一次也需要很多时间，但之后的 2 或 3 次（7-30 秒构建）会更好，这主要是因为工作室 2 中的优化。 X。但我发现任何形式的 clean-sync-build-run 仍然会出现 2-10 分钟的高系统锁定率，这会占用我 10% 的工作日。

【解决方案4】：

传递值时，可以附加字母“k”表示千字节，“m”表示兆字节，或“g”表示千兆字节。

【讨论】：

【解决方案5】：

'--offline' 解决了我的问题。

【讨论】：