使用Gradle（Android Studio）进行超长构建

现在，对于非常简单的更改，我们的构建时间为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的构建时间，所以我不确定那里出了什么问题。1:30比蚂蚁还疯狂。如果您知道AndroidStudio正在做什么（或者忽略，或者重写为gradle配置），我将非常感谢您知道

因此，在更改后，只需CMD+B（简单编译）就可以实现超快的速度，比如7秒。 但在运行应用程序时，它会启动任务dexxxdebug，这简直要了我们的命。 我试过把

没用

我知道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

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

android

块：

dexOptions {
    incremental true
}

在该

dexOptions

块中，还可以指定dex进程的堆大小，例如：

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

---

这些选项取自adt dev邮件列表（）上的一个线程，该线程有更多的上下文。

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

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

 dexOptions {
    jumboMode = true
//  incremental true
}

在我们的build.gradle项目中：

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

 dexOptions {
    jumboMode = true
//  incremental true
}

以前我们有一个增量真的。在评论之后，它需要大约20秒的时间来运行，而不是2分钟30秒。

---

我不知道这能解决你的问题。但它可以帮助其他人。：）

“--offline”解决了我的问题。

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

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

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

第一个是，有很多相关的东西，仍然是开放的，仍然有很多人抱怨2.2.1版不可用。我喜欢那个注意到这个问题的人（一个高优先级的人），包括“666”不是巧合。大多数人描述音乐程序和鼠标移动在构建过程中口吃的方式感觉就像在镜子里看一样

您应该注意到，人们报告Windows进程套索的性能很好，而我发现在*nix变体中，没有人报告renice'ing或cpu限制的性能很好

（谁说他不使用gradle）实际上在Ask Ubuntu中展示了一些非常好的东西，不幸的是，在我的情况下，这些东西不起作用

这限制了gradle执行的线程，但在我的场景中，这并没有真正改善，可能是因为有人在另一个链接上说studio生成多个gradle实例（而参数只影响一个实例的并行性）

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

就个人而言，我无法测试许多解决方案，因为我在一台托管（无根privs）Ubuntu机器上工作，无法获得/renice，但我可以告诉你，我有一个i7-4770、8GB RAM和一个混合SSD，即使经过多年的大量内存和渐变调整后，我也有这个问题。这是一个诱人的问题，我无法理解谷歌为何没有为gradle项目投入必要的人力资源，以修复他们构建的最重要平台开发的核心问题

---

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

当你从IDE进行Cmd-B构建时，它并没有完全构建到APK——这就是为什么在运行时它会慢得多的原因，因为它在生成一个完整的APK，它在执行dex，这可能需要很长时间。看看adt dev邮件列表上的这个帖子，它讨论了构建时间，收集了这里讨论的信息，并补充了您的问题，看看我们是否可以对它有更多的了解。我知道它只是编译源代码，而没有构建dex。但是Ant是如何在不到20秒的时间内完成这项任务的，而我在这里需要大约2.5分钟？这是一个好问题，但如果你能收集更多的信息，我就不必做那么多错误的猜测；）添加到问题中的有关时间的信息。这有帮助吗？我发现Eclipse ADT更快。我知道AA有很酷的特性，但速度不如Eclipse。@JuanMendez我也很快接受Eclipse