ruta - ¿La construcción de Android Studio se ralentizó después de agregar nuevas bibliotecas?

error sdk android studio

Question

Mi aplicación utiliza componentes de arquitectura antiguos. Quiero pasar a los nuevos componentes de la arquitectura de Android .

Para este propósito, agregué dependencias relacionadas con la habitación al principio, después de que la construcción fuera normal.

Pero cuando intenté agregar dependencias para Lyfecycles, LiveData y ViewModel, como se menciona here .

El proceso de construcción de la aplicación se ralentizó considerablemente, se requieren 5 minutos y más tiempo para crear el apk.

Siguientes dependencias agregadas en build.gradle de la aplicación:

 compile "android.arch.lifecycle:runtime:1.0.0-alpha5"
compile "android.arch.lifecycle:extensions:1.0.0-alpha5"
annotationProcessor "android.arch.lifecycle:compiler:1.0.0-alpha5"

También tengo que habilitar jack para compatibilidad con Java 8, de la siguiente manera:

defaultConfig {
........
jackOptions {
enabled true
}
}

Después de agregar todos estos componentes, el proceso de construcción se ha reducido considerablemente. Intenté realizar algunos cambios personalizados en las opciones de VM para algunos parámetros yendo a Help -> Edit custom VM options

-Xmx5120m

Lo puse a casi 5 GB pero nada funcionó para mí. Mi máquina tiene suficiente hardware, creo. (8 GB de RAM, Windows 10, HDD de 1TB, AMD A8)

Mi aplicación hace uso de muchos servicios de Google, como la API de Gmail, las API de Firebase, algunas otras bibliotecas ¿agoté el límite de referencia de 64K? Pero ya he habilitado el multidexing como se menciona here .

¿Esto sucedió debido a los nuevos componentes de la arquitectura o algo más? ¿Cómo hago el proceso de construcción más rápido?

Actualización:

Una de las respuestas a continuación de Budius sugirió que un script que muestre los tiempos tomados por cada proceso de construcción, lo ejecuté en mi aplicación, aquí están los resultados:

BUILD SUCCESSFUL
Total time: 18 mins 28.44 secs
Task timings:
480ms :app:mergeDebugResources
2516ms :app:processDebugResources
487725ms :app:transformClassesWithPreJackPackagedLibrariesForDebug
29213ms :app:transformClassesWithPreJackRuntimeLibrariesForDebug
752ms :app:transformResourcesWithMergeJavaResForDebug
556894ms :app:transformJackWithJackForDebug
5184ms :app:transformNativeLibsWithMergeJniLibsForDebug
17524ms :app:packageDebug

Jack toma la mayoría de los tiempos.

Probé la versión canaria que se sugiere en la siguiente respuesta de Bryan continuación se muestra el tiempo tomado para el proceso de construcción:

BUILD SUCCESSFUL in 6m 11s
42 actionable tasks: 33 executed, 9 up-to-date
Task timings:
608ms :app:preDebugBuild
350ms :app:mergeDebugResources
394ms :app:processDebugManifest
2543ms :app:processDebugResources
9410ms :app:javaPreCompileDebug
46585ms :app:compileDebugJavaWithJavac
262ms :app:compileDebugShaders
395ms :app:mergeDebugAssets
5835ms :app:packageInstantRunResourcesDebug
98922ms :app:transformClassesWithDesugarForDebug
334ms :app:transformClassesWithExtractJarsForDebug
7765ms :app:transformClassesWithInstantRunVerifierForDebug
23117ms :app:transformNativeLibsWithMergeJniLibsForDebug
10128ms :app:transformResourcesWithMergeJavaResForDebug
16565ms :app:transformClassesWithInstantRunForDebug
11825ms :app:transformClassesWithInstantRunSlicerForDebug
84703ms :app:transformClassesWithDexBuilderForDebug
17061ms :app:transformDexArchiveWithDexMergerForDebug
1706ms :app:transformDexWithInstantRunDependenciesApkForDebug
9770ms :app:transformDexWithInstantRunSlicesApkForDebug
10571ms :app:packageDebug
1387ms :app:buildInfoGeneratorDebug

Así que quité el jack y cambié a esta versión canaria, la compilación es más rápida que la anterior pero es lenta para su uso.

Answer 1

¿Configuró Gradle en Offline Work e intentó Edit custom VM options para un tamaño de pila mayor?

Otra solución es actualizar Android Studio a Android Studio 3.0, que también aumenta la velocidad de compilación

Answer 2

Agrega lo siguiente en el build.gradle dentro de Android {}

dexOptions {
incremental true
javaMaxHeapSize "4g"
}

Establezca lo siguiente en el archivo gradle.properties:

org.gradle.parallel=true
org.gradle.daemon=true
org.gradle.configureondemand=true
org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
android.enableBuildCache=true
org.gradle.caching=true

Answer 3

Archivo -> Configuración -> (lado izquierdo) Compilación, Ejecución, Desarrollo -> Herramientas de compilación -> Gradle

Bajo la "Configuración global de Gradle" habrá una casilla de verificación llamada "Trabajo sin conexión". Revisalo.

¿Lo has hecho?

Answer 4

Como la biblioteca tiene un procesador de anotaciones, debe generar un nuevo código en las clases generadas. Dagger es también una biblioteca que genera código. Butterknife lo mismo.

Puedes encontrarlos en la app/build/generated carpeta de proyecto.

Puede consultar más sobre el procesador de anotaciones here .

También puede ser de su disco duro. Un SSD podría darle mucho más poder de procesamiento.

Answer 5

El Jack Toolchain está en deprecated , y aún estaba en una fase experimental antes de su desaprobación. Aunque el proceso de generación de código puede ser lento (como lo mencionó @ FlorescuGeorgeCătălin), generalmente no causa tiempos de construcción excesivamente lentos. Sospecho que la causa de tus tiempos de construcción lentos es el Jack Toolchain; ya it is notoriously slow .

Si desea funciones de lenguaje Java 8, le sugiero que se mude a la versión canaria de Android Studio 3.0 que las tiene built-in .

Si esa no es una opción, podría usar Retrolambda en Retrolambda lugar, que incluye la mayoría de las mismas funciones de lenguaje de Java 8.

Answer 6

Esta es una posibilidad remota, pero ¿hay un dispositivo Android real conectado a su máquina de prueba? En realidad, me doy cuenta de que mi AS se ejecuta muy lentamente si tengo mis dispositivos de prueba conectados, tal vez el ADB tenga problemas y eso ralentice el sistema.

Alternativamente, actualicé a un procesador ram i7 de 16 gb desde mi máquina anterior y las cosas comenzaron a ejecutarse mucho más rápido.

Answer 7

Mucho de su pregunta se basa en suposiciones de que esto o aquello podría ser, que hay "lotes". Pero el tiempo es algo muy fácil de medir, y gradle divide el proceso de construcción en varias tareas más pequeñas. Entonces, supongo que tu mejor acción es medir cada tarea y entonces puedes comparar lo que está tomando tanto tiempo.

Aquí hay un script que hice para medir los tiempos de compilación , solo agréguelo a la carpeta raíz de su proyecto y en su archivo de nivel superior, agregue apply from: ''time.gradle''

timer.gradle

import java.util.concurrent.TimeUnit
class TimingsListener implements TaskExecutionListener, BuildListener {
private long startTime
private timings = []
@Override
void beforeExecute(Task task) {
startTime = System.nanoTime()
}
@Override
void afterExecute(Task task, TaskState taskState) {
def ms = TimeUnit.MILLISECONDS.convert(System.nanoTime() - startTime, TimeUnit.NANOSECONDS);
timings.add([ms, task.path])
}
@Override
void buildFinished(BuildResult result) {
println "Task timings:"
for (timing in timings) {
if (timing[0] >= 250) {
printf "%7sms %s/n", timing
}
}
}
@Override
void buildStarted(Gradle gradle) {}
@Override
void projectsEvaluated(Gradle gradle) {}
@Override
void projectsLoaded(Gradle gradle) {}
@Override
void settingsEvaluated(Settings settings) {}
}
gradle.addListener new TimingsListener()