Inspecter l’activité du processeur avec CPU Profiler

Optimiser l’utilisation du PROCESSEUR de votre application présente de nombreux avantages, tels que fournir une expérience utilisateur plus rapide et plus fluide et préserver la durée de vie de la batterie de l’appareil.

Vous pouvez utiliser le profileur CPU pour inspecter l’utilisation du processeur et l’activité du thread de votre application en temps réel lors de l’interaction avec votre application, ou vous pouvez inspecter les détails des traces de méthode enregistrées, des traces de fonction et des traces système.

Les types d’informations spécifiques que le profileur CPU enregistre et affiche sont déterminés par la configuration d’enregistrement que vous choisissez:

• Trace système: Capture des détails à grain fin qui vous permettent d’inspecter comment votre application interagit avec les ressources système.

• Traces de méthodes et de fonctions: Pour chaque thread de votre processus d’application, vous pouvez déterminer quelles méthodes (Java) ou fonctions (C / C++) sont exécutées sur une période de temps et les ressources CPU consommées par chaque méthode ou fonction lors de son exécution. Vous pouvez également utiliser des traces de méthodes et de fonctions pour identifier les appelants et les appels. Un appelant est une méthode ou une fonction qui appelle une autre fonction de méthode, et un appelé est celui qui est invoqué par une autre méthode ou fonction. Vous pouvez utiliser ces informations pour déterminer quelles méthodes ou fonctions sont responsables d’invoquer trop souvent des tâches particulières nécessitant des ressources et d’optimiser le code de votre application pour éviter tout travail inutile.

  Lors de l’enregistrement des traces de méthode, vous pouvez choisir sampled ou instrumentedrecording. Lors de l’enregistrement des traces de fonction, vous ne pouvez utiliser que l’enregistrement échantillonné.

Pour plus de détails sur l’utilisation et le choix de chacune de ces options de suivi, voirchoisissez une configuration d’enregistrement.

Présentation du Profileur CPU

Pour ouvrir le Profileur CPU, procédez comme suit :

1. Sélectionnez Afficher >Fenêtres d’outils >Profileur ou cliquez sur Profil dans la barre d’outils.

   Si la boîte de dialogue Sélectionner la cible de déploiement vous y invite, choisissez l’appareil pour lequel déployer votre application pour le profilage. Si vous avez connecté un périphérique via Usbmais ne le voyez pas dans la liste, assurez-vous d’avoir activé le débogage USB.

2. Cliquez n’importe où dans la chronologie du PROCESSEUR pour ouvrir le profileur du processeur.

Lorsque vous ouvrez le profileur CPU, il commence immédiatement à afficher l’activité CPUusage et thread de votre application. Vous devriez voir quelque chose de similaire à la figure 1.

Figure 1. Chronologies dans le profileur CPU.

Comme indiqué sur la figure 1, la vue par défaut du profileur CPU inclut les chronologies suivantes :

1. Chronologie des événements: Affiche les activités de votre application lors de leur transition à travers différents états de leur cycle de vie et indique les interactions de l’utilisateur avec l’appareil, y compris les événements de rotation de l’écran. Pour plus d’informations sur l’activation de la chronologie des événements sur les appareils fonctionnant sous Android 7.1 (niveau API 25) et inférieur, consultez Activer le profilage avancé.
2. Chronologie du PROCESSEUR : Affiche l’utilisation du processeur en temps réel de votre application – en pourcentage du temps CPU total disponible — et le nombre total de threads que votre application utilise. La chronologie montre également l’utilisation du processeur d’autres processus (tels que les processus système ou d’autres applications), afin que vous puissiez la comparer à l’utilisation de votre application. Vous pouvez inspecter les données historiques d’utilisation du processeur en déplaçant votre souris le long de l’axe horizontal de la timeline.
3. Chronologie de l’activité du thread : Répertorie chaque thread appartenant au processus de votre application et indique son activité le long d’une chronologie en utilisant les couleurs énumérées ci-dessous. Après avoir enregistré une trace, vous pouvez sélectionner un thread dans cette chronologie pour inspecter ses données dans le volet de trace.
   • Vert : Le thread est actif ou prêt à utiliser le processeur. Autrement dit, il est dans un état en cours d’exécution ou exécutable.
   • Jaune : Le thread est actif, mais il attend une opération d’E/S, telle que des E/S de disque ou de réseau, avant de pouvoir terminer son travail.
   • Gris: Le thread est en veille et ne consomme aucun temps CPU. Cela se produit parfois lorsque le thread nécessite l’accès à une ressource qui n’est pas encore disponible. Soit le thread entre en veille volontaire, soit le noyau met le thread en veille jusqu’à ce que la ressource requise soit disponible.

   Le profileur de CPU signale également l’utilisation par le processeur des threads qu’Android Studio et la plate—forme Android ajoutent au processus de votre application, tels que JDWPProfile SaverStudio:VMStatsStudio:Perfa, et Studio:Heartbeat (bien que les noms exacts affichés dans la chronologie de l’activité du thread puissent varier). Android Studio rapporte ces données afin que vous puissiez identifier quand l’activité du thread et l’utilisation du PROCESSEUR sont réellement causées par le code de votre application.

Traces d’enregistrement

Pour commencer à enregistrer une trace, choisissez une configuration d’enregistrement dans l’un des menus déroulants au-dessus ou en dessous du profileur CPU et cliquez sur Enregistrer.

Figure 2. Le profileur CPU affiche l’état, la durée et le type d’enregistrement effectué.

Interagissez avec votre application, puis cliquez sur Arrêter lorsque vous avez terminé. Le profileur affiche automatiquement ses informations de traçage dans le volet de traçage, comme indiqué dans la figure 3 :

Figure 3. Le profileur CPU après l’enregistrement d’une trace de méthode.

1. Plage sélectionnée : Détermine la partie du temps enregistré à inspecter dans le volet de suivi. Lorsque vous enregistrez une trace pour la première fois, le profileur CPU sélectionne automatiquement toute la longueur de votre enregistrement dans la chronologie du PROCESSEUR. Pour inspecter les données de trace pour une partie seulement de la plage de temps enregistrée, faites glisser les bords de la région en surbrillance.
2. Section Interaction : Affiche l’interaction utilisateur et les événements du cycle de vie de l’application le long d’une chronologie.
3. Section Threads : Affiche l’activité de l’état du thread (comme l’exécution, la veille, etc.) et un graphique d’appel (ou un graphique d’événements de trace dans la Trace système) pour chaque thread le long d’une chronologie.
   • Utilisez les raccourcis clavier et souris pour naviguer dans la timeline.
   • Double-cliquez sur le nom du thread ou appuyez sur Entrée pendant qu’un thread est sélectionné pour développer ou réduire un thread.
   • Sélectionnez un thread pour afficher des informations supplémentaires dans le volet Analyse. Maintenez la touche Maj ou Ctrl (Commande sur Mac) enfoncée pour sélectionner plusieurs threads.
   • Sélectionnez un appel de méthode (ou un événement de trace dans la Trace système) pour afficher des informations supplémentaires dans le volet Analyse.
4. Volet d’analyse: Affiche les données de trace pour la plage de temps et l’appel de thread ou de méthode que vous avez sélectionnés. Dans ce volet, vous pouvez sélectionner comment afficher chaque trace de pile (à l’aide des onglets analyse) et comment mesurer le temps d’exécution (à l’aide du menu déroulant Référence de temps).
5. Onglets du volet d’analyse : Choisissez comment afficher les détails de la trace. Pour plus de détails sur chaque option, consultez Inspecter les traces.
6. Menu de référence de l’heure : Sélectionnez l’une des options suivantes pour déterminer comment les informations de synchronisation de chaque appel sont mesurées (uniquement prises en charge dans les méthodes Java d’échantillonnage/ de suivi) :
   • Heure de l’horloge murale: Les informations de synchronisation représentent le temps écoulé réel.
   • Temps du thread: Les informations de synchronisation représentent le temps écoulé réel moins toute partie de ce temps lorsque le thread ne consomme pas de ressources CPU. Pour un appel donné, son temps de thread est toujours inférieur ou égal à son temps d’horloge murale. L’utilisation du temps de thread vous permet de mieux comprendre la quantité d’utilisation réelle du PROCESSEUR d’un thread consommée par une méthode ou une fonction donnée.
7. Filtre : Filtre les données de trace par fonction, méthode, classe ou nom de paquet. Par exemple, si vous souhaitez identifier rapidement les données de trace liées à un appel spécifique, tapez le nom dans le champ de recherche. Dans l’onglet Graphique de flamme, les piles d’appels qui incluent un appel, un package ou une classe correspondant à la requête de recherche sont mises en évidence. Dans les onglets de haut en bas et de bas en haut, ces piles d’appels sont prioritaires sur les autres résultats de suivi. Vous pouvez également activer les options suivantes en cochant la case appropriée à côté du champ de recherche :
   • Regex: Pour inclure des expressions régulières dans votre recherche, utilisez cette option.
   • Correspondre à la casse : Si votre recherche est sensible à la casse, utilisez cette option.

Choisissez une configuration d’enregistrement

Avant de commencer l’enregistrement des informations de trace, choisissez la configuration d’enregistrement appropriée pour les informations de profilage que vous souhaitez capturer :

• Exemple de méthodes Java : Capture la pile d’appels de votre application à intervalles fréquents pendant l’exécution du code Java de votre application. Le profileur compare des ensembles de données capturées pour dériver des informations de synchronisation et d’utilisation des ressources sur l’exécution de code basée sur Java de votre application.

  Un problème inhérent au traçage basé sur l’échantillonnage est que si votre application entre dans une méthode après une capture de la pile d’appels et quitte la méthode avant la capture suivante, cet appel de méthode n’est pas enregistré par le profileur. Si vous êtes intéressé par des méthodes de traçage avec des cycles de vie aussi courts, vous devez utiliser le traçage instrumenté.

• Tracer les méthodes Java : Instrumente votre application au moment de l’exécution pour enregistrer un horodatage au début et à la fin de chaque appel de méthode. Les horodatages sont collectés et comparés pour générer des données de suivi de méthode, y compris des informations de synchronisation et d’utilisation du PROCESSEUR.

  Notez que la surcharge associée à l’instrumentation de chaque méthode a un impact sur les performances d’exécution et peut influencer les données de profilage ; cela est encore plus visible pour les méthodes avec des cycles de vie relativement courts. De plus, si votre application exécute un grand nombre de méthodes en peu de temps, le profileur peut rapidement dépasser sa limite de taille de fichier et ne pas être en mesure d’enregistrer d’autres données de traçage.

• Exemple de fonctions C/C++: Capture les traces échantillonnées des threads natifs de votre application. Pour utiliser cette configuration, vous devez déployer votre application sur un appareil fonctionnant sous Android 8.0 (niveau API 26) ou supérieur.

  En interne, cette configuration utilise simpleperf pour tracer le code natif de votre application. Si vous souhaitez spécifier des options supplémentaires pour simpleperf, telles que l’échantillonnage de processeurs de périphériques spécifiques ou la spécification de durées d’échantillonnage avec une grande précision, vous pouvez utiliser simpleperf à partir de la ligne de commande.

• Tracer les appels système : Capture des détails à grain fin qui vous permettent d’inspecter la façon dont votre application interagit avec les ressources système. Vous pouvez inspecter les horaires et les durées exactes des états de votre thread, visualiser les goulots d’étranglement de votre CPU sur tous les cœurs et ajouter des événements de suivi personnalisés à analyser. Ces informations peuvent être cruciales lorsque vous résolvez des problèmes de performances. Pour utiliser cette configuration, vous devez déployer votre application sur un appareil fonctionnant sous Android 7.0 (niveau API 24) ou supérieur.

  Lors de l’utilisation de cette configuration de suivi, vous pouvez marquer visuellement des routines de code importantes dans la chronologie du profileur en instrumentant votre code. Pour instrumenter le code C/C++, utilisez l’API de traçage native fournie par trace.h. Pour instrumenter le code Java, utilisez la classe Trace. Pour plus d’informations, consultez Instrumenter le code de votre application.

  Cette configuration de trace est construite sur systrace. Vous pouvez utiliser l’utilitaire de ligne de commande systrace pour spécifier des options au-delà de celles fournies dans le profileur CPU. Les données supplémentaires au niveau du système fournies par systrace peuvent vous aider à inspecter les processus système natifs et à dépanner les trames abandonnées ou retardées.

  Sur les appareils fonctionnant sous Android 9 (niveau API 28) ou supérieur, vous pouvez utiliser une application système appelée Suivi du système pour enregistrer les traces du système sur un appareil.

Créer, modifier ou afficher une configuration d’enregistrement

Vous créez, modifiez et affichez des configurations d’enregistrement dans la boîte de dialogue Configuration d’enregistrement du PROCESSEUR, que vous ouvrez en sélectionnant Modifier les configurations dans le menu déroulant Configurations d’enregistrement en haut du profileur du processeur.

Pour afficher les paramètres d’une configuration d’enregistrement existante, sélectionnez-la dans le volet Gauche de la boîte de dialogue Configurations d’enregistrement CPU.

Pour créer une nouvelle configuration d’enregistrement, procédez comme suit :

1. Cliquez sur Ajouter en haut à gauche de la boîte de dialogue. Cela crée une nouvelle configuration avec des paramètres par défaut.
2. Nommez votre configuration.
3. Sélectionnez une technologie de trace.
4. Pour les configurations d’enregistrement échantillonnées, spécifiez l’intervalle d’échantillonnage en micros-secondes (µs). Cette valeur représente le temps écoulé entre chaque échantillon de la pile d’appels de votre application. Plus l’intervalle que vous spécifiez est court, plus vousatteindre la limite de taille de fichier pour les données enregistrées.
5. Spécifiez la limite de taille de fichier, en mégaoctets (Mo), pour les données enregistrées écrites sur le périphérique connecté. Lorsque vous arrêtez l’enregistrement, AndroidStudio analyse ces données et les affiche dans la fenêtre du profileur. Donc, si vousaugmentez la limite et enregistrez une grande quantité de données, Android Studio prend beaucoup plus de temps pour analyser le fichier et peut ne plus répondre.

   Remarque : Si vous utilisez un appareil connecté fonctionnant sous Android 8.0 (niveau API 26) ou supérieur, il n’y a pas de limite à la taille du fichier des données de trace, et cette valeur est ignorée. Cependant, vous devez toujours faire attention à la quantité de donnéesl’appareil collecte après chaque enregistrement — Android Studio peut avoir des difficultés à analyser de gros fichiers de trace. Par exemple, si vous enregistrez un sampledtrace avec un court intervalle d’échantillonnage ou une trace instrumentée pendant que votre application appelle de nombreuses méthodes en peu de temps, vous générerez rapidement de gros fichiers de trace.

6. Pour accepter les modifications et continuer à apporter des modifications à d’autres configurations, cliquez sur Appliquer. Pour accepter toutes les modifications appliquées et fermer la boîte de dialogue, cliquez sur Ok.

Enregistrez l’activité du processeur avec l’API de débogage

Vous pouvez utiliser l’API Debug pour permettre à votre application de démarrer et d’arrêter l’enregistrement de l’activité du processeur dans le profileur du PROCESSEUR.

Le profileur CPU commence l’enregistrement lorsque votre application appelle startMethodTracing(String tracePath), et le profileur CPU arrête l’enregistrement lorsque votre application appelle stopMethodTracing(). Lors de l’enregistrement de l’activité du processeur déclenchée à l’aide de cette API, le profileur du PROCESSEUR affiche l’API Debug comme configuration d’enregistrement du PROCESSEUR active.

Pour contrôler l’enregistrement de l’activité du processeur avec l’API Debug, déployez votre application instrumentée sur un appareil fonctionnant sous Android 8.0 (niveau API 26) ou supérieur.

Pour plus d’informations, voiRgénérer les journaux de trace en instrumentant votre application.

Enregistrez l’activité du PROCESSEUR au démarrage de l’application

Pour commencer à enregistrer automatiquement l’activité du processeur au démarrage de l’application, procédez à la suivante :

1. Sélectionnez Exécuter > Modifier les configurations.
2. Dans l’onglet Profilage, cochez la case à côté de Démarrer l’enregistrement d’un methodtrace au démarrage.
3. Sélectionnez une configuration d’enregistrement CPU dans le menu.
4. Cliquez sur Appliquer.
5. Déployez votre application sur un appareil fonctionnant sous Android 8.0 (niveau API 26) ou supérieur en sélectionnant le profil Run>.

Exporter les traces

Après avoir enregistré l’activité du processeur avec le profileur de PROCESSEUR, vous pouvez exporter les données asa .trace fichier à partager avec d’autres ou à inspecter plus tard.

Pour exporter un fichier de trace à partir de la chronologie du PROCESSEUR, procédez comme suit:

1. Dans la chronologie du PROCESSEUR, cliquez avec le bouton droit sur la trace de méthode enregistrée ou la trace système que vous souhaitez exporter.
2. Sélectionnez Exporter la trace dans le menu.
3. Accédez à l’endroit où vous souhaitez enregistrer le fichier, spécifiez le nom du fichier et cliquez sur Ok.

Pour exporter un fichier de trace à partir du volet Sessions, procédez comme suit :

1. Dans le volet Sessions, cliquez avec le bouton droit sur la trace enregistrée que vous souhaitez exporter.
2. Cliquez sur le bouton Exporter la trace de la méthode ou Exporter la trace du système à la hauteur de l’entrée de la session.
3. Accédez à l’endroit où vous souhaitez enregistrer le fichier, spécifiez le nom du fichier et cliquez sur Ok.

Importer des traces

Vous pouvez importer des fichiers .trace créés avec l’API Debug ou un profileur CPU.

Importez votre fichier de trace en cliquant sur Démarrer une nouvelle session de profileur dans le volet Sessions du profileur, puis en sélectionnant Charger à partir du fichier.

Vous pouvez inspecter une trace importée dans le Profileur CPU comme vous le faites avec des traces capturées directement dans le Profileur CPU, avec les exceptions suivantes:

• L’activité du PROCESSEUR n’est pas représentée le long de la chronologie du processeur (sauf dans la Trace système).
• La timeline de la section Threads n’affiche pas les états des threads tels que lancer, attendre ou dormir (sauf dans la Trace système).

Inspecter les traces

La vue trace dans le profileur CPU fournit plusieurs façons d’afficher les informations à partir des traces enregistrées.

Pour les traces de méthode et les traces de fonction, vous pouvez afficher directement le Graphique d’appel dans la chronologie des Threads et le Graphique de flamme, de haut en bas et de bas en haut depuis le volet Analyse. Pour les traces système, vous pouvez afficher les événements de trace directement dans la chronologie des Threads, ainsi que le graphique de flamme, les onglets de Haut en bas et de bas en haut depuis Analysispane.

Des raccourcis clavier et souris sont disponibles pour faciliter la navigation des graphiques d’appels ou des événements de trace.

Inspecter les traces à l’aide du Tableau des appels

Le tableau des appels fournit une représentation graphique d’une trace de méthode ou d’une trace de fonction, où la période et la synchronisation d’un appel sont représentées sur l’axe horizontal, et ses callees sont affichées le long de l’axe vertical. Les appels aux API système sont affichés en orange, les appels aux propres méthodes de votre application sont affichés enen et les appels aux API tierces (y compris les API du langage Java) sont affichés enblue. La figure 4 montre un exemple de diagramme d’appel et illustre le concept de temps auto, de temps enfant et de temps total pour une méthode ou une fonction donnée. Vous pouvez en savoir plus sur ces concepts dans la section sur la façon d’identifier les traces en utilisant de haut en bas et de bas en haut.

Figure 4. Un exemple de graphique d’appel qui illustre l’aide, les enfants et le temps total pour la méthode D.

Astuce: Pour sauter le code source d’une méthode ou d’une fonction, cliquez dessus avec le bouton droit de la souris et sélectionnez Aller à la source. Cela fonctionne à partir de l’un des onglets du volet d’analyse.

Inspectez les traces à l’aide de l’onglet Graphique de flamme

L’onglet Graphique de flamme fournit un graphique d’appel inversé qui agrège les piles d’appels identiques. Autrement dit, des méthodes ou des fonctions identiques qui partagent la même séquence d’appelants sont collectées et représentées sous la forme d’une barre plus longue dans le graphique enflammé (plutôt que de les afficher sous la forme de plusieurs barres plus courtes, comme indiqué dans le graphique acall). Cela permet de voir plus facilement quelles méthodes ou fonctions consomment le plus de temps. Cependant, cela signifie également que l’axe horizontal ne représente pas atimeline; au lieu de cela, il indique le temps relatif nécessaire à l’exécution de chaque méthode orfunction.

Pour illustrer ce concept, considérons le diagramme d’appels de la figure 5. Notez que la méthode D effectue plusieurs appels à B (B1, B2 Etb3), et certains de ces appels à B effectuent un appel à C (C1 etc3).

Figure 5. Un graphique d’appels avec plusieurs appels de méthodes qui partagent une séquence commune d’appelants.

Parce que B1, B2 et B3 partagent la même séquence d’appelants (A → D → B), ils sont agrégés, comme le montre la figure 6. De même, C1 et C3 sont agrégés car ils partagent la même séquence d’appelants (A → D → B → C); notez que C2 n’est pas inclus car il a une séquence d’appelante différente (A → D → C).

Figure 6. Agréger des méthodes identiques qui partagentla même pile d’appels.

Les appels agrégés sont utilisés pour créer le diagramme de flamme, comme le montre la figure 7.Notez que, pour tout appel donné dans un graphique de flamme, les appels qui consomment le plus de temps CPU apparaissent en premier.

Figure 7. Une représentation graphique des flammes du callchart illustré à la figure 5.

Inspectez les traces à l’aide de Haut en bas et de bas en haut

L’onglet Haut en bas affiche une liste d’appels dans lesquels l’expansion d’un nœud de méthode ou de fonction affiche ses appels. La figure 8 montre un graphique de haut en bas pour le callchart de la figure 4. Chaque flèche du graphique pointe d’un appelant à un appelé.

Comme le montre la figure 8, l’expansion du nœud pour la méthode A dans l’onglet du haut vers le bas affiche ses callees, méthodes B et D. Après cela, l’expansion du nœud pour la méthode D expose ses callees, méthodes B et C, et ainsi de suite. Similaire à Flame charttab, l’arborescence de haut en bas agrège les informations de trace pour des méthodes identiques qui partagent la même pile d’appels. Autrement dit, l’onglet graphique de flamme fournit une représentation graphiquereprésentation de l’onglet Haut vers le bas.

L’onglet du haut vers le bas fournit les informations suivantes pour aider à décrire le temps de CPU passé sur chaque appel (les temps sont également représentés en pourcentage du temps total de thethread sur la plage sélectionnée):

• Self: le temps que l’appel de méthode ou de fonction a passé à exécuter son propre code et non celui de ses appels, comme illustré à la figure 4 pour la méthode D.
• Enfants: le temps que l’appel de méthode ou de fonction a passé à exécuter ses appels et non son propre code, comme illustré à la figure 4 pour la méthode D.
• Enfants: le temps que l’appel de méthode ou de fonction a passé à exécuter ses appels et non son propre code, comme illustré à la figure 4 pour la méthode D.
• Total: la somme du temps de Soi et des enfants de la méthode. Cela représente le temps total que l’application a passé à exécuter un appel, comme illustré en figure 4 pour la méthode D.

L’onglet de bas en haut affiche une liste d’appels dans lesquels l’expansion d’une fonction ou du nœud de la méthode affiche ses appelants. En utilisant l’exemple de trace illustré à la figure 8, la figure 9 fournit une arborescence ascendante pour la méthode C. Ouvrir le nœud pour la méthode C Dans l’arborescence ascendante affiche chacun de ses appelants uniques, les méthodes B et D. Notethat, bien que B appelle C deux fois, B n’apparaît qu’une seule fois lors de l’expansion du nœud formethod C dans l’arborescence ascendante. Après cela, développez le nœud pour l’affichage B de son appelant, des méthodes A et D.

L’onglet de bas en haut est utile pour trier les méthodes ou les fonctions par celles qui consomment le plus (ou le moins) de temps CPU. Vous pouvez inspecter chaque nœud pour déterminer quels appelants passent le plus de temps CPU à invoquer ces méthodes ou fonctions.Par rapport à l’arborescence descendante, les informations de synchronisation pour chaque méthode ou fonction dans l’arborescence descendante font référence à la méthode en haut de chaque arborescence (nœud supérieur).Le temps CPU est également représenté en pourcentage du temps total du thread pendant l’enregistrement. Le tableau suivant explique comment interpréter les informations de temps pour le nœud supérieur et ses appelants (sous-nœuds).

	Auto	Enfants	Total
Méthode ou fonction en haut de l’arborescence ascendante (nœud supérieur)	Représente le temps total que la méthode ou la fonction a passé à exécuter son propre code et non celui de ses callees. Par rapport à l’arborescence descendante, ces informations de synchronisation représentent la somme de tous les appels à cette méthode ou fonction sur la durée de l’enregistrement.	Représente le temps total que la méthode ou la fonction a passé à exécuter ses appels et non son propre code. Par rapport à l’arborescence descendante, ces informations de synchronisation représentent la somme de tous les appels à cette méthode ou aux appels de cette fonction sur la durée de l’enregistrement.	La somme du temps de soi et du temps des enfants.
Appelants (sous-nœuds)	Représente le temps d’autonomie total de l’appelé lorsqu’il est appelé par l’appelant. En utilisant l’arborescence ascendante de la figure 9 à titre d’exemple, le temps auto pour la méthode B serait égal à la somme des temps auto pour chaque exécution de la méthode C lorsqu’elle est appelée par B.	Représente le temps enfant total de l’appelé lorsqu’il est invoqué par l’appelant. En utilisant l’arborescence ascendante de la figure 9 à titre d’exemple, le temps enfant de la méthode B serait égal à la somme des temps enfant pour chaque exécution de la méthode C lorsqu’elle est appelée par B.	La somme du temps auto et du temps enfant.

Remarque: Pour un enregistrement donné, Android Studio cesse de collecter de nouvelles données lorsque le profileur atteint la limite de taille de fichier (cependant, cela n’arrête pas l’enregistrement). Cela se produit généralement beaucoup plus rapidement lors de l’exécution de traces instrumentées, car ce type de traçage collecte plus de données en un temps plus court, par rapport à une trace échantillonnée. Si vous prolongez le temps d’inspection jusqu’à la fin de l’enregistrement qui s’est produit après avoir atteint la limite, les données de synchronisation dans le volet de suivi ne changent pas (car aucune nouvelle donnée n’est disponible). De plus, le volet de suivi affiche NaN pour les informations de synchronisation lorsque vous sélectionnez uniquement la partie d’un enregistrement qui ne contient aucune donnée.

Inspecter les traces système

Lors de l’inspection d’une trace système, vous pouvez examiner les événements de trace dans la chronologie theThreads pour afficher les détails des événements qui se produisent sur chaque thread.Passez le pointeur de votre souris sur un événement pour voir le nom de l’événement et le temps passé dans chaque état. Cliquez sur un événement pour afficher plus d’informations dans le volet Analyse.

Le volet Cœurs de processeur (comme illustré à la figure 10) affiche la planification de l’activité du thread sur chaque cœur. Passez le pointeur de la souris sur une activité de thread pour voir sur quel fil ce noyau s’exécute à ce moment précis.

Figure 10. Affichage de l’activité du processeur et des événements de suivi pour le thread de rendu.

Pour plus d’informations sur l’inspection des informations de trace système, reportez-vous à la section sur les problèmes de performances de l’interface utilisateur de la documentation systrace.

Inspecter les données de rendu des images

Vous pouvez inspecter le temps nécessaire à votre application pour rendre chaque image sur le mainthread et RenderThread pour enquêter sur les goulots d’étranglement qui provoquent des jank et des lowframerates de l’interface utilisateur.

Pour voir les données de rendu de trame, enregistrez une trace à l’aide d’une configuration qui vous permet de tracer les appels système. Après l’enregistrement de la trace, recherchez des informations sur chaque image sous la chronologie des images dans la section d’affichage, comme le montre la figure 11.

Figure 11. Chaque image qui prend plus de 16mest affichée en rouge.