现在我们正处于构建时间为2分30秒的情况下进行非常简单的更改。这（与ANT相比）速度惊人，并且正在削弱整个团队的生产力。我正在使用Android Studio并使用“使用本地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 =真
org.gradle.daemon =真
它并没有真正帮助。
我把上述参数放在〜/ .gradle / gradle.properties中（我甚至怀疑Android工作室是否忽略了这一点，所以我测试了 - 它并没有忽略它）。
仍然从终端我在Android Studio中获得1:30构建时间与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
我不太确定为什么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）上的一个帖子，该列表有更多的上下文。
我们的团队面临同样的问题。我们的项目超出了dex的方法限制（> 65k）。因此，在库项目中，我们将以下选项放在build.gradle中：
dexOptions {
jumboMode = true
preDexLibraries = false
}
在我们的项目build.gradle中：
dexOptions {
jumboMode = true
// incremental true
}
以前我们有增量真实。在评论之后它需要大约20秒运行，相比之下2分30秒。我不知道这可能会解决你的问题。但它可以帮助别人。 :)
免责声明：这不是一个解决方案 - 它是一个声明，没有相关链接源的解决方案来证明它。
由于这里的所有答案都没有解决自2014年以来一直存在的问题，我将继续发布一些链接，这些链接描述了一个非常类似的问题，并提出了可能会或可能没有帮助的特定于操作系统的调整，因为OP做了似乎没有指定它，并且解决方案在它们之间变化很大。
首先是actual AOSP bug-tracker issue referring to parallelization，有很多相关的东西，仍然开放，仍然有很多人抱怨2.2.1版本。我喜欢那个注意到这个问题的人（那是一个很高级的人），包括“666”并不是巧合。大多数人在构建过程中描述音乐程序和鼠标移动口吃的方式感觉就像在盯着镜子......
您应该注意人们使用Windows的流程套索报告好东西，而我看到没有任何报告在* nix变体中使用renice'ing或cpu-limiting有任何好处。
This guy（谁声称他不使用gradle）实际上在Ask Ubuntu中提供了一些非常好的东西，遗憾的是在我的情况下不起作用。
Here is another alternative限制了gradle执行的线程，但在我的场景中并没有真正改进，这可能是因为有人在关于工作室产生多个gradle实例的另一个链接上说了什么（而参数只影响一个实例的并行性）。
请注意，这一切都可以追溯到原来的“666”，高优先级问题......
我个人无法测试许多解决方案，因为我在一个托管（无root privs）Ubuntu机器上工作，不能apt-get / renice，但我可以告诉你我有一个i7-4770,8GB RAM和一个混合SSD，即使经过多年的大量内存和gradle调整，我也遇到了这个问题。这是一个令人着迷的问题，我无法理解谷歌如何没有为gradle项目提供必要的人力资源来修复他们构建的最重要平台的开发核心。
关于我的环境需要注意的一件事是：我在一个多依赖工作室项目中工作，有大约10个子项目，所有这些项目都是自己构建并填满了gradle管道。
传递一个值时，可以附加字母'k'表示千字节，'m'表示兆字节，或'g'表示千兆字节。
'--offline'解决了我的问题。