Évaluez les performances

Utilisez Simpleperf pour évaluer les performances d'un appareil. Simpleperf est un outil de profilage natif applications et processus natifs sur Android. Utilisez Profileur de processeur pour inspecter l'utilisation du processeur de l'application et l'activité des threads en temps réel.

L'utilisateur peut voir les deux indicateurs de performances suivants:

  • Performances prévisibles et perceptibles : L’utilisateur l'interface utilisateur (UI) supprime-t-elle des images ou s'affiche-t-elle de façon cohérente à 60 FPS ? Lecture audio sans artefacts ni éclats ? Combien de temps s'écoule entre le moment où l'utilisateur touche l'écran et l'effet qui s'affiche à l'écran ?
  • Durée nécessaire pour des opérations plus longues (par exemple, l'ouverture des applications).

Le premier est plus visible que le second. Les utilisateurs remarquent généralement des à-coups mais ils ne peuvent pas faire la différence entre un temps de démarrage de 500 ms et 600 ms, sauf ils regardent deux appareils côte à côte. La latence tactile est immédiatement est visible et contribue de manière significative à la perception de l'appareil.

Par conséquent, sur un appareil rapide, le pipeline d'UI est la chose la plus importante au système autre que ce qui est nécessaire pour que le pipeline d'UI reste fonctionnel. Ce signifie que le pipeline d'UI doit préempter toute autre tâche qui n'est pas nécessaire pour une UI fluide. Pour maintenir une UI fluide, la synchronisation en arrière-plan, l'envoi de notifications et les tâches similaires doivent toutes être retardées si le travail de l'interface utilisateur peut être exécuté. Il est accepter les performances d'opérations plus longues (environnement d'exécution HDR+, le démarrage de l'application, etc.) afin de maintenir une interface utilisateur fluide.

Capacité et gigue

Lorsque vous examinez les performances d'un appareil, vous devez tenir compte de la capacité et de la gigue sont deux métriques significatives.

Capacité

La capacité est la quantité totale de ressources que possède l'appareil un certain temps. Il peut s'agir de ressources de processeur, de GPU, d'E/S, les ressources réseau, la bande passante de mémoire ou toute autre métrique similaire. Lors de l’examen les performances du système dans son ensemble, il peut être utile d'extraire les composants individuels et supposer qu'il s'agit d'une seule métrique qui détermine les performances (en particulier lorsque vous réglez nouvel appareil, car les charges de travail exécutées sur cet appareil sont probablement corrigées).

La capacité d'un système varie en fonction des ressources de calcul en ligne. La modification de la fréquence du processeur/GPU est le principal moyen de modifier la capacité, mais il existe d'autres, comme la modification du nombre de cœurs de CPU en ligne. En conséquence, le la capacité d'un système correspond à la consommation d'énergie ; changement entraîne toujours une variation similaire de la consommation d'énergie.

La capacité requise à un moment donné est largement déterminée par l'application en cours d'exécution. Par conséquent, la plate-forme n'est pas en mesure d'ajuster requise pour une charge de travail donnée, et les moyens d'y parvenir sont limités des améliorations de l'environnement d'exécution (framework Android, ART, Bionic, compilateurs/pilotes de GPU, noyau).

Gigue

Si la capacité requise pour une charge de travail est facile à voir, la gigue est nébuleux. Pour bien présenter la gigue comme un obstacle à la rapidité systèmes, reportez-vous à LE CAS DES PERFORMANCES MANQUANTES DU SUPER-COMPUTER: OBTENIR DES PERFORMANCES OPTIMALES SUR LES 8 192 PROCESSEURS D'ASCl Q. Il s'agit de comprendre pourquoi l'ASCI Le superordinateur Q n'a pas atteint les performances attendues et est excellent introduction à l'optimisation des grands systèmes.)

Cette page utilise le terme gigue pour décrire ce que l'article ASCI Q appelle bruit. La gigue est le comportement aléatoire du système qui empêche le travail à partir de son exécution. Il s'agit souvent d'une tâche qui doit être exécutée, mais elle peut ne pas avoir de règles strictes qui entraînent son exécution à un moment donné. Parce qu’il s’agit aléatoire, il est extrêmement difficile de réfuter l'existence de la gigue pour une pour une charge de travail donnée. Il est également extrêmement difficile de prouver qu'une source connue la gigue était à l'origine d'un problème de performances particulier. Les outils les plus courants utilisée pour diagnostiquer les causes de la gigue (comme le traçage ou la journalisation) peut introduire leur propre gigue.

Sources de gigue observées dans les implémentations réelles d'Android incluent:

  • Retard du programmeur
  • Interrompre les gestionnaires
  • Code de pilote s'exécutant trop longtemps avec préemption ou interruptions désactivées
  • Softirqs de longue date
  • Conflit de verrouillage (application, framework, pilote de noyau, verrouillage de liaison, mmap) verrouiller)
  • Contention de descripteur de fichier où un thread à faible priorité maintient le verrou sur un ce qui empêche l'exécution d'un thread à priorité élevée
  • Exécuter du code critique de l'interface utilisateur dans des files d'attente pouvant être retardé
  • Transitions d'inactivité du processeur
  • Journalisation
  • Retards d'E/S
  • Création de processus inutile (par exemple, diffusions CONNECTIVITY_CHANGE)
  • Le thrashing du cache de la page est dû à un manque de mémoire disponible

La durée requise pour une période de gigue donnée peut ou non diminue à mesure que la capacité augmente. Par exemple, si un conducteur vous interrompt, désactivé en attente d'une lecture sur un bus i2c, la durée d'exécution quelle que soit la fréquence du processeur à 384 MHz ou 2 GHz. En hausse la capacité n'est pas une solution réalisable pour améliorer les performances lorsque la gigue impliqués. Par conséquent, les processeurs plus rapides n'améliorent généralement pas les performances dans les situations où la gigue est limitée.

Enfin, contrairement à la capacité, la gigue relève presque entièrement du domaine de votre fournisseur de système.

Consommation de mémoire

La consommation de mémoire est généralement due à de mauvaises performances. Alors que la consommation en elle-même n'est pas un problème de performances, il peut provoquer de la gigue via Lowmemorykiller, les redémarrages de services et le thrashing du cache de pages. En baisse la consommation de mémoire peut éviter les causes directes de mauvaises performances, mais il existe d'autres améliorations ciblées permettant d'éviter ces causes (par exemple, épingler le framework pour éviter qu'il ne soit paginé lorsqu'il le sera ; peu de temps après).

Analyser les performances initiales de l'appareil

Commencer par un système fonctionnel mais peu performant et tenter de corriger le comportement du système en analysant les cas individuels de problèmes les performances n'est pas une bonne stratégie. Comme des performances médiocres n'est généralement pas facilement reproductible (la gigue) ni présente un problème d'application. de nombreuses variables dans le système complet empêchent cette stratégie d'être efficace. En tant que Par conséquent, il est très facile de mal identifier les causes et d'apporter des améliorations mineures tout en passer à côté d'opportunités systémiques d'amélioration des performances dans l'ensemble du système ;

Utilisez plutôt l'approche générale suivante lorsque vous affichez une nouvelle appareil:

  1. Faites en sorte que le système démarre sur l'interface utilisateur avec tous les pilotes en cours d'exécution et quelques les paramètres du gouverneur de fréquence (si vous modifiez les paramètres du gouverneur de fréquence, répétez toutes les étapes ci-dessous).
  2. Assurez-vous que le noyau est compatible avec le point de trace sched_blocked_reason ainsi que d'autres points de trace dans le pipeline d'affichage qui indiquent quand la trame s'affiche à l'écran.
  3. Prendre de longues traces de l'ensemble du pipeline d'interface utilisateur (de la réception d'entrées via un IQL) à l'analyse finale) tout en exécutant une charge de travail légère et cohérente (par exemple, UiBench ou le test global dans TouchLatency).
  4. Correction des pertes de frames détectées dans les images légères et cohérentes charge de travail spécifique.
  5. Répétez les étapes 3 à 4 jusqu'à ce que vous puissiez exécuter l'application sans perte de frames pendant plus de 20 secondes à la fois.
  6. Passez à d'autres sources d'à-coups visibles par l'utilisateur.

Voici d'autres opérations simples que vous pouvez effectuer dès le début de l'affichage de l'appareil:

  • Assurez-vous que votre noyau dispose du sched_blocked_reason correctif tracepoint. Ce point de trace est activé avec la catégorie de trace programmée dans Systrace et fournit la fonction responsable du sommeil le thread en veille sans interruption. Il est essentiel pour l'analyse des performances car le sommeil sans interruption est un indicateur très courant de la gigue.
  • Assurez-vous de disposer d'un traçage suffisant pour le GPU et les pipelines d'affichage. Activé des SOC Qualcomm récents, les tracepoints sont activés à l'aide des éléments suivants:
    • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

    Ces événements restent activés lorsque vous exécutez Systrace afin que vous puissiez voir les informations dans le trace concernant le pipeline d'affichage (MDSS) dans le Section mdss_fb0. Dans les SOC Qualcomm, vous n'aurez pas accès des informations sur le GPU dans la vue Systrace standard, mais les résultats sont présente dans la trace elle-même (pour en savoir plus, consultez Comprendre Systrace).

    Ce que vous attendez de ce type de traçage de l'affichage est un événement unique indique directement qu'un cadre a été envoyé à l'écran. À partir de là, vous peut déterminer si vous avez atteint votre temps de rendu avec succès ; Si l'événement Xn se produit moins de 16,7 ms après l'événement Xn-1 (en supposant un affichage de 60 Hz) ; alors vous savez que vous n'avez pas à-coup. Si votre SOC ne fournit pas ces signaux, avec votre fournisseur pour les obtenir. Le débogage de la gigue est extrêmement difficile le signal définitif de l'achèvement de la trame.

Utiliser des benchmarks synthétiques

Les analyses comparatives synthétiques sont utiles pour garantir les fonctionnalités de base d'un appareil est présent. Toutefois, traiter les benchmarks comme un indicateur de l'appareil perçu les performances ne sont pas utiles.

D'après des expériences avec les SOC, différences au niveau des benchmarks synthétiques entre les SOC n'est pas corrélée à une différence similaire Performances perceptibles de l'interface utilisateur (nombre de frames perdus, 99e centile de frames) l'heure, etc.). Les benchmarks synthétiques sont des benchmarks de capacité uniquement. impacts de la gigue les performances mesurées de ces benchmarks du benchmark. En conséquence, les scores de benchmark synthétiques non pertinente pour mesurer les performances perçues par l'utilisateur.

Prenons l'exemple de deux SOC exécutant le benchmark X qui affiche 1 000 images d'UI et indique le délai total d'affichage (un score faible est préférable).

  • SOC 1 effectue le rendu de chaque image du benchmark X en 10 ms et obtient un score de 10 000.
  • SOC 2 affiche 99% des images en 1 ms, mais 1% des images en 100 ms et les scores 19 900, soit un score nettement supérieur.

Si l'analyse comparative indique les performances réelles de l'interface utilisateur, le SOC 2 serait inutilisable. Avec une fréquence d'actualisation de 60 Hz, le SOC 2 présenterait des frames saccadés tous les 1,5 s de fonctionnement. Dans le même temps, le SOC 1 (le SOC le plus lent selon le benchmark X) serait parfaitement fluide.

Utiliser les rapports de bug

Les rapports de bugs sont parfois utiles pour l'analyse des performances, sont si lourds qu'ils sont rarement utiles pour déboguer les problèmes d'à-coups sporadiques. Ils peuvent fournir quelques indices sur ce que faisait le système à un moment donné, surtout si l'à-coup était lié à une transition d'application (qui est enregistrée un rapport de bug). Les rapports d'erreur peuvent également indiquer une portée plus large qui pourraient réduire sa capacité effective (comme la valeur une limitation ou une fragmentation de la mémoire).

Utiliser la latence tactile

Plusieurs exemples de comportement insatisfaisant sont dus à TouchLatency, qui est la charge de travail périodique privilégiée utilisée pour le Pixel et le Pixel XL. Disponible à l'adresse frameworks/base/tests/TouchLatency et propose deux modes: la latence tactile et balle rebondissante (pour changer de mode, cliquez sur le bouton en haut à droite .

Le test d'une balle rebondissante est tout aussi simple qu'il y paraît: une balle rebondit. autour de l'écran pour toujours, quelle que soit l'entrée utilisateur. Il est généralement aussi de loin le test le plus difficile à exécuter parfaitement, mais plus il est proche s'exécute sans perte de frames, meilleur sera votre appareil. La Le test de la balle rebondissante est difficile, car il est simple, mais parfaitement cohérent. charge de travail qui s'exécute à une horloge très faible (cela suppose que l'appareil a une fréquence gouverneur si l'appareil fonctionne avec des horloges fixes, rétrogradez la CPU/GPU à une valeur proche du minimum lorsque vous exécutez le test de la balle rebondissante pour la première fois). À mesure que le système s'arrête et que les horloges se rapprochent de l'inactivité, le processeur/GPU le temps par image augmente. Vous pouvez observer les à-coups, pourra également voir les frames manqués dans Systrace.

Comme la charge de travail est très cohérente, vous pouvez identifier la plupart des sources la gigue beaucoup plus facilement que dans la plupart des charges de travail visibles par l'utilisateur. s'exécute exactement sur le système lors de chaque frame manqué, au lieu de l'UI. pipeline. Les horloges basses amplifient les effets de la gigue en les rendant plus de chances que toute gigue entraîne une perte de frames. Par conséquent, la latence tactile est de 60 FPS, moins le système est susceptible d'être défectueux. qui provoquent des à-coups sporadiques et difficiles à reproduire dans des applications.

La gigue étant souvent (mais pas toujours) invariante par la vitesse de l'horloge, utilisez un test qui s'exécute à des horloges très faibles pour diagnostiquer la gigue pour les raisons suivantes:

  • La gigue n'est pas forcément invariante par la vitesse de l'horloge. de nombreuses sources n'utilisent que le processeur en temps réel.
  • Le gouverneur doit obtenir le temps de rendu moyen à l'approche de la date limite les horloges, de sorte que le temps passé à exécuter des tâches hors UI peut le dépasser pour l’abandon d’une image.