Gradle로 매우 긴 빌드 (Android Studio)

Gradle로 매우 긴 빌드 (Android Studio)

---

지금 우리는 매우 간단한 변경을 위해 빌드 시간이 2 분 30 초인 상황에 있습니다. 이것은 (ANT와 비교하여) 놀랍도록 느리고 전체 팀의 생산성을 저하시킵니다. Android Studio를 사용하고 "Use local gradle distribution"을 사용하고 있습니다. 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 스튜디오가이를 무시하고 있는지 의심했기 때문에 테스트했습니다. 무시하지 않습니다).

여전히 터미널에서 나는 Android Studio에서 1:30 빌드 시간과 2:30을 얻으므로 거기에 무엇이 잘못되었는지 확실하지 않습니다. 1:30은 Ant에 비해 여전히 미쳤습니다. 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가 명령 줄보다 느린 이유는 잘 모르겠지만 증분 덱싱을 켜면 빌드 속도를 높일 수 있습니다. 모듈의 빌드 파일에서 다음 옵션을 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
}

이전에 우리는 점진적으로 사실이었습니다. 댓글을 단 후 2 분 30 초에 비해 달리는 데 약 20 초가 걸립니다. 이것이 당신의 문제를 해결할 수 있을지 모르겠습니다. 그러나 그것은 다른 사람들에게 도움이 될 수 있습니다. :)

---

면책 조항 : 이것은 해결책이 아닙니다 . 증명할 관련 링크 소스가있는 해결책이 없다는 진술입니다 .

여기에있는 모든 답변은 2014 년 이후로 남아있는 문제를 해결하지 못하기 때문에 매우 유사한 문제를 설명하고 OP가 도움이 될 수도 있고 도움이되지 않을 수도있는 OS 별 조정을 제시하는 몇 개의 링크를 게시 할 것입니다. 그것을 지정하지 않는 것 같고 솔루션은 그들에 따라 많이 다릅니다.

첫 번째는 병렬화를 언급 하는 실제 AOSP 버그 추적기 문제 입니다. 관련 항목이 많지만 여전히 열려 있고 많은 사람들이 2.2.1 버전을 벗어났다고 불평합니다. 나는 우연이 아닌 "666"을 포함하여 이슈를 기록하는 사람 (그것에 대한 애국심이 높은 사람)을 좋아한다. 대부분의 사람들이 빌드하는 동안 음악 프로그램과 마우스 움직임이 끊기는 것을 묘사하는 방식은 마치 거울을 보는 것과 같은 느낌입니다.

You should note people report good stuff with process lasso for Windows, while I see none really reporting anything good with renice'ing or cpu-limiting in *nix variants.

This guy (who states he doesn't use gradle) actually presents some very nice stuff in Ask Ubuntu, that unfortunately doesn't work in my case.

Here is another alternative that limits threads of gradle execution, but that didn't really improve in my scenario probably due to what somebody says on another link about studio spawning multiple gradle instances (while the parameter only affects one instance's parallelism).

Note that this all goes back to the original "666", high-priority issue...

Personally I couldn't test many of the solutions because I work on a managed (no root privs) Ubuntu machine and can't apt-get/renice, but I can tell you I have an i7-4770, 8GB RAM and a hybrid SSD, and I have this problem even after a lot of memory and gradle tweaks over the years. It is a tantalizing issue, and I can't understand how Google hasn't committed the necessary human resources to the gradle project to fix something that is at the core of development for the most important platform they build.

One thing to note on my environment is: I work in a multi-dependency studio project, with about 10 subprojects, all of them building on their own and filling up the gradle pipeline.

---

When passing a value, you can append the letter 'k' to indicate kilobytes, 'm' to indicate megabytes, or 'g' to indicate gigabytes.

---

'--offline' solved my problem.

ReferenceURL : https://stackoverflow.com/questions/25006075/extremely-long-build-with-gradle-android-studio