Studio Android utilisant à tout moment> 100% du processeur - aucun processus d'arrière-plan ne semble en cours d'exécution

J'ai remarqué qu'Android Studio (lors de l'exécution) utilise plus de 100% du processeur à tout moment, même lorsqu'il semble qu'il n'y a pas de processus d'arrière-plan que l'EDI exécute (indexation, etc.). Je pourrais soupçonner que c'était quelque chose de spécifique à ma boîte, mais certains autres développeurs le rencontrent également.

Souvent, l'utilisation du processeur se situe dans les 100 ou les 200 moyens (voir les captures d'écran ci-dessous). Quelqu'un a-t-il également rencontré cela? Si tel est le cas, existe-t-il des stratégies ou des options au sein de l'EDI pour corriger cette utilisation intensive des ressources système?

Vous pouvez essayer les options suivantes dans le menu Fichier:

1. Menu Fichier -> Invalidate Caches / Restart ... -> Invalidate and Restart
2. Activez le mode d'économie d'énergie en cliquant sur Fichier -> Mode d'économie d'énergie

Le mode d' économie d' énergie ne désactive que les informations de code et les tâches en arrière-plan.

Merci à Buzzrick (répondu sur cette page, probablement au-dessus de ma réponse), il a évoqué VCS. La désactivation de toutes les opérations d'arrière-plan de VCS semblait avoir un impact ÉNORME sur l'utilisation élevée du processeur - c'était 150% et maintenant c'est 20%, plus ou moins.

Je suis sous OS X

Accédez à: Préférences> Contrôle de version> Arrière-plan. Maintenant répertorié sous «Opérations d'arrière-plan» sont 6 options. J'ai désactivé les trois premières options qui sont:

Effectuer une mise à jour sur VCS en arrière-plan, effectuer une validation sur VCS en arrière-plan, effectuer une extraction vers VCS en arrière-plan

Vous pourriez envisager d'aller dans Fichier> Invalider les caches / Redémarrer Votre cache peut lancer quelque chose de funky en arrière-plan

J'ai rencontré une utilisation constante et élevée du processeur sans raison apparente. L'invalidation du cache n'a pas fonctionné ni le mode d'économie d'énergie.

Dans mon cas, il y avait un problème dans le répertoire '.git' qui provoquait l'échec d'Android Studio dans une boucle sans fin. La vérification du repo a à nouveau résolu le problème.

Mon conseil est de vérifier les journaux du studio Android pour tout indice sur ce qui le fait échouer. Vous pouvez également le démarrer à partir du terminal et vérifier la sortie Stdout / Stderr.

J'ai activé l'économie d'énergie dans Android Studio 1.0, cela m'a aidé, mais cela signifie que j'ai désactivé tant de fonctionnalités qu'Android Studio a à offrir. Ainsi j'ai cherché à trouver une meilleure solution, il m'est arrivé d'avoir toujours une boîte de dialogue qui s'affiche et me demande d'augmenter la taille de ma VM. Apparemment, une fois que j'ai augmenté cela, je suis capable de désactiver l'économie d'énergie et de faire fonctionner parfaitement mon Android Studio.

Voici comment procéder: Sur Mac OS, allez dans /Applications/Android\ Studio.app/Contents/bin/studio.vmoptions(Pour ouvrir le contenu, faites un clic droit sur l'application Android Studio> Afficher le contenu) Vous trouverez les variables suivantes

-Xms128m
-Xmx4096m
-XX:MaxPermSize=1024m
-XX:ReservedCodeCacheSize=200m
-XX:+UseCompressedOops

Sous Windows, accédez aux variables d'environnement et recherchez une variable système appelée _JAVA_OPTIONS

Augmentez ces chiffres en conséquence.

• Xmx spécifie le pool d'allocation de mémoire maximal pour une machine virtuelle Java (JVM).
• Xms spécifie le pool d'allocation de mémoire initial.

c'est-à-dire que votre JVM démarrera avec une quantité de mémoire Xms et pourra utiliser une quantité maximale de Xmx de mémoire.

J'ai eu exactement le même problème sous Linux. Résolu en augmentant la taille de la mémoire.

Commencé par regarder le top -p <android studio pid> -Hqui montre quels threads utilisent le plus de CPU, il y a trois threads pour moi: 94232,94233,94234. Ensuite, je fais un jstack <pid>pour obtenir le vidage de la pile d'Android Studio et cherche 0x17018 (= 94232), il s'avère que c'est le cas "Gang worker#0 (Parallel CMD Threads)". Tous les trois. apparemment, JVM est trop occupé à faire du GC tout le temps.

J'ai également ouvert jconsole contre mon processus de studio Android et il montre l'heure GC " 20 minutes" !!! (en bas de l'onglet mémoire)

Le correctif consiste à changer les options studio.vm (ou studio64.vmoptions dans mon cas), pour augmenter la -Xmxvaleur par défaut de 750m à 1500m. Cela me suffit. si vous avez trop de mémoire, réglez sur 2g ou 4g ou 16g ..

Fait intéressant, pour moi, cela semblait être quelque chose à voir avec l'intégration du contrôle de version.

J'ai corrigé cela en rechargeant mon projet de studio Android et quand il m'a demandé de câbler mes liens CVS (je ne me souviens pas du libellé exact), j'ai juste dit "Ignorer". Après cela, il a fonctionné en douceur sans tirer le processeur

J'ai essayé la procédure suivante et Android Studioj'ai Surface Pro 3accéléré d'une quantité insensée:

1. Réduisez le amountet memoryle que Android Virtual Devicesvous avez.
2. Invalidate Caches/Restart
3. Aller au Power Savemode
4. Fermez tout unnecessary files that are opened.
5. Réduisez votre VM Heap Sizeà environ 256.

Sous Windows, j'ai réduit la priorité du processus studio64.exe et défini l'affinité du processus sur la moitié des cœurs. Ouvrez le Gestionnaire des tâches, cliquez sur l'onglet Processus, faites un clic droit sur processus studio64.exe et vous le verrez dans le menu.

J'ai laissé cette question ouverte pendant un certain temps, car les collègues et les affiches ici ont trouvé de la valeur dans diverses solutions au fil du temps. Pour moi, la simple mise à jour d'Android Studio a résolu le problème (après un certain nombre de mois où aucune des solutions présentées ici ne fonctionnait pour moi).

Sur Android Studio 2.3, cela se produit lorsque la fenêtre «Moniteur Android» est ouverte (la fenêtre affiche les messages Logcat des appareils et des émulateurs), puis que vous appuyez sur Ctrl+F( Cmd+Fsur le Mac) pour afficher la barre de recherche «Rechercher» dans cette fenêtre .

Cela peut également se produire lorsque vous connectez un téléphone Samsung à votre ordinateur via USB, qui a activé le mode développeur, car les téléphones Samsung envoient généralement de grandes quantités de texte de débogage à Logcat toutes les secondes, même si la fenêtre Logcat est fermée.

Ainsi, les solutions pour éviter l'utilisation à 100% du processeur sont:

Désactivez la barre de recherche Rechercher ou masquez complètement la fenêtre.

ou

Déconnectez un téléphone Samsung qui envoie de nombreux messages de débogage.

ou

Passez à Android Studio 3, où ce bogue ne se produit pas.

Dans mon cas, j'ai white-listedle dossier d'Android-Studio "Eset Smart Security"et le problème est résolu!

J'espère que cela t'aides!

Éditer:

La désactivation HIPSen Eset settingsa également été utile dans ma situation!