Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Évaluation des performances

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

Il existe deux indicateurs de performance visibles par l'utilisateur:

  • Performances prévisibles et perceptibles . L'interface utilisateur (UI) supprime-t-elle des images ou effectue-t-elle un rendu cohérent à 60 images par seconde? L'audio est-il lu sans artefacts ni éclats? Combien de temps dure le délai entre l'utilisateur touchant l'écran et l'effet affiché sur l'écran?
  • Durée requise pour des opérations plus longues (telles que l'ouverture d'applications).

Le premier est plus visible que le second. Les utilisateurs remarquent généralement des jank mais ils ne pourront pas dire le temps de démarrage de l'application 500 ms contre 600 ms à moins qu'ils ne regardent deux appareils côte à côte. La latence tactile est immédiatement perceptible et contribue de manière significative à la perception d'un appareil.

Par conséquent, dans un appareil rapide, le pipeline d'interface utilisateur est l'élément le plus important du système, à part ce qui est nécessaire pour maintenir le pipeline d'interface utilisateur fonctionnel. Cela signifie que le pipeline d'interface utilisateur doit anticiper tout autre travail qui n'est pas nécessaire pour l'interface utilisateur fluide. Pour maintenir une interface utilisateur fluide, la synchronisation en arrière-plan, la remise des notifications et le travail similaire doivent tous être retardés si le travail de l'interface utilisateur peut être exécuté. Il est acceptable d'échanger les performances d'opérations plus longues (HDR + runtime, démarrage d'application, etc.) pour maintenir une interface utilisateur fluide.

Capacité vs gigue

Lorsque l'on considère les performances de l'appareil, la capacité et la gigue sont deux mesures significatives.

Capacité

La capacité est la quantité totale de ressources que le périphérique possède pendant un certain temps. Il peut s'agir de ressources CPU, de ressources GPU, de ressources d'E / S, de ressources réseau, de bande passante mémoire ou de toute autre métrique similaire. Lors de l'examen des performances de l'ensemble du système, il peut être utile d'abstraire les composants individuels et de supposer une seule métrique qui détermine les performances (en particulier lors du réglage d'un nouveau périphérique, car les charges de travail exécutées sur ce périphérique sont probablement corrigées).

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

La capacité requise à un moment donné est majoritairement déterminée par l'application en cours d'exécution. En conséquence, la plate-forme ne peut pas faire grand-chose pour ajuster la capacité requise pour une charge de travail donnée, et les moyens pour le faire sont limités à des améliorations d'exécution (framework Android, ART, Bionic, compilateur / pilotes GPU, noyau).

Jitter

Alors que la capacité requise pour une charge de travail est facile à voir, la gigue est un concept plus nébuleux. Pour une bonne introduction à la gigue en tant qu'obstacle aux systèmes rapides, reportez-vous au CAS DE LA PERFORMANCE DU SUPERCOMPUTER MANQUANT: ATTEINDRE DES PERFORMANCES OPTIMALES SUR LES 8 192 PROCESSEURS DE ASCl Q. (Il s'agit d'une enquête sur les raisons pour lesquelles le supercalculateur ASCI Q n'a pas atteint les performances attendues et constitue une excellente introduction à l'optimisation de grands systèmes.)

Cette page utilise le terme gigue pour décrire ce que le papier ASCI Q appelle le bruit . La gigue est le comportement aléatoire du système qui empêche l'exécution d'un travail perceptible. C'est souvent un travail qui doit être exécuté, mais il se peut qu'il ne soit pas soumis à des exigences de minutage strictes qui l'obligent à s'exécuter à un moment donné. Comme il est aléatoire, il est extrêmement difficile de réfuter l'existence de la gigue pour une charge de travail donnée. Il est également extrêmement difficile de prouver qu'une source connue de gigue était la cause d'un problème de performances particulier. Les outils les plus couramment utilisés pour diagnostiquer les causes de la gigue (comme le traçage ou la journalisation) peuvent introduire leur propre gigue.

Les sources de gigue rencontrées dans les implémentations réelles d'Android incluent:

  • Retard du planificateur
  • Gestionnaires d'interruption
  • Le code du conducteur s'exécute trop longtemps avec la préemption ou les interruptions désactivées
  • Softirqs de longue durée
  • Contention de verrouillage (application, framework, pilote de noyau, verrou de classeur, verrou mmap)
  • Conflit de descripteur de fichier où un thread de basse priorité maintient le verrou sur un fichier, empêchant un thread de haute priorité de s'exécuter
  • Exécution de code critique pour l'interface utilisateur dans les files d'attente de travail où il pourrait être retardé
  • Transitions inactives du processeur
  • Enregistrement
  • Retards d'E / S
  • Création de processus inutile (par exemple, diffusions CONNECTIVITY_CHANGE)
  • Suppression du cache de page causée par une mémoire libre insuffisante

La durée requise pour une période donnée de gigue peut ou non diminuer à mesure que la capacité augmente. Par exemple, si un pilote laisse les interruptions désactivées en attendant une lecture sur un bus i2c, cela prendra un temps fixe, que le processeur soit à 384 MHz ou 2 GHz. L'augmentation de la capacité n'est pas une solution réalisable pour améliorer les performances en cas de gigue. En conséquence, des processeurs plus rapides n'amélioreront généralement pas les performances dans des situations de gigue limitée.

Enfin, contrairement à la capacité, la gigue est presque entièrement du domaine du fournisseur du système.

Consommation de mémoire

La consommation de mémoire est traditionnellement imputée aux performances médiocres. Bien que la consommation en elle-même ne soit pas un problème de performances, elle peut provoquer une gigue via une surcharge de lowmemorykiller, des redémarrages de service et une suppression du cache de page. La réduction de la consommation de mémoire peut éviter les causes directes de performances médiocres, mais il peut y avoir d'autres améliorations ciblées qui évitent également ces causes (par exemple, épingler le cadre pour éviter qu'il ne soit paginé lorsqu'il sera paginé peu de temps après).

Analyse des performances initiales de l'appareil

Partir d'un système fonctionnel mais peu performant et tenter de corriger le comportement du système en examinant des cas individuels de performances médiocres visibles par l'utilisateur n'est pas une bonne stratégie. Parce que les performances médiocres ne sont généralement pas facilement reproductibles (c.-à-d. Gigue) ou sont un problème d'application, trop de variables dans le système complet empêchent cette stratégie d'être efficace. En conséquence, il est très facile de mal identifier les causes et d'apporter des améliorations mineures tout en manquant des opportunités systémiques pour corriger les performances du système.

Utilisez plutôt l'approche générale suivante lors de la mise en place d'un nouvel appareil:

  1. Obtenez le démarrage du système sur l'interface utilisateur avec tous les pilotes en cours d'exécution et certains paramètres de base du régulateur de fréquence (si vous modifiez les paramètres du régulateur de fréquence, répétez toutes les étapes ci-dessous).
  2. Assurez-vous que le noyau prend en charge le point de sched_blocked_reason sched_blocked_reason ainsi que d'autres points de trace dans le pipeline d'affichage qui indiquent le moment où la trame est livrée à l'affichage.
  3. Prenez de longues traces de l'ensemble du pipeline de l'interface utilisateur (de la réception de l'entrée via une IRQ à l'analyse finale) tout en exécutant une charge de travail légère et cohérente (par exemple, UiBench ou le test de balle dans TouchLatency) .
  4. Corrigez les chutes de trames détectées dans la charge de travail légère et cohérente.
  5. Répétez les étapes 3 à 4 jusqu'à ce que vous puissiez exécuter avec zéro image perdue pendant plus de 20 secondes à la fois.
  6. Passez à d'autres sources de jank visibles par l'utilisateur.

Voici d'autres choses simples que vous pouvez faire dès le début de la mise en service de l'appareil:

  • Assurez-vous que votre noyau dispose du correctif de point de trace sched_blocked_reason . Ce point de trace est activé avec la catégorie de trace de planification dans systrace et fournit la fonction responsable de la mise en veille lorsque ce thread entre en veille ininterrompue. Il est essentiel pour l'analyse des performances car le sommeil sans interruption est un indicateur très courant de gigue.
  • Assurez-vous de disposer d'un traçage suffisant pour le GPU et les pipelines d'affichage. Sur les SOC Qualcomm récents, les points de trace sont activés à l'aide de:
  • 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 des informations supplémentaires dans la trace sur le pipeline d'affichage (MDSS) dans la section mdss_fb0 . Sur les SOC Qualcomm, vous ne verrez aucune information supplémentaire sur le GPU dans la vue systrace standard, mais les résultats sont présents dans la trace elle-même (pour plus de détails, voir Comprendre systrace ).

    Ce que vous attendez de ce type de traçage d'affichage est un événement unique qui indique directement qu'une image a été envoyée à l'écran. De là, vous pouvez déterminer si vous avez atteint votre temps de trame avec succès; si l'événement X n se produit moins de 16,7 ms après l'événement X n-1 (en supposant un affichage à 60 Hz), vous savez que vous n'avez pas sauté. Si votre SOC ne fournit pas de tels signaux, travaillez avec votre fournisseur pour les obtenir. Le débogage de la gigue est extrêmement difficile sans un signal définitif d'achèvement de la trame.

Utilisation de benchmarks synthétiques

Les benchmarks synthétiques sont utiles pour s'assurer que les fonctionnalités de base d'un appareil sont présentes. Cependant, traiter les benchmarks comme un proxy pour les performances perçues de l'appareil n'est pas utile.

Sur la base des expériences avec les SOC, les différences de performance de référence synthétique entre les SOC ne sont pas corrélées avec une différence similaire dans les performances de l'interface utilisateur perceptible (nombre de trames perdues, temps de trame du 99e centile, etc.). Les repères synthétiques sont des repères de capacité uniquement; la gigue a un impact sur les performances mesurées de ces benchmarks uniquement en dérobant du temps à l'exploitation en masse du benchmark. En conséquence, les scores de référence synthétiques ne sont généralement pas pertinents en tant que mesure de la performance perçue par l'utilisateur.

Considérez deux SOC exécutant Benchmark X qui rend 1000 images d'interface utilisateur et indique le temps de rendu total (un score inférieur est meilleur).

  • SOC 1 rend chaque image de Benchmark X en 10 ms et obtient un score de 10 000.
  • SOC 2 rend 99% des images en 1 ms, mais 1% des images en 100 ms et obtient un score de 19 900, un score nettement meilleur.

Si le benchmark est indicatif des performances réelles de l'interface utilisateur, SOC 2 serait inutilisable. En supposant un taux de rafraîchissement de 60 Hz, SOC 2 aurait une trame irrégulière toutes les 1,5 s de fonctionnement. Pendant ce temps, le SOC 1 (le SOC le plus lent selon Benchmark X) serait parfaitement fluide.

Utilisation des rapports de bogue

Les rapports de bogues sont parfois utiles pour l'analyse des performances, mais comme ils sont si lourds, ils sont rarement utiles pour déboguer des problèmes de jank sporadiques. Ils peuvent fournir des indications sur ce que le système faisait à un moment donné, surtout si le jank concernait une transition d'application (qui est consignée dans un rapport de bogue). Les rapports de bogue peuvent également indiquer quand quelque chose ne va pas dans le système et pourrait réduire sa capacité effective (comme la limitation thermique ou la fragmentation de la mémoire).

Utilisation de TouchLatency

Plusieurs exemples de mauvais comportement proviennent de TouchLatency, qui est la charge de travail périodique préférée utilisée pour le Pixel et le Pixel XL. Il est disponible sur frameworks/base/tests/TouchLatency et dispose de deux modes: latence tactile et balle rebondissante (pour changer de mode, cliquez sur le bouton dans le coin supérieur droit).

Le test de la balle qui rebondit est exactement aussi simple qu'il y paraît: une balle rebondit sur l'écran pour toujours, quelle que soit l'entrée de l'utilisateur. C'est généralement aussi de loin le test le plus difficile à exécuter parfaitement, mais plus il se rapproche de l'exécution sans aucune image perdue, meilleur sera votre appareil. Le test de la balle rebondissante est difficile car il s'agit d'une charge de travail triviale mais parfaitement cohérente qui s'exécute à une horloge très basse (cela suppose que l'appareil dispose d'un régulateur de fréquence; si l'appareil fonctionne à la place avec des horloges fixes, downclockez le processeur / GPU au minimum. lors de l'exécution du test de balle rebondissante pour la première fois). À mesure que le système se met au repos et que les horloges se rapprochent du ralenti, le temps CPU / GPU requis par image augmente. Vous pouvez regarder le ballon et voir les choses jank, et vous pourrez également voir les images manquées dans systrace.

Étant donné que la charge de travail est si cohérente, vous pouvez identifier la plupart des sources de gigue beaucoup plus facilement que dans la plupart des charges de travail visibles par l'utilisateur en suivant ce qui s'exécute exactement sur le système pendant chaque trame manquée au lieu du pipeline de l'interface utilisateur. Les horloges inférieures amplifient les effets de la gigue en augmentant la probabilité que toute gigue provoque une trame perdue. En conséquence, plus TouchLatency est proche de 60FPS, moins vous risquez d'avoir de mauvais comportements système qui provoquent des saccades sporadiques et difficiles à reproduire dans les applications plus volumineuses.

Comme la gigue est souvent (mais pas toujours) invariante de la vitesse d'horloge, utilisez un test qui s'exécute à des horloges très basses pour diagnostiquer la gigue pour les raisons suivantes:

  • Toute la gigue n'est pas invariante en vitesse d'horloge; de nombreuses sources consomment simplement du temps CPU.
  • Le gouverneur doit rapprocher le temps de trame moyen de la date limite en diminuant le pointage, de sorte que le temps passé à exécuter un travail non lié à l'interface utilisateur peut le pousser au-delà de la suppression d'une trame.