Ma machine Windows 7 a un processeur i7 quad core. Lorsque je reconstruis mon projet, cela prend en moyenne 25 secondes. Et lorsque je lance l'application, cela prend en moyenne 36 secondes (avant que l'application ne soit téléchargée sur l'appareil).
J'ai 588 fichiers dans le dossier/src de mon projet, qui comprend tout mon code Java et XML. J'ai deux libs .so chacun 5Mo et 7 jars dans mon dossier/libs.
Voir ma capture d'écran ci-jointe. Comme vous pouvez le constater, mon processeur atteint son maximum à 100% tout le temps. Ma musique iTunes s'interrompt et un message contextuel "Performance médiocre" s'affiche dans le coin inférieur droit de la barre des tâches de Windows. C'est à quel point c'est mauvais.
J'utilise Android Studio 1.2.1.1
La plupart du temps est consacré aux opérations preDex et dex.
Voici ce que j'ai essayé jusqu'à présent (séparément, je ne les ai pas tous essayés ensemble):
Rien n'a encore fonctionné. Je ne peux pas imaginer que c'est un problème commun, ai-je raison? Suis-je trop incapable, parce que c'est vraiment beaucoup plus lent qu'Eclipse?
Je suppose que mes questions sont:
Je suis vraiment à la recherche de pailles, donc si quelqu'un a des informations, et plus particulièrement pourquoi l'opération Dex prend autant de temps processeur, ce serait génial.
Je suppose qu'il va sans dire que cela se produit si je modifie un fichier XML, effectue une reconstruction, puis lance l'application. S'il n'y a rien à nettoyer et à reconstruire ... Quand je fais juste un projet Make ... le temps de construction moyen est de 3 secondes.
Voici les trois améliorations que j'ai pu apporter:
Je pré-examinais mes fichiers JAR chaque fois que je construisais le projet. J'ai donc trouvé cette solution:
dexOptions {
preDexLibraries = false
}
J'utilisais toute la bibliothèque de services Google Play:
compile('com.google.Android.gms:play-services:+') {
exclude module: 'support-v4'
}
Quand tout ce dont j'avais besoin était Google Cloud Messenger:
compile('com.google.Android.gms:play-services-gcm:+') {
exclude module: 'support-v4'
}
Dans Eclipse, je ferais toujours une reconstruction, puis lancerais une application avec le bouton de lecture. Dans Android Studio, je suis en train de faire un nettoyage, puis de lancer une application avec le bouton de lecture. De plus, le bouton Exécuter dans Android Studio NE fonctionne PAS à chaque fois juste après le nettoyage. Cela causait ce qui semblait être des retards car rien ne se passait. Alors maintenant, je laisse la console Gradle ouverte pour m'assurer que le bouton Exécuter fonctionne et si ce n'est pas le cas, je le frappe une seconde fois.
Ce que j'avais l'habitude d'avoir:
Rebuild: 26 seconds
Launch: 36 seconds
Install: 15 seconds
et maintenant:
Clean: 8 seconds
Launch: 22 seconds
Install: 15 seconds
ce qui est une amélioration majeure! Espérons que cela aide quelqu'un d'autre.
Comme indiqué sur la page tracker pour ce problème , l'équipe a identifié ceci comme étant le problème:
--parallel-threads ne s'applique qu'à la parallélisation de projet.
Pour les tâches Android exécutées en parallèle, nous créons toujours en tant que autant de fils que possible
De la page, il semble qu'ils ciblent la version 1.3 pour résoudre ce problème (voir le commentaire n ° 13 ici).
Entre-temps, ce qui m’a aidé à faire face à Windows 7, c’était de définir l’affinité CPU pour le processus Android Studio (et ses processus enfants) afin d’épargner au moins un des cœurs (comme suggéré par le commentaire n ° 9 sur la page).
Il existe plusieurs façons de procéder, mais vous pouvez essayer la réponse votée par le plus fort nombre sur cette question de superutilisateur (qui suggère d'utiliser Process Lasso ), qui semble fonctionner assez bien pour moi.
Outre les optimisations spécifiques à Gradle (voir ci-dessous), je vous recommande d'essayer de désactiver l'antivirus protection pour votre répertoire de caches Gradle et votre répertoire de projet Android Studio. Pour moi, cela réduit mes temps de construction d'environ 50%. Exclure ces mêmes répertoires de l'indexation Windows Search peut également aider.
Les optimisations Gradle que j'utilise, dans ~/.gradle/gradle.properties.
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx6144m <-- Tweak this based on available RAM
org.gradle.caching=true
org.gradle.parallel=true
kotlin.incremental=true
Notez que l'activation de la mise en cache signifie que vous devez parfois effacer explicitement vos caches lors du changement de branche. Je lance ce script lorsque je rencontre des problèmes de construction énigmatiques.
#!/bin/bash
# Clean Android cache
./gradlew cleanBuildCache
# Clean Gradle cache, prompting for each directory
find ~/.gradle/caches -maxdepth 1 -name build-cache* -print -exec rm -rfI {} \;
# Clean Project
./gradlew clean
# Stop Gradle Daemon
./gradlew --stop