Compilação extremamente longa com Gradle (Android Studio)

Question

no momento, estamos em uma situação em que o tempo de construção é de 2 minutos e 30 segundos para alterações muito simples.Isso (comparado ao ANT) é incrivelmente lento e está acabando com a produtividade de toda a equipe.Estou usando o Android Studio e usando a opção "Usar distribuição gradle local".Tentei dar mais memória ao gradle:

org.gradle.jvmargs=-Xmx6096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Muito mais memória.E AINDA ESTÁ DANDO ERROS DE MEMÓRIA de vez em quando.

Exceção no encadeamento "pool-1-thread-1" java.lang.OutOfMemoryError:Limite de sobrecarga do GC excedido

Incrível.Estou usando a opção paralela e o daemon:

org.gradle.parallel=true

org.gradle.daemon=true

Isso realmente não ajuda.

Coloquei os parâmetros mencionados acima em ~/.gradle/gradle.properties (e até duvidei que o Android Studio estivesse ignorando isso, então testei - não está ignorando).

Ainda no terminal, recebo 1:30 de tempo de construção versus 2:30 no Android Studio, então não tenho certeza do que há de errado aí.1:30 AINDA é LOUCO comparado ao Ant.Se você sabe o que o Android Studio está fazendo (ou ignorando ou reescrevendo como configuração gradle), ficaria grato em saber.

Então apenas CMD + B (compilação simples) é super rápido após as alterações, tipo 7 segundos.Mas quando se trata de executar o aplicativo, ele inicia a tarefa dexXxxDebug, que está nos matando.Eu tentei colocar

dexOptions {
    preDexLibraries = false
}

Não ajuda.

Entendo que o gradle provavelmente ainda não está pronto para ambientes de produção, mas estou começando a me arrepender de nossa decisão de migrar para ele tão cedo.Temos muitos módulos, o que provavelmente é parte do problema, mas isso não foi um problema com o Ant.

Qualquer ajuda apreciada, Dan

Mais algumas informações sobre tempos de execução:

Descrição Duração

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

O comedor de tempo::app:dexDebug 1m16.46s

Answer 1

Não sei bem por que o Android Studio é mais lento que a linha de comando, mas você pode acelerar suas compilações ativando a dexação incremental.No arquivo de construção do seu módulo, adicione esta opção ao seu android bloquear:

dexOptions {
    incremental true
}

Naquilo dexOptions block você também pode especificar o tamanho do heap para o processo dex, por exemplo:

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

Essas opções são retiradas de um tópico na lista de discussão adt-dev (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ) que tem um pouco mais de contexto.

Answer 2

Nossa equipe estava enfrentando o mesmo problema.Nosso projeto excede o limite do método para dex(>65k).Então, em nosso projeto de biblioteca colocamos abaixo as opções em build.gradle:

dexOptions {
    jumboMode = true
    preDexLibraries = false
}

Em nosso projeto build.gradle:

 dexOptions {
    jumboMode = true
//  incremental true
}

anteriormente tínhamos incremental true.depois de comentar, leva cerca de 20 segundos para ser executado, em comparação com 2 minutos e 30 segundos.Não sei se isso pode resolver seu problema.mas pode ajudar outras pessoas.:)

Answer 3

Isenção de responsabilidade:Isto não é uma solução - é uma afirmação de que não há solução com fontes de links relevantes para provar isso.

Como todas as respostas aqui não resolvem um problema que persiste desde 2014, irei em frente e postarei alguns links que descrevem um problema muito semelhante e apresentam ajustes específicos do sistema operacional que podem ou não ajudar, já que o OP fez não parecem especificá-lo, e as soluções variam muito entre eles.

Primeiro é o problema real do rastreador de bugs do AOSP referente à paralelização, com muita coisa relevante, ainda aberto e ainda com muita gente reclamando por estar fora da versão 2.2.1.Eu gosto do cara que nota o problema (de alta prioridade), incluindo "666", não sendo uma coincidência.A maneira como a maioria das pessoas descreve os programas de música e os movimentos do mouse travados durante as compilações é como olhar no espelho...

Você deve observar que as pessoas relatam coisas boas com o laço de processo para Windows, embora eu não veja ninguém realmente relatando algo de bom com renice'ing ou limitação de CPU nas variantes * nix.

Esse cara (que afirma não usar gradle) na verdade apresenta algumas coisas muito legais no Ask Ubuntu, que infelizmente não funcionam no meu caso.

Aqui está outra alternativa isso limita os threads de execução do gradle, mas isso realmente não melhorou no meu cenário, provavelmente devido ao que alguém disse em outro link sobre o estúdio gerar várias instâncias do gradle (enquanto o parâmetro afeta apenas o paralelismo de uma instância).

Observe que tudo isso remonta ao "666" original, problema de alta prioridade...

Pessoalmente, não pude testar muitas das soluções porque trabalho em uma máquina Ubuntu gerenciada (sem root privs) e não consigo apt-get/renice, mas posso dizer que tenho um i7-4770, 8 GB de RAM e um híbrido SSD, e tenho esse problema mesmo depois de muita memória e ajustes gradle ao longo dos anos.É uma questão tentadora e não consigo entender como o Google não comprometeu os recursos humanos necessários no projeto Gradle para consertar algo que está no centro do desenvolvimento da plataforma mais importante que eles constroem.

Uma coisa a observar no meu ambiente é:Eu trabalho em um projeto de estúdio multidependência, com cerca de 10 subprojetos, todos construídos por conta própria e preenchendo o pipeline do Gradle.

Answer 4

Ao passar um valor, você pode acrescentar a letra 'k' para indicar kilobytes, 'm' para indicar megabytes ou 'g' para indicar gigabytes.

Answer 5

'--offline' resolveu meu problema.