使用Gradle（Android Studio）构建时间过长

Question

使用Gradle（Android Studio）构建时间过长

gradleandroid-studio

58

现在我们的情况是，即使进行非常简单的更改，构建时间也要2分30秒。与ANT相比，这个速度非常慢，正在影响整个团队的生产力。

我正在使用Android Studio并且使用“使用本地gradle分发”选项。

我尝试为gradle提供更多的内存：

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

提供了大量的内存，但有时仍然会出现内存错误：

Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: GC overhead limit exceeded

真是惊人。我正在使用并行选项和守护进程：

org.gradle.parallel=true

org.gradle.daemon=true

但这并没有真正帮助解决问题。

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

从终端运行构建时间只需要1分30秒，而在Android Studio中却需要2分30秒，所以不确定问题出在哪里。与Ant相比，1分30秒仍然非常慢。如果您知道Android Studio正在做什么（或忽略什么，或将其重写为gradle配置），我将不胜感激。

因此，仅进行简单的编译（CMD + B）后，构建速度非常快，只需要大约7秒钟。但是，在运行应用程序时，它会开始执行dexXxxDebug任务，这真的很消耗时间。我已经尝试过：

dexOptions {
    preDexLibraries = false
}
没有帮助。
我知道Gradle可能还没有准备好用于生产环境，但我开始后悔我们这么早地转向它的决定。我们有很多模块，这可能是问题的一部分，但在Ant中这不是问题。
非常感谢任何帮助，Dan
关于执行时间的更多信息：
描述时长
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

- Danail

2

我知道只是编译源代码，没有构建DEX。但Ant如何能够在不到20秒的时间内完成这个任务，而我需要大约2.5分钟呢？ - Danail

1

这是一个好问题，但如果您能收集更多信息，我就不必猜那么多了 ;) - Scott Barta

1

这个有帮助吗？https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ - Scott Barta

这非常有帮助。从2.5/1.5分钟缩短到37-40秒。谢谢！我想看看我们是否可以进一步优化。如果您将评论发布为答案，我会点赞（并在收集其他答案后可能接受它）。 - Danail

请参阅 https://dev59.com/mGQm5IYBdhLWcg3w0Bm5 -- 滚动查看最新的答案。 - Mr-IDE

显示剩余3条评论

5个回答

12

我们的团队也遇到了同样的问题。我们的项目超出了 dex 方法限制（>65k）。因此，在我们的库项目的 build.gradle 中，我们加入了以下选项：

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

在我们的项目 build.gradle 文件中：

 dexOptions {
    jumboMode = true
//  incremental true
}

之前我们使用了增量真值。在注释掉它后，运行时间从2分30秒缩短到了大约20秒。

我不确定这是否可以解决您的问题，但它可能会对其他人有所帮助。:)

- vikoo

1

我发现Eclipse ADT更快。我知道AA有很酷的功能，但不如Eclipse快。 - Juan Mendez

@JuanMendez 我也认为Eclipse更快.. 但是Android Studio是官方的，而且有很多功能.. 这就是我们留在这里的原因。 - Ranjithkumar

1

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

自从2014年以来一直存在的问题，所有的答案都没有解决，我要发表一些链接，描述一个非常相似的问题，并提供可能有所帮助的特定于操作系统的调整方法，因为OP似乎没有具体说明，而且解决方案在各个系统中差异很大。

首先是实际的AOSP错误跟踪问题引用了并行处理的问题，有很多相关内容，仍然保持着开放状态，许多人在版本2.2.1之后仍然抱怨。我喜欢那个指出该问题（一个高优先级问题）id包括“666”不是巧合的家伙。大多数人描述音乐程序和鼠标移动在构建过程中的卡顿感觉就像照镜子一样...

你应该注意到，Windows上的进程Lasso报告良好，而我看不到任何*nix变体中的renice或cpu限制报告任何好的东西。

这个人（声称他不使用gradle）在Ask Ubuntu上提供了一些非常好的东西，但不幸的是在我的情况下并不起作用。

这里有另一个替代方案，它限制了gradle执行的线程数，但在我的情况下并没有真正改善，可能是因为某个链接上有人说studio会生成多个gradle实例（而该参数只影响一个实例的并行性）。

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

就个人而言，我无法测试许多解决方案，因为我在托管的Ubuntu机器上工作，没有根权限，无法apt-get/renice，但我可以告诉你，我有一个i7-4770，8GB RAM和混合SSD，在多年的内存和gradle调整后，我仍然遇到这个问题。这是一个令人着迷的问题，我无法理解为什么Google没有投入必要的人力资源来修复这个对于他们构建的最重要平台的核心问题。

需要注意的一点是：我的工作环境是在一个多依赖的工作室项目中，有大约10个子项目，它们都在独立构建并填充gradle管道。

- leRobot

1

当然，所有这些都是主观的，因为很多人通过使用巨型模式和增量来解决问题，但那是他们的情况。需要注意的一件事是，大多数构建（在我的情况下）即使使用了这些方法，在第一次构建时也需要很长时间，但接下来的2-3次将会更好（7-30秒构建）。这主要是因为Studio 2.x中的优化。但我发现任何形式的“清洗-同步-构建-运行”仍然会出现相同的2-10分钟的系统卡顿率，这耗费了我工作日的10％。 - leRobot

0

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

- Manikandan K

-3

"

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

"

- Aziz Altun

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Scott Barta · Accepted Answer

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

android {
    ...
    dexOptions {
        incremental true
    }
}

dexOptions {
    incremental true
}

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

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

这些选项取自adt-dev邮件列表上的一个帖子（https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ），该帖子包含更多上下文信息。