Gradle 构建时间过长 [英] Gradle Build too long
问题描述
在启用 MultiDex 后，Gradle 构建现在花费的时间太长(实际上它在运行 1 小时后还没有完成构建).我遵循了 https://developer.android.com/studio/build/multidex.html 站点以在应用程序中配置 MultiDex.
Gradle build now takes too long (literally it does not complete building after running for like 1 hour) after enabling MultiDex. I followed the steps given at https://developer.android.com/studio/build/multidex.html site to configure MultiDex in app.
以下是我的 gradle 控制台的摘录.
Below is an excerpt from my gradle console.
: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 控制台停止的地方.任何帮助，将不胜感激.我还需要在 pre-lollipop 设备中测试该应用程序.
the last task :app:transformClassesWithDexForDevelopmentDebug is the one where the gradle console stops. Any help would be appreciated. I also need to test the app in pre-lollipop devices.
编辑
仅当我在棒棒糖预测试设备中测试我的应用时才会出现此问题.主要测试设备的构建似乎工作正常.为 Nexus 6P 构建需要 8.12 秒.但我也想测试棒棒糖之前的设备.
The problem only occurs when I test my app in a pre-lollipop test device. Building for main test device seems to work fine. It takes 8.12 seconds while building for Nexus 6P. But I want to test for pre-lollipop devices too.
编辑 2
根据@Gillis 的建议，我附上了我的堆栈跟踪
As per @Gillis's advice I am attaching my stacktrace
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 文件夹，但仍然没有运气.很明显，在获取锁的过程中存在一个循环.
I have tried removing my /home/.gradle folder too but still no luck. Clearly there is a loop in acquiring the lock.
我也附上了我的 jstacktrace
Also I am attaching my jstacktrace too
"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)
请参阅这个 pastebin 以获取完整日志.
please refer this pastebin for complete log.
推荐答案
非常感谢您的帮助.我解决了这个问题.显然问题是因为(我想是)JaCoCo 与我的班级 dexing 一起进行 dexing 并发出锁.我通过删除应用程序 build.gradle 中的 testCoverageEnabled=true 行来解决此问题.
Thanks for your much appreciated help. I solved this issue. Apparently the issue was because (I suppose that) the JaCoCo was dexing along with my class dexing and was issuing a locks. I fixed this by removing the testCoverageEnabled=true line in my app's build.gradle.
如果你们中的任何人遇到类似的问题.创建两个构建风格(prod 和 development)并添加行 testCoverageEnable=true 仅用于开发风格并将其设置为 false 其他地方.还要确保您的开发将 minSdkVersion 设置为 21 (Lollipop)，因为 ART 已完成 dexing，基本上您不会遇到此问题.
In case any of you guys run into similar issue. Create two build flavours (prod and development) and add the line testCoverageEnable=true only for development flavor and set it to false else where. Also ensure that your development has the minSdkVersion set to 21 (Lollipop) as the dexing is done for ART and basically you won't be running into this issue.
这篇关于Gradle 构建时间过长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
