Latence et saccades avec Perfetto sur Android : un guide complet

Lorsqu'une application Android semble lente, saccadée ou présente des animations irrégulières (désactiver les animations système)Il y a presque toujours un coupable caché qui se trame en arrière-plan : la latence et les saccades tant redoutées. Android propose plusieurs outils de diagnostic, mais l’un des plus puissants et des plus flexibles est perfetto, combinée à la commande classique dumpsys et des sources de données telles que ftrace, atrace o heapprofdComprendre comment les utiliser correctement vous permet de passer du vague sentiment que « mon application se comporte bizarrement » à des chiffres, des traces et des causes concrets.

Dans cet article, nous allons analyser, calmement mais directement, le sujet., Comment ça marche perfetto Sur Android, quels sont ses modes d'utilisation, quelles sources de données peut-il activer et comment complète-t-il d'autres commandes clés telles que : dumpsys gfxinfo, dumpsys meminfo o dumpsys batterystatsL'idée est de vous donner un aperçu complet de tout ce que vous pouvez mesurer et comment l'utiliser pour optimiser la latence, éliminer les saccades et, accessoirement, améliorer la consommation de mémoire, de réseau et de batterie.

Qu'est-ce que Perfetto et pourquoi est-il si utile pour réduire la latence et les saccades ?

perfetto Il s'agit d'un outil de suivi des performances intégré à Android. qui est normalement lancé depuis l'ordinateur à l'aide d'Android Debug Bridge (ADB) avec des commandes comme adb shell perfetto ...Sa mission est de collecter des informations de bas niveau sur ce qui se passe sur l'appareil : activités du noyau, annotations de l'utilisateur, utilisation de la mémoire, statistiques des processus, etc., le tout dans un format de trace que vous pouvez ensuite analyser avec des visualiseurs comme le site web de perfetto.dev.

Perfetto s'appuie sur plusieurs « sources de données » spécialisées., parmi lesquels figurent :

• ftrace, qui capture les événements du noyau (planification des threads, système de fichiers, etc.).
• atrace, axées sur les annotations provenant de l'espace utilisateur pour les services et les applications.
• heapprofd, axé sur l'échantillonnage de l'utilisation de la mémoire native dans les services et les applications.

En combinant judicieusement ces sourcesVous pouvez enregistrer précisément les informations nécessaires pour suivre les problèmes de latence de l'interface utilisateur, les images sautées, les pics d'utilisation du processeur ou les verrouillages liés aux E/S. Stockage UFS.

Syntaxe de base de Perfetto et modes de fonctionnement

Perfetto peut être utilisé selon deux modes principaux : léger et normal.Les deux sont appelées depuis ADB, mais elles diffèrent considérablement dans la manière dont elles configurent ce qui est tracé et comment cela est enregistré.

L'idée générale reste toujours la même: exécuter une commande adb shell perfetto Il convient de spécifier la durée, la taille du tampon, les sources de données et le fichier de trace de sortie. Le fichier résultant est généralement généré selon le format du protocole. trace.proto à partir d'AOSP, que vous pouvez ensuite ouvrir dans les outils d'analyse de Perfetto.

Options générales lors de l'invocation de Perfetto

Quel que soit le mode (clair ou normal)Il existe un certain nombre d'options communes qui contrôlent la manière dont la capture est exécutée, ce qui est fait avec le fichier généré et comment il est intégré aux systèmes d'alerte ou de téléchargement à distance :

• --background o -d: fait perfetto Quittez l'interface de ligne de commande et poursuivez l'enregistrement en arrière-plan.
• --background-wait o -DSimilaire à la précédente, mais attend jusqu'à 30 secondes que toutes les sources de données confirment leur démarrage. Le code de sortie sera 0 si tout fonctionne correctement et toute autre valeur en cas d'erreur ou de dépassement de délai.
• --alert-id, --config-id, --config-uid y --subscription-id: identifiants qui relient la trace aux alertes ou aux configurations de déclenchement défini dans le système, utile dans les scénarios de surveillance automatisée.
• --out OUT_FILE o -o OUT_FILE: chemin complet où le fichier de trace sera enregistré, ou - si vous préférez que j'aille à stdoutUn répertoire est généralement utilisé comme /data/misc/perfetto-traces.
• --uploadUne fois la capture terminée, transmettez le fichier de trace au paquet spécifié par le message. IncidentReportConfig dans la configuration prototype.
• --no-guardrails y --reset-guardrails: Ils contrôlent les mécanismes de sécurité et les limitations des ressources lorsque le téléchargement automatique est activé (--upload), conçu pour les tests et moins pour la production.
• --rsave-for-bugreport: si la capture a un bugreport_score supérieur à 0, enregistre la trace dans un fichier et affiche le chemin d'accès une fois l'opération terminée, pour faciliter son intégration aux rapports d'erreurs.
• --query y --query-rawIls interrogent l'état du service de traçage. La première commande fournit une sortie lisible, la seconde renvoie le contenu protocodé de tracing_service_state.proto.
• --help o -h: Affiche l'aide intégrée de l'outil.

Le mode léger de Perfetto : rapide et similaire à celui de Systrace

Le mode léger de Perfetto est conçu pour les tracés rapidestrès similaire à la façon dont il était utilisé historiquement systraceIl vous permet de sélectionner uniquement un sous-ensemble de base de sources : essentiellement atrace y ftraceet c'est utile en parallèle applications pour optimiser les performances.

Syntaxe typique en mode léger Ça ressemble à ça :

adb shell perfetto ... --out FILE

Parmi les options spécifiques les plus pertinentes du mode lumière nous avons trouvé:

• --time TIME o -t TIME: durée de l'enregistrement en secondes, minutes ou heures. Par exemple, --time 1m Capture d'une minute. Si aucune valeur n'est spécifiée, une durée de 10 secondes est utilisée par défaut.
• --buffer SIZE o -b SIZE: taille du tampon circulaire en mémoire. La valeur par défaut est généralement de l'ordre de --buffer 32mb.
• --size SIZE o -s SIZETaille maximale des fichiers sur le disque : si cette limite n’est pas configurée, Perfetto ne peut écrire que dans la mémoire tampon.
• --app o -a: nom du package de l'application Android à utiliser dans les annotations de atrace.

Ces drapeaux sont suivis des « spécificateurs d'événements ».qui déterminent les catégories ou événements qui seront enregistrés :

• ATRACE_CAT: catégories de atrace que vous souhaitez activer (par exemple, wm (pour WindowManager). Une commande typique serait : adb shell perfetto --out FILE wm.
• FTRACE_GROUP/FTRACE_NAME: événements spécifiques de ftraceComme sched/sched_switchVous pourriez courir : adb shell perfetto --out FILE sched/sched_switch.

Mode normal de Perfetto : contrôle maximal et plus de sources

Le mode normal de Perfetto est beaucoup plus puissant et configurable.Au lieu de transmettre des catégories individuelles, on vous fournit un fichier de configuration (un proto) qui décrit en détail quelles sources de données activer, comment échantillonner, quels tampons utiliser, etc.

Syntaxe habituelle pour le mode normal est la suivante:

adb shell perfetto --config CONFIG_FILE --out FILE

Les indicateurs spécifiques qui sont essentiels dans ce mode sont:

• --config CONFIG_FILE o -c CONFIG_FILE: chemin d'accès au fichier de configuration qui suit le schéma de trace_config.proto dans AOSP. Au sein de ce prototype, des éléments tels que TraceConfig y DataSourceConfig (défini dans data_source_config.proto) pour sélectionner et paramétrer les sources de données.
• --txt: indique que le fichier de configuration est au format texte pbtxt Au lieu du binaire. Très pratique pour le prototypage local, mais déconseillé comme format de production finale.

Sources de données compatibles Perfetto

La véritable force de Perfetto réside dans les diverses ressources qu'elle peut mobiliser.Chacun est configuré à partir du prototype via un bloc de DataSourceConfigEt selon l'appareil, la version d'Android et le noyau, vous aurez plus ou moins d'options disponibles.

Événements du noyau avec ftrace

La source ftrace Perfetto vous permet de capturer les événements internes du noyauce qui est une mine d'or lorsqu'on veut comprendre pourquoi un thread ne s'exécute pas à temps ou ce qui bloque le processeur à un instant donné.

Pour activer ftrace à partir des paramètres Le champ doit être défini. ftrace_config dans DataSourceConfig…en sélectionnant les événements spécifiques que nous souhaitons suivre. Voici quelques exemples courants liés à la planification des processus :

• sched/sched_switch
• sched/sched_wakeup
• sched/sched_wakeup_new
• sched/sched_process_exec
• sched/sched_process_exit
• sched/sched_process_fork
• sched/sched_process_free
• sched/sched_process_hang
• sched/sched_process_wait

Les événements du système de fichiers et les annotations de retour en arrière peuvent également être activés.Ainsi, une seule trace capture à la fois les données du noyau et les événements de niveau supérieur. La liste des événements réels dépend toujours du périphérique et de son noyau ; il est donc conseillé de consulter les protocoles de configuration pertinents.

Statistiques des processus et des systèmes

Une autre source très pratique est celle des statistiques de processus et du système lui-même.Il permet d'obtenir des compteurs périodiques d'utilisation des ressources, à la fois globalement et par processus individuel, idéal pour corréler les pics d'utilisation du processeur ou de la mémoire avec des événements de saccades spécifiques et avec applications d'arrière-plan.

Pour l'utiliser, vous devez configurer les champs. process_stats_config y sys_stats_config dans DataSourceConfigLes données obtenues comprennent, entre autres, des informations sur le temps processeur, l'utilisation de la mémoire et d'autres indicateurs qui peuvent varier en fonction de l'appareil et de la version du système d'exploitation.

Profils de mémoire natifs avec heapprofd

heapprofd C'est l'élément clé pour comprendre l'utilisation de la mémoire native. de vos services applicatifs ou système. Il fonctionne par échantillonnage, générant des profils qui indiquent quelles parties du code réservent de la mémoire.

Pour allumer heapprofd dans une trace de Perfetto Vous devez remplir la section heapprofd_config de DataSourceConfig. Le résultat est ProfilePackets avec les informations de la pile d'appels, y compris celles des frameworks Java lorsqu'elles sont disponibles. C'est un outil puissant pour détecter les fuites de mémoire natives ou les schémas d'allocation inefficaces.

Documentation publique dans perfetto.dev Il détaille comment configurer ces profils, filtrer par processus spécifiques, ajuster la fréquence d'échantillonnage, etc., vous permettant ainsi d'adapter le coût de l'instrumentation au niveau de détail dont vous avez besoin.

Autres sources de données supplémentaires

En plus de ce qui précède, d'autres sources sont disponibles en fonction de l'appareil et de la version d'Android.Certaines sont axées sur l'énergie, d'autres sur le réseau, et d'autres encore sur des indicateurs de performance plus spécifiques. Pour les examiner en détail, il convient de consulter les différents schémas de configuration des sources de données Perfetto publiés sur AOSP.

Dans tous les cas, le schéma se répète toujours.Vous choisissez la source, vous configurez son bloc DataSourceConfig dans le prototype de TraceConfig et vous lancez le traçage avec perfettoEnsuite, vous analysez le fichier résultant à l'aide des outils de visualisation.

dumpsys : le plugin idéal pour mesurer la latence et les performances

Bien que Perfetto soit la star pour les traces de bas niveaul'outil vétéran dumpsys Cela reste essentiel lorsque vous souhaitez des diagnostics de haut niveau, regroupés par service système : entrée, graphisme, réseau, batterie, mémoire, etc.

dumpsys Il fonctionne sur les appareils Android. et elle est invoquée depuis ADB avec des commandes comme adb shell dumpsysSi vous l'exécutez sans paramètres, il génère des informations provenant de tous les services système, ce qui est généralement excessif. Il est préférable de spécifier le service qui vous intéresse afin de vous concentrer uniquement sur cette partie.

Syntaxe générale de la commande dumpsys

La manière générique d'appeler dumpsys est la suivante:

adb shell dumpsys | -c | -h]

Quelques usages courants serait:

• adb shell dumpsys: annule tous les services (très verbeux).
• adb shell dumpsys input: état du système d'entrée (claviers, écrans tactiles, etc.).
• adb shell dumpsys -l: lister tous les services disponibles.

Parmi les principales options de ligne de commande comprennent:

• -t timeout: durée maximale en secondes accordée à dumpsys pour terminer l'opération (par défaut, 10 s).
• --help: aide générique sur les outils.
• -l: liste des services système.
• --skip services: indique un ou plusieurs services que vous souhaitez exclure du résultat lorsque vous n'en spécifiez aucun.
• service Spécifiez le service précis que vous souhaitez inspecter, avec des arguments facultatifs. En cas de doute, de nombreux services acceptent… -h pour montrer leur propre aide, par exemple adb shell dumpsys procstats -h.
• -c: permet à certains services de renvoyer des données dans un format plus adapté à la consommation par des scripts ou des outils.
• -hDans certains services, imprimez une aide supplémentaire spécifique.

Diagnostic des entrées : interactions tactiles, frappes au clavier et latences des événements

Pour les problèmes de latence liés à l'entrée tactile ou au clavierLe service clé est input. avec adb shell dumpsys input Vous obtenez un récapitulatif de l'état des périphériques d'entrée et du flux des événements depuis leur génération jusqu'à leur arrivée dans les fenêtres.

Le résultat comprend trois blocs logiques importants: l'état du centre d'événements, l'état de InputReader et l'état de InputDispatcherChacune d'elles vous aide à détecter les défauts dans une étape du déroulement de l'événement.

Centre d'événements : appareils disponibles et leur configuration

La section « État du hub d’événements » répertorie tous les périphériques d’entrée connus du système., avec des informations telles que le chemin d'accès au périphérique, la classe, les fichiers de disposition des touches, les caractères spéciaux et la configuration, ainsi que l'identifiant du clavier intégré (BuiltInKeyboardId).

Lors de la consultation de cette section, il est conseillé de vérifier:

• Que tous les dispositifs physiques attendus soient correctement répertoriés.
• Chaque touche possède son propre fichier de disposition des touches, sa propre table de caractères et son propre fichier de configuration ; si ces fichiers sont manquants ou contiennent des erreurs de syntaxe, ils ne se chargeront pas et l’expérience de saisie en sera affectée.
• Que le champ Classes avoir les bits appropriés, mappés à des constantes comme INPUT_DEVICE_CLASS_TOUCH_MT en EventHub.h.
• Que BuiltInKeyboardId mer -2 En l'absence de clavier intégré, ou si l'identifiant du clavier interne est incorrect, veuillez le vérifier. Si vous constatez que ce n'est pas le cas, veuillez le vérifier. -2 Et ça devrait l'être ; il manque probablement une table de caractères spéciaux pour un pavé de fonctions, qui ne devrait contenir que type SPECIAL_FUNCTION.

InputReader : Comment les événements d’entrée sont interprétés

InputReader Il est responsable de la « traduction » des événements de bas niveau du noyau à quelque chose que le framework peut comprendre : coordonnées tactiles, pression, taille du toucher, etc. Dans son fichier de vidage, vous verrez la configuration détaillée de chaque appareil (par exemple, un écran tactile spécifique) et les dernières actions effectuées.

Dans le cas des écrans tactiles, il est crucial de vérifier:

• Les plages X et Y (minimums, maximums, précision, tolérances).
• Les paramètres d'étalonnage (échelles de taille, pression, orientation, etc.).
• La taille de la surface (largeur et hauteur en pixels).
• Facteurs de translation et d'échelle, qui déterminent comment les coordonnées brutes sont mappées sur l'espace écran.

Les paramètres globaux sont également listés à la fin de cette section. comme l'intervalle de clic, les seuils de vitesse du pointeur ou les paramètres gestuels (durée du double clic, distance minimale, etc.), qui affectent directement la sensation de fluidité.

InputDispatcher : envoi d’événements aux fenêtres et à l’ANR

InputDispatcher Il gère l'envoi des événements entrants aux différentes fenêtresSon statut indique quelle fenêtre est au premier plan, lesquelles sont tactiles, l'état des files d'attente d'entrée et si une ANR (Application Not Responding) est en cours.

En pratique, cette section vous permet de vérifier:

• Quelle fenêtre recevait les coups au moment où le coup a été donné ? dumpsys.
• S’il existe des événements en attente ou des files d’attente bloquées susceptibles d’augmenter la latence perçue.
• Comment les connexions entrantes sont réparties entre les différentes fenêtres et si certaines saturent leur file d'attente.

Un contrôle simple mais très révélateur Il suffit d'effleurer l'écran pour le lancer immédiatement. adb shell dumpsys input et voir si la ligne de TouchStates Identifiez correctement la fenêtre que vous avez touchée. Sinon, il y a un problème avec la gestion du focus ou le mappage des zones tactiles.

Mesure des performances de l'interface utilisateur avec gfxinfo et framesstats

Lorsque le principal problème réside dans les saccades des animations et du défilement, le service gfxinfo C'est ton ami. À travers dumpsys gfxinfo Vous pouvez obtenir des données sur les images rendues pour une application spécifique.

La commande de base pour une application spécifique est la suivante:

adb shell dumpsys gfxinfo package-name

Si vous ajoutez l'option framestatsLe diagnostic devient encore plus détaillé :

adb shell dumpsys gfxinfo package-name framestats

Cela vous donnera des statistiques de latence image par image Ces données issues des animations récentes sont très utiles pour identifier les transitions ou les écrans où le temps de rendu connaît des pics. Ces informations peuvent ensuite être intégrées à des tests automatisés ou à des macrobenchmarks afin de détecter les régressions entre les versions de l'application.

Diagnostic réseau avec dumpsys netstats

Pour déterminer si la latence de l'interface utilisateur est liée à un réseau lent ou à des pics de trafic, le service netstats C'est très utile. Cela permet de collecter des statistiques d'utilisation du réseau dès la mise en marche de l'appareil.

La commande typique plus en détail est la suivante:

adb shell dumpsys netstats detail

Le départ est organisé en plusieurs sections.:

• Interfaces actives et interfaces UID actives, où les noms comme wlan0 et son identifiant réseau.
• Les statistiques « Dev » et « Xt » présentent des données historiques avec des intervalles de temps (par exemple, par incréments d'une heure) et des champs tels que les octets reçus (rb), colis reçus (rp), octets transmis (tb, Etc.)
• Statistiques par UID, permettant d'analyser la consommation réseau d'une application spécifique, en faisant la distinction entre mobile et Wi-Fi.

Pour trouver l'UID de votre applicationOn utilise quelque chose comme ceci :

adb shell dumpsys package your-package-name | grep userId

Une fois que vous connaissez la valeur de userId, vous pouvez regarder la sortie de netstats les lignes avec uid=ese_valor et voir, par exemple, combien d'octets et de paquets il a utilisés au cours de chaque période de deux heures, et s'il était au premier plan (set=DEFAULT) ou en arrière-plan (set=BACKGROUND).

Consommation de la batterie et d'énergie avec batterystats

La latence et les saccades ne sont pas seulement corrigées grâce à de meilleures performances.Il est parfois également utile d'examiner comment les optimisations affectent la consommation d'énergie. dumpsys batterystats Il fournit un rapport très complet sur l'utilisation de la batterie par UID et par composant.

La commande de base pour ce service est la suivante:

adb shell dumpsys batterystats options

Si vous souhaitez vous concentrer sur une application spécifique depuis la dernière mise en ligneIl est utilisé :

adb shell dumpsys batterystats --charged package-name

Le départ habituel comprend:

• Historique des événements liés à la batterie.
• Statistiques globales des appareils.
• Estimations de la consommation d'énergie par UID et par composants du système.
• Durée d'utilisation du réseau mobile par application et par forfait.
• Statistiques globales des UID système et application.

Format d'enregistrement (CSV) pour l'analyse automatisée

Si vous devez traiter des données de batterie à l'aide de scripts ou d'outils externesVous pouvez générer une sortie « compatible avec les machines » avec :

adb shell dumpsys batterystats --checkin

Ce format présente chaque observation sur une ligne CSV.avec un identifiant de section qui détermine comment interpréter les autres champs. Voici quelques exemples de sections :

• vers: versions d'enregistrement, de colis et de plateforme.
• uid: Relation entre l'UID et le nom du package.
• apk, pr, sr, vib, fgetc. : utilisation de processus, capteurs, vibrateur, temps de premier plan, synchronisations, tâches, etc.
• nt y gn: statistiques réseau (octets et paquets mobiles/Wi-Fi, temps de disponibilité, etc.).
• bt, dc, lvDonnées relatives à la batterie, telles que la durée, le niveau et la durée de décharge.
• wfl, gwfl, gble: informations spécifiques Wi-Fi et Bluetooth, y compris les durées et la consommation estimée en mAh.

Dans les versions récentes d'Android (6.0 et supérieures)La consommation énergétique du Wi-Fi, de la radio mobile et du Bluetooth est présentée comme un élément pwi avec des étiquettes dédiées (wifi, blue, cell), alors que dans les versions plus anciennes, il était regroupé dans la section m (recueil).

Inspection de la mémoire au fil du temps avec procstats

Si vous soupçonnez que les saccades proviennent de fuites de mémoire ou d'applications gourmandes en ressources exécutées en arrière-plan,, dumpsys procstats Elle vous permet de voir comment votre application se comporte au fil du temps : combien de temps elle a été active, dans quel état et avec quelle consommation de mémoire.

L'utilisation typique consiste à demander des statistiques sur les dernières heures., par exemple:

adb shell dumpsys procstats --hours 3

Le résultat est résumé pour chaque application. Le pourcentage de temps d'exécution du processus, ainsi que les valeurs PSS, USS et RSS (minimum, moyenne et maximum) et le nombre d'échantillons prélevés, sont indiqués. Un résumé de la mémoire est également fourni par type de processus (noyau, natif, persistant, processus les plus utilisés, services, processus en cache, etc.).

Cette vue agrégée permet de détecter les tendances Les applications qui restent trop longtemps en arrière-plan ou qui maintiennent un PSS moyen ou maximal très élevé sont des candidates potentielles à l'optimisation, voire peuvent provoquer une pression sur la mémoire qui dégrade les performances du système.

Instantané détaillé de la mémoire avec meminfo

Lorsque vous avez besoin d'un aperçu très précis de l'utilisation de la mémoire d'un processus spécifiqueL'outil est dumpsys meminfoGrâce à lui, vous pouvez voir comment la RAM est répartie entre les tas natifs, Dalvik/ART, les cartes de code, les tampons graphiques, etc.

La syntaxe de base est:

adb shell dumpsys meminfo package_name|pid

Le choix -d Plus d'informations pour Dalvik/ARTmontrant des détails internes tels que l'espace pour les objets volumineux (.LOS), surcharge du GC, cache JIT, espace zygote, etc. Avec -h Vous pouvez voir tous les drapeaux disponibles.

Les colonnes clés à observer sont généralement Pss Total y Private DirtyCes chiffres reflètent respectivement l'utilisation de la RAM ajustée par le partage et la quantité de mémoire privée modifiée qui ne sera libérée qu'à la fin du processus. Ils peuvent parfois présenter un intérêt. Private Clean y Heap AllocSi vous détectez une consommation anormale, vérifiez comment libérer de la RAM pour les atténuer.

Quelques catégories pertinentes dans le tableau:

• Native Heap y Dalvik Heap: utilisation de la mémoire native et de la mémoire du tas de la machine virtuelle. Heap Alloc Cela indique ce que les allocateurs considèrent comme réservé, ce qui peut être supérieur à la PSS en raison de l'effet Zygote et de la mémoire partagée.
• .so mmap, .dex mmap, .oat mmap y .art mmap: RAM utilisée par le code natif et le bytecode, y compris les images ART et leurs espaces partagés.
• .Heap, .LOS, .GC, .JITCache, .Zygote, .NonMoving, .IndirectRef (Avec -d): détailler plus en détail l'utilisation interne de la mémoire gérée par ART.
• Unknown: pages qui n'ont pas pu être classées dans les catégories précédentes, souvent des affectations natives visualisées via ASLR.

La ligne TOTAL regroupe le total PSS du processusqui peut être comparé au PSS d'autres processus et à la RAM disponible. Private Dirty + Private Clean Elles indiquent la mémoire qui sera libérée lorsque le processus sera arrêté.

De plus, les compteurs d'objets de haut niveau sont répertoriés à la fin du rapport. comme un certain nombre de ViewRootImpl, AppContexts o ActivitiesCela permet de détecter les fuites typiques de contextes ou d'activités conservées par des références statiques ou par des vues/éléments graphiques qui continuent de les référencer.

Il est bon de s'en souvenir un View ou Drawable Ils conservent également des références à Activity d'où elles proviennent, un stockage inadéquat peut donc entraîner des fuites concernant toute l'activité et les ressources associées.

Combiner les traces détaillées de Perfetto avec les diagnostics de dumpsys L'outil d'analyse des entrées, des graphismes, de la mémoire, du réseau et de la batterie offre une vue à 360 degrés du comportement d'une application Android : de la planification d'un thread au temps de rendu d'une image (en millisecondes), en passant par la consommation de mémoire et d'énergie. L'utilisation régulière de ces outils lors du développement et des tests fait toute la différence entre une application « à peu près fonctionnelle » et une application véritablement fluide, stable et performante, même sur des appareils modestes. optimiser Android.