Gradle 构建时间过长答案

【问题标题】：Gradle Build too longGradle 构建时间过长
【发布时间】：2016-10-04 10:28:50
【问题描述】：

在启用 MultiDex 后，Gradle 构建现在需要很长时间（实际上它在运行大约 1 小时后无法完成构建）。我按照https://developer.android.com/studio/build/multidex.html 站点给出的步骤在应用程序中配置 MultiDex。

以下是我的 gradle 控制台的摘录。

:app:compileDevelopmentDebugNdk UP-TO-DATE
:app:compileDevelopmentDebugSources
:app:mergeDevelopmentDebugShaders UP-TO-DATE
:app:compileDevelopmentDebugShaders UP-TO-DATE
:app:generateDevelopmentDebugAssets UP-TO-DATE
:app:mergeDevelopmentDebugAssets UP-TO-DATE
:app:unzipJacocoAgent UP-TO-DATE
:app:transformClassesWithJacocoForDevelopmentDebug UP-TO-DATE
:app:transformClassesWithDexForDevelopmentDebug

最后一个任务:app:transformClassesWithDexForDevelopmentDebug 是 gradle 控制台停止的那个。任何帮助，将不胜感激。我还需要在棒棒糖之前的设备中测试该应用程序。

编辑

仅当我在棒棒糖前测试设备中测试我的应用程序时才会出现此问题。为主要测试设备构建似乎工作正常。为 Nexus 6P 构建需要 8.12 秒。但我也想测试棒棒糖之前的设备。

编辑 2

根据@Gillis 的建议，我附上了我的堆栈跟踪

10:19:10.558 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
10:19:10.558 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:10.559 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
10:19:20.555 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
10:19:20.560 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:20.560 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
10:19:20.561 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.

我也尝试过删除我的/home/.gradle 文件夹，但仍然没有成功。显然在获取锁的过程中有一个循环。

我也附上了我的 jstacktrace

"File lock request listener" #27 prio=5 os_prio=31 tid=0x00007fb9b2c20800 nid=0x5d07 runnable [0x0000700001961000]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainDatagramSocketImpl.receive0(Native Method)
        - locked <0x00000006c026d670> (a java.net.PlainDatagramSocketImpl)
        at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
        - locked <0x00000006c026d670> (a java.net.PlainDatagramSocketImpl)
        at java.net.DatagramSocket.receive(DatagramSocket.java:812)
        - locked <0x00000006c0bc5df0> (a java.net.DatagramPacket)
        - locked <0x00000006c026d630> (a java.net.DatagramSocket)
        at org.gradle.cache.internal.FileLockCommunicator.receive(FileLockCommunicator.java:60)
        at org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler$1.doRun(DefaultFileLockContentionHandler.java:67)
        at org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler$1.run(DefaultFileLockContentionHandler.java:54)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
        at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

完整的日志请参考this pastebin。

【问题讨论】：

对于像编译时间太长这样的问题，答案很简单......购买更好的PC/Mac
iMac（27 英寸，2012 年末）3.2 GHz Intel Core i5，8 GB 1600 MHz DDR3，NVIDIA GeForce GTX 675MX 1024 MB
正如@Selvin 所说，如果您的电脑配置较低，那么通常需要花费时间，但我认为即使在我的双核中完成构建也需要花费数小时，它在 1 或 2 内完成分钟
@androidXP 我明确表示我尝试使用 MultiDex，因为我之前遇到过 dex 溢出错误，方法数量超过 65k。我使用了大量的库。
信不信由你，问题在于您的互联网连接检查设置中的离线工作->Buildtools->Gradle 并重试。

标签： android android-studio gradle android-build

【解决方案1】：

非常感谢您的帮助。我解决了这个问题。显然问题是因为（我想）JaCoCo 正在与我的班级 dexing 一起进行 dexing 并发出锁。我通过删除应用程序 build.gradle 中的 testCoverageEnabled=true 行来解决此问题。

如果你们中的任何人遇到类似的问题。创建两个构建风格（产品和开发）并添加行 testCoverageEnable=true 仅用于开发风格并将其设置为 false 其他地方。还要确保您的开发将minSdkVersion 设置为 21（棒棒糖），因为 dexing 是针对 ART 完成的，基本上您不会遇到这个问题。

【讨论】：

但是如果你去掉“testCoverageEnable”，你就不能得到测试覆盖率报告，对吧？
创建多种口味并为棒棒糖后版本启用 testCoverage。
这个解决方案拯救了我的一天
非常感谢，我为解决这个问题苦苦挣扎了几天。虽然有时原因可能不同，但如果 gradle 文件中有此行，我建议先检查此选项。
虽然构建问题消失了，但无法获得覆盖率报告。 minSdkVersion 21 不工作。产品风味也无法识别“testCoverageEnabled”这个词。

【解决方案2】：

除了其他答案中给出的所有 gradle 调整之外，您还可以不时地做一些事情，比如结束 gradle 进程。根据我的经验，这样做并开始一个新的构建解决了这个问题。

【讨论】：

【解决方案3】：

转到控制台中的应用文件夹并运行：

./gradlew build --debug

这可以为您提供大量信息，说明哪里出了问题。通常当 gradle 挂起时，它是由无法检索的外部依赖引起的。

您可以尝试在 android studio 中启用离线模式，看看这是否真的是问题所在。

【讨论】：

嘿，谢谢您的建议。我也附上了我的调试日志和堆栈跟踪。获取唤醒锁似乎有一个循环。

【解决方案4】：

试试这个

    android {
        compileSdkVersion 24
        buildToolsVersion "24.0.0"

        dexOptions {
            javaMaxHeapSize "4g"
        }
        ....
    }

【讨论】：

试过了，没有运气。
org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m 这是我的 gradle 属性
如果这些都不适合您，请尝试全新安装 android studio。

【解决方案5】：

首先确保你的 gradle 也是最新的 Android Studio试一试。

【讨论】：

我也试过了。我正在使用 gradle 版本 3.1 和 buildTools 版本 2.2 我也尝试过启用离线工作
我的互联网速度一般，如果不是很快的话。所以我的构建通常不会超过 12 秒。（通过构建我的意思是同步）。我的网速是 200Mbps，我认为这足以快速下载所有依赖项。但为了安全起见，我也尝试过开启离线模式。

【解决方案6】：

提高 Gradle 任务执行性能的几个技巧：

Gradle 守护进程如果你告诉 Gradle 使用守护进程来构建，你可以减少 Gradle 的启动时间（在我的电脑上减少到两秒）：

org.gradle.daemon=true

并行项目执行如果您正在构建具有许多子模块依赖项的非常复杂的项目，这确实会产生重大影响：

org.gradle.parallel=true

全局 gradle.properties

在我们的主目录中的属性文件中定义的属性优先于在我们的项目目录中的文件中定义的属性。这背后的原因是您希望避免在构建服务器上使用 Gradle 守护程序，因为启动时间不如内存消耗重要：

/Users/~/.gradle/gradle.properties

like this

【讨论】：

【解决方案7】：

您可以在程序末尾使用exit(0); 命令，它应该退出此循环

【讨论】：