web-dev-qa-db-fra.com

La construction d'un studio Android a ralenti après l'ajout de nouvelles bibliothèques?

Mon application utilise d'anciens composants d'architecture. Je veux passer à de nouveaux composants d'architecture Android .

À cette fin, j'ai ajouté des dépendances liées à la pièce au début, après quoi la construction était normale.

Mais quand j'ai essayé d'ajouter des dépendances pour Lyfecycles, LiveData et ViewModel, comme mentionné ici .

Le processus de création d’applications a été considérablement ralenti, 5 min et plus de temps pour compiler apk.

Les dépendances suivantes ajoutées dans build.gradle de l'application:

    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"

De plus, je dois activer Jack pour la compatibilité avec Java 8, comme suit:

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

Après avoir ajouté tous ces composants, le processus de construction s’est considérablement ralenti. J'ai essayé d'apporter des modifications personnalisées à l'option VM de certains paramètres en allant à Help -> Edit custom VM options

-Xmx5120m

Je l'ai réglé à près de 5 Go, mais rien n'a fonctionné pour moi. Ma machine a assez de matériel, je crois. (8 Go de RAM, Windows 10, disque dur de 1 To, AMD A8)

Mon application utilise de nombreux services Google, tels que l'API Gmail, les API Firebase, et certaines autres bibliothèques, ai-je épuisé la limite de référence de 64 Ko? Mais j'ai déjà activé le multidexing comme mentionné ici .

Cela est-il dû à de nouveaux composants d'architecture ou à autre chose? Comment rendre le processus de construction plus rapide?

Mise à jour:

Une des réponses ci-dessous par Budius a suggéré un script qui montrera les temps pris par chaque processus de construction, je l’ai exécuté dans mon application, voici les résultats:

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

La plupart des timings sont pris par Jack.

J'ai essayé la version canary suggérée dans la réponse ci-dessous par Bryan suivante est la sortie du timing pris pour le processus de construction:

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

Donc j'ai enlevé jack et suis passé à cette version canary, la construction est plus rapide que la précédente, mais toujours lente à utiliser.

androidgradleandroid-gradleandroid-build
16
pcj

Jack Toolchain est obsolète et était toujours dans une phase expérimentale avant sa dépréciation. Bien que le processus de génération de code puisse être lent (comme le mentionne @ FlorescuGeorgeCătălin), cela ne signifie pas généralement , ce qui cause des temps de construction excessivement lents. Je soupçonne que la lenteur de votre construction est due à la chaîne d'outils Jack; comme itestnotoirementlent .

Si vous souhaitez utiliser les fonctionnalités du langage Java 8, je vous suggère de passer à la version canary d’Android Studio 3.0 qui les intègre intégrée .

Si ce n'est pas une option, vous pouvez utiliser Retrolambda , qui inclut la plupart des mêmes fonctionnalités du langage Java 8.

6
Bryan

Votre question repose en grande partie sur des hypothèses selon lesquelles ceci ou cela pourrait être, il y a des "lots". Mais le temps est quelque chose de très facile à mesurer, et gradle divise le processus de construction en plusieurs tâches plus petites. Je suppose donc que votre meilleure action consiste à mesurer chaque tâche et à comparer ce qui prend si longtemps.

Voici un script que j'ai créé pour mesurer les temps de construction , ajoutez-le simplement dans le dossier racine de votre projet et dans votre fichier de niveau supérieur, ajoutez 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()
7
Budius

La bibliothèque ayant un processeur d'annotation, il doit générer un nouveau code dans les classes générées. Dagger est également une bibliothèque qui génère du code. Butterknife le même.

Vous pouvez les trouver dans le dossier de projet app/build/generated.

Vous pouvez en savoir plus sur le processeur d'annotation ici .

Peut aussi être de votre disque dur. Un SSD pourrait vous donner beaucoup plus de puissance de traitement.

2
Florescu Cătălin

Avez-vous défini Gradle sur Offline Work et essayé de Edit custom VM options pour augmenter la taille du segment de mémoire?

Une autre solution est de mettre à niveau Android Studio vers Android Studio 3.0 , ce qui augmente également la vitesse de génération. 

1
nhoxbypass

Ajoutez les éléments suivants dans build.gradle inside Android {}

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

Définissez les éléments suivants dans le fichier 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
1
AnupamChugh

Fichier -> Paramètres -> (Côté gauche) Construction, Exécution, Développement -> Outils de construction -> Gradle 

Sous les "Paramètres globaux", une case à cocher nommée "Travail hors ligne" apparaîtra. Vérifie ça.

L'AS-tu fait?

1
Efe AYDIN

C'est un long coup, mais y a-t-il un vrai appareil Android connecté à votre machine de test? En fait, je remarque que mon AS fonctionne très lentement si mes périphériques de test sont connectés. Peut-être que l'adb rencontre des problèmes et que cela ralentit le système.

Sinon, j'ai mis à niveau mon ancien ordinateur vers un processeur RAM 16 Go de 16 Go et les choses ont commencé à fonctionner beaucoup plus rapidement.

0
Bqin1