L’application peut faire trop de travail sur son thread principal

Je suis nouveau dans l’environnement SDK / API Android. C’est la première fois que j’essaie de dessiner un graphique. J’ai essayé de lancer différents types de code pour l’émulateur en utilisant 3 bibliothèques gratuites différentes, rien ne s’affiche dans l’écran de mise en page. Le logcat répète le message suivant:

  W / Trace (1378): Valeur inattendue de nativeGetEnabledTags: 0
  I / Chorégraphe (1378): A sauté 55 frames!  L'application peut faire trop de travail sur son thread principal. 

Le problème n’a pas persisté et le graphique a fonctionné lorsque j’ai exécuté un exemple de code relatif à une copie d’évaluation d’une bibliothèque sous licence.

tiré de: Android UI: Correction des images ignorées

Quiconque commence à développer une application Android voit ce message sur logcat «Chorégraphe (abc): ignoré xx images! L’application fait peut-être trop de travail sur son thread principal. » Alors, qu’est-ce que cela signifie réellement, pourquoi devriez-vous être concerné et comment le résoudre?

Cela signifie que votre code prend beaucoup de temps à être traité et que les frameworks sont ignorés à cause de cela, peut-être à cause d’un traitement intensif que vous effectuez au cœur de votre application ou de votre access à la firebase database. arrêtez-vous un moment. Voici une explication plus détaillée:

Chorégraphe permet aux applications de se connecter au vsync, et de chronométrer correctement les choses pour améliorer les performances.

Les animations de vues Android utilisent en interne Choreographer dans le même but: chronométrer correctement les animations et éventuellement améliorer les performances.

Puisque Choreographer est informé de tous les événements vsync, je peux savoir si l’un des Runnables transmis par Choreographer.post * apis ne se termine pas dans le temps imparti, ce qui entraîne l’ignorance des images.

D’après ce que je comprends, le chorégraphe ne peut détecter que le saut de trame. Il n’a aucun moyen de dire pourquoi cela se produit.

Le message “L’application peut faire trop de travail sur son thread principal” pourrait être trompeur.

source: Signification des messages de chorégraphe dans Logcat

Pourquoi vous devriez vous inquiéter

Lorsque ce message apparaît sur l’émulateur Android et que le nombre d’images ignorées est assez faible (<100), vous pouvez parier que votre émulateur est lent, ce qui arrive presque toujours. Mais si le nombre de cadres sautés et volumineux et de l'ordre de 300+ alors il peut y avoir de sérieux problèmes avec votre code. Les appareils Android sont fournis dans une vaste gamme de matériel, contrairement aux appareils iOS et Windows. La RAM et le processeur varient et si vous voulez une performance raisonnable et une expérience utilisateur sur tous les périphériques, vous devez corriger ce problème. Lorsque les images sont ignorées, l'interface utilisateur est lente et lente, ce qui n'est pas une expérience utilisateur souhaitable.

Comment le réparer

La résolution de ce problème nécessite l’identification des nœuds là où il existe ou peut se produire une longue durée de traitement. Le meilleur moyen est de faire tout le traitement, peu importe sa taille ou sa taille dans un thread séparé du thread principal de l’interface utilisateur. Accédez donc à la firebase database SQLite ou faites des calculs complexes ou sortingez simplement un tableau – Faites-le dans un autre thread

Maintenant, il y a un problème ici, vous allez créer un nouveau thread pour faire ces opérations et quand vous exécuterez votre application, il plantera en disant “Seul le thread d’origine qui a créé une hiérarchie de vues peut toucher ses vues”. Vous devez savoir que l’interface utilisateur dans Android peut être modifiée par le thread principal ou le thread d’interface utilisateur uniquement. Tout autre thread qui tente de le faire échoue et se bloque avec cette erreur. Ce que vous devez faire est de créer un nouveau Runnable dans runOnUiThread et à l’intérieur de cet exécutable, vous devez effectuer toutes les opérations impliquant l’UI. Trouvez un exemple ici .

Donc, nous avons Thread et Runnable pour traiter les données en dehors du thread principal, quoi d’autre? Il y a AsyncTask dans Android qui permet d’effectuer des processus de longue durée sur le thread d’interface utilisateur. C’est le plus utile lorsque vos applications sont pilotées par des données ou Web Api ou utilisent des interfaces utilisateur complexes comme celles créées à l’aide de Canvas. La puissance d’AsyncTask est qu’il permet de faire les choses en arrière-plan et qu’une fois le traitement terminé, vous pouvez simplement effectuer les actions requirejses sur l’interface utilisateur sans provoquer d’effet retardé. Ceci est possible parce que AsyncTask dérive du thread de l’interface utilisateur d’Activity – toutes les opérations que vous faites sur l’interface utilisateur via AsyncTask sont un thread différent du thread d’interface utilisateur principal, aucune entrave à l’interaction de l’utilisateur.

C’est donc ce que vous devez savoir pour créer des applications Android fluides et pour autant que je sache, chaque débutant reçoit ce message sur sa console.

Comme d’autres ont répondu ci-dessus, “Sauté 55 images!” signifie que certains traitements lourds sont dans votre application.

Pour mon cas, il n’y a pas de processus lourd dans ma demande. Je double et sortingple tout vérifié et supprimé ces processus, je pense que c’était un peu lourd.

J’ai enlevé Fragments, Activities, Libraries jusqu’à ce qu’il ne rest plus que le squelette. Mais le problème n’est toujours pas résolu. J’ai décidé de vérifier les ressources et j’ai trouvé que certaines icons et arrière-plans que j’utilise sont assez gros, car j’ai oublié de vérifier la taille de ces ressources.

Donc, ma suggestion est que si aucune des réponses ci-dessus ne vous aide, vous pouvez également vérifier la taille de vos fichiers de ressources.

Moi aussi j’ai eu le même problème.
Le mien était un cas où j’utilisais une image d’arrière-plan qui était sous forme de dessins. Cette image particulière était d’environ 130 Ko et était utilisée pendant l’écran d’accueil et la page d’accueil dans mon application Android.

Solution – J’ai juste déplacé cette image particulière dans le dossier drawables-xxx à partir de drawables et j’ai pu libérer beaucoup de mémoire occupée en arrière-plan et les images sautées ne sautaient plus.

Update Utilisez le dossier de ressources pouvant être dessiné ‘nodp’ pour stocker les fichiers pouvant être dessinés en arrière-plan.
Est-ce qu’un dossier pouvant être dessiné par densité ou un nodpi pouvant être dessiné est prioritaire?

L’access SharedPreferences est une autre cause fréquente de retards sur le thread d’interface utilisateur. Lorsque vous appelez une méthode PreferenceManager.getSharedPreferences et d’autres méthodes similaires pour la première fois, le fichier .xml associé est immédiatement chargé et analysé dans le même thread .

L’une des bonnes façons de lutter contre ce problème est de déclencher la première charge SharedPreference à partir du thread d’arrière-plan, démarrée le plus tôt possible (par exemple, depuis la onCreate de votre classe d’application). De cette façon, l’object de préférence peut déjà être construit au moment où vous souhaitez l’utiliser.

Malheureusement, il est parfois nécessaire de lire un fichier de préférence lors des premières phases de démarrage (par exemple, dans l’activité initiale ou même l’application elle-même). Dans de tels cas, il est toujours possible d’éviter de bloquer l’interface utilisateur en utilisant MessageQueue.IdleHandler . Faites tout ce que vous devez faire sur le thread principal, puis installez IdleHandler pour exécuter du code une fois que votre activité a été complètement dessinée. Dans ce Runnable, vous devriez pouvoir accéder à SharedPreferences sans retarder trop d’opérations de dessin et rendre le chorégraphe mécontent.

Essayez d’utiliser les stratégies suivantes afin d’améliorer les performances de votre application:

  • Utilisez si possible une programmation multi-threading. Les avantages en termes de performances sont énormes, même si votre smartphone est doté d’un cœur (les threads peuvent s’exécuter dans différents cœurs, si le processeur en possède deux ou plus). Il est utile de séparer la logique de votre application de l’interface utilisateur. Utilisez les threads Java, AsyncTask ou IntentService. Vérifiez ceci .
  • Lisez et suivez les conseils de performances divers du site Web de développement Android. Vérifiez ici .

Je ne suis pas un expert, mais j’ai reçu ce message de débogage lorsque je voulais envoyer des données de mon application Android à un serveur Web. Bien que j’utilise la classe AsyncTask et que j’ai effectué le transfert de données en arrière-plan, pour récupérer les données du serveur, j’ai utilisé la méthode get () de la classe AsyncTask, ce qui signifie que l’interface utilisateur attendra trop longtemps. Je vous conseille donc de faire en sorte que votre application exécute toutes les tâches orientées réseau sur un thread distinct.

J’ai eu le même problème. Dans mon cas, j’avais 2 schémas relatifs nesteds. RelativeLayout doit toujours effectuer deux passes de mesure. Si vous imbriquez RelativeLayouts, vous obtenez un algorithme de mesure exponentiel.

Optimisez vos images … N’utilisez pas des images de plus de 100 Ko … Le chargement des images prend trop de temps processeur et votre application se bloque.

J’ai eu le même problème. Android Emulator a parfaitement fonctionné sur Android <= 6.0. Lorsque j'ai essayé l'émulateur Nexus 5 (Android 6.0), l'application fonctionnait très lentement avec I/Choreographer: Skipped frames dans les journaux.

Donc, j’ai résolu ce problème en changeant dans le fichier manifeste hardwareAccelerated option hardwareAccelerated en true comme ceci:

    ...   

Mon application avait le même problème. Mais il ne s’agissait pas d’afficher la liste des cartes et du texte dessus. Rien ne fonctionne en arrière-plan. Mais après une enquête a révélé que le jeu d’images pour l’arrière-plan de la carte en était la cause, même s’il était petit (350kb). Ensuite, j’ai converti l’image en images 9patch en utilisant http://romannurik.github.io/AndroidAssetStudio/index.html .
Cela a fonctionné pour moi.

Après avoir fait beaucoup de R & D sur ce sujet, j’ai eu la solution,

Dans mon cas, je suis en train d’utiliser Service qui fonctionnera toutes les 2 secondes et avec le runonUIThread, je me demandais si le problème était là mais pas du tout. Le prochain problème que j’ai trouvé est que j’utilise une grande image dans may app et que c’est le problème.

J’ai enlevé les images et défini de nouvelles images.

Conclusion: – Regardez dans votre code si un fichier brut que vous utilisez est de grande taille.

Lisez d’abord l’avertissement. Il dit plus de charge sur le thread principal. Donc, il suffit d’exécuter des fonctions avec plus de travail dans un thread.

J’ai eu le même problème. Lorsque j’ai exécuté le code sur un autre ordinateur, cela a fonctionné correctement. Sur le mien, cependant, il affiche “L’application peut faire trop de travail sur son thread principal”.

J’ai résolu mon problème en redémarrant le studio Android [Fichier -> Caches / Redémarrage invalidé -> cliquez sur “Invalider et redémarrer”].

J’ai eu le même problème en développant une application qui utilise beaucoup de fichiers png pouvant être dessinés sur la grid. J’ai également essayé d’optimiser mon code autant que possible .. mais cela n’a pas fonctionné pour moi. Puis j’ai essayé de réduire la taille de ces png et deviner que cela fonctionnerait parfaitement bien. Donc je suggère de réduire taille des ressources exploitables le cas échéant ..

Vous pouvez utiliser la bibliothèque Glide pour charger des images. Elle chargera l’image sur le thread d’arrière-plan.