configurar - Construcción extremadamente larga con Gradle(Android Studio)

update gradle android studio

Question

ahora mismo estamos en una situación de tener tiempos de construcción de 2 minutos y 30 segundos para un cambio muy simple. Esto (en comparación con ANT) es increíblemente lento y está matando la productividad de todo el equipo. Estoy usando Android Studio y uso de "Usar distribución gradle local". Intenté darle más memoria a gradle:

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

Mucho más memoria. Y SIGUE DANDO ERRORES PARA LA MEMORIA de vez en cuando.

Excepción en el hilo "pool-1-thread-1" java.lang.OutOfMemoryError: límite superior de GC excedido

Asombroso. Estoy usando la opción paralela y daemon:

org.gradle.parallel = true

org.gradle.daemon = true

Realmente no ayuda.

Puse los parámetros mencionados en ~ / .gradle / gradle.properties (e incluso dudé de que el estudio de Android ignore eso, así que probé, no lo ignoraba).

Aún desde la terminal obtengo un tiempo de construcción de 1:30 vs 2:30 en Android Studio, así que no estoy seguro de lo que está mal allí. 1:30 es TODAVIA LOCA en comparación con Ant. Si sabe lo que está haciendo Android Studio (o ignorando, o reescribiendo como configuración de gradle), le agradecería que lo supiera.

Entonces, solo CMD + B (compilación simple) es súper rápido después de los cambios, como 7 segundos. Pero cuando se trata de ejecutar la aplicación, inicia la tarea dexXxxDebug, que simplemente nos está matando. He intentado poner

dexOptions {
preDexLibraries = false
}

No ayuda.

Entiendo que es posible que Gradle aún no esté listo para entornos de producción, pero estoy empezando a arrepentirnos de nuestra decisión de avanzar tan pronto. Tenemos muchos módulos, que probablemente sean parte del problema, pero eso no fue un problema con Ant.

Cualquier ayuda apreciada, Dan

Algo más de información sobre los tiempos de ejecución:

Descripción Duración

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

The time eater:: aplicación: dexDebug 1m16.46s

Answer 1

''--offline'' resolvió mi problema.

Answer 2

Al pasar un valor, puede agregar la letra ''k'' para indicar kilobytes, ''m'' para indicar megabytes, o ''g'' para indicar gigabytes.

Answer 3

No estoy muy seguro de por qué Android Studio es más lento que la línea de comandos, pero puedes acelerar tus compilaciones activando el dexing incremental. En el archivo de compilación de tu módulo, agrega esta opción a tu bloque de android :

dexOptions {
incremental true
}

En ese bloque dexOptions también puede especificar el tamaño del montón para el proceso dex, por ejemplo:

dexOptions {
incremental true
javaMaxHeapSize "4g"
}

Estas opciones están tomadas de un hilo en la lista de distribución de adt-dev ( groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ ) que tiene un poco más de contexto.

Answer 4

Nuestro equipo enfrentaba el mismo problema. Nuestro proyecto excede el límite del método para dex (> 65k). Entonces, en nuestro proyecto de biblioteca, colocamos las siguientes opciones en build.gradle:

dexOptions {
jumboMode = true
preDexLibraries = false
}

En nuestro proyecto build.gradle:

 dexOptions {
jumboMode = true
// incremental true
}

anteriormente teníamos incremental verdadero. después de comentarlo tarda alrededor de 20 segundos en ejecutarse en comparación con 2 minutos y 30 segundos. No sé, esto puede resolver su problema. pero puede ayudar a otros. :)

Answer 5

Para los usuarios de Linux esto ayuda: sudo renice -n 20 -p <pid of gradle daemon>

Puede encontrar el pid usando el comando: pgrep -la java Y busque ".gradle / daemon", elija pid.

Answer 6

Descargo de responsabilidad: esta no es una solución, es una declaración de que no existe una solución con fuentes de enlace relevantes para probarlo .

Dado que todas las respuestas aquí no resuelven un problema que ha estado persistiendo desde 2014, voy a seguir adelante y publicar un par de enlaces que describen un problema muy similar y presentar ajustes específicos del sistema operativo que podrían o no ayudar, ya que OP hizo parece que no lo especifica, y las soluciones varían mucho entre ellos.

Primero está el problema real del rastreador de errores de AOSP que se refiere a la paralelización , con muchas cosas relevantes, todavía abierto y aún con mucha gente quejándose de la versión 2.2.1. Me gusta el tipo que nota el problema (una gran prioridad en eso) identificación incluyendo "666" no es una coincidencia. La forma en que la mayoría de la gente describe los programas de música y el tartamudeo del movimiento del mouse durante las compilaciones parece como mirar en un espejo ...

Debe tener en cuenta que las personas informan sobre cosas buenas con lazo de proceso para Windows, mientras que no veo nada que informe realmente nada bueno con renice''ing o cpu-limit en variantes de * nix.

Este tipo (que dice que no usa gradle) realmente presenta algunas cosas muy agradables en Ask Ubuntu, que desafortunadamente no funciona en mi caso.

Aquí hay otra alternativa que limita los hilos de la ejecución de gradle, pero que realmente no mejoró en mi escenario probablemente debido a lo que alguien dice en otro enlace sobre el estudio que genera múltiples instancias gradle (mientras que el parámetro solo afecta el paralelismo de una instancia).

Tenga en cuenta que todo esto se remonta al "666" original, problema de alta prioridad ...

Personalmente no pude probar muchas de las soluciones porque trabajo en una máquina Ubuntu administrada (sin privs de raíz) y no puedo usar get / renice, pero puedo decir que tengo una i7-4770, 8GB de RAM y un híbrido. SSD, y tengo este problema incluso después de muchos ajustes de memoria y gradle a lo largo de los años . Es un tema tentador, y no puedo entender cómo Google no ha comprometido los recursos humanos necesarios para el proyecto Gradle para arreglar algo que está en el centro del desarrollo de la plataforma más importante que construyen.

Una cosa a tener en cuenta en mi entorno es: trabajo en un proyecto de estudio de varias dependencias, con alrededor de 10 subproyectos, todos ellos construyendo por sí mismos y llenando la tubería de Gradle.