Guides pratiques

Guide de progression pour améliorer vos performances

Temps de lecture : 9 min
Alice Yuan
Ingénieur chargé des relations avec les développeurs

Guide de progression pour votre parcours sur les performances

Bienvenue au quatrième jour de la semaine consacrée aux performances. Maintenant que vous avez découvert certains des outils et des bonnes pratiques que nous avons récemment introduits, comme l'optimiseur R8 et l'optimisation guidée par le profil avec les profils de référence et les profils de démarrage, vous vous demandez peut-être par où commencer pour améliorer les performances. 

Nous avons élaboré un guide de classification des performances étape par étape pour répondre aux besoins de votre équipe de développement mobile, que vous soyez un développeur d'applications qui souhaite se lancer dans l'amélioration des performances ou que vous disposiez d'une équipe entière dédiée à l'amélioration des performances Android. 

Le guide de nivellement des performances comporte cinq niveaux. Nous commencerons par le niveau 1, qui présente des outils de performances nécessitant un effort d'adoption minimal, et nous passerons au niveau 5, idéal pour les applications qui disposent des ressources nécessaires pour maintenir un framework de performances sur mesure.

 
N'hésitez pas à passer directement au niveau qui vous intéresse le plus :

Niveau 1 : Utilisez la surveillance des champs fournie par la Play Console

Nous vous recommandons d'abord d'utiliser Android Vitals dans la Play Console pour afficher les données de surveillance des champs collectées automatiquement. Vous obtiendrez ainsi des informations sur votre application avec un minimum d'efforts.

Android Vitals est une initiative de Google visant à collecter et à afficher automatiquement les données de ce champ pour vous.

Voici une explication de la façon dont nous fournissons ces données :

  1. Collecte de données  : lorsqu'un utilisateur active cette option, son appareil Android enregistre automatiquement les événements clés liés aux performances et à la stabilité de toutes les applications, y compris la vôtre.
  2. Données agrégées : Google Play collecte et anonymise ces données auprès des utilisateurs de votre application.
  3. Insights sur les surfaces : les données sont présentées dans le tableau de bord Android Vitals de votre Google Play Console.

Le tableau de bord Android Vitals suit de nombreuses métriques, mais certaines sont désignées comme Core Vitals. Elles sont les plus importantes, car elles peuvent avoir une incidence sur la visibilité et le classement de votre application sur le Google Play Store.

Statistiques principales

PRINCIPALES MÉTRIQUES DE QUALITÉ TECHNIQUE DE GOOGLE PLAY

Pour maximiser la visibilité de votre application sur Google Play, veillez à ce qu'elle ne dépasse pas les seuils de comportement insatisfaisant pour ces métriques.

Taux de plantages repérés par l'utilisateurPourcentage d'utilisateurs actifs par jour ayant subi au moins un plantage probablement perceptible
Taux d'erreurs ANR repérées par l'utilisateurPourcentage d'utilisateurs actifs par jour ayant subi au moins une ANR susceptible d'avoir été remarquée
Utilisation excessive de la batteriePourcentage de sessions avec le cadran au cours desquelles l'utilisation de la batterie dépasse 4,44 % par heure
Nouveau : Trop de wakelocks partielsPourcentage de sessions utilisateur où l'utilisation cumulée de wakelocks non exemptés dépasse deux heures.

Les statistiques principales incluent le taux de plantages perçus par l'utilisateur, le taux d'erreurs ANR, l'utilisation excessive de la batterie et la nouvelle métrique sur les wakelocks partiels excessifs.

Taux d'erreurs ANR perçues par l'utilisateur

Vous pouvez utiliser le tableau de bord Android Vitals pour les erreurs ANR afin de consulter les traces de pile des problèmes qui se produisent sur le terrain, et obtenir des insights et des recommandations sur la façon de les résoudre. 

crashesAnrs.png

Vous pouvez examiner une ANR spécifique qui s'est produite pour afficher la trace de la pile, ainsi que des informations sur la cause possible du problème.

insights.png

Consultez également nos conseils sur les ANR pour vous aider à diagnostiquer et à résoudre les scénarios courants dans lesquels des ANR peuvent se produire. 

Taux de plantages perçus par l'utilisateur

Utilisez le tableau de bord des plantages Android Vitals pour déboguer plus en détail les plantages et afficher un échantillon des traces de pile qui se produisent dans votre application. 

Notre documentation fournit également des conseils pour résoudre les problèmes de plantage spécifiques. Par exemple, le guide de dépannage des services de premier plan explique comment identifier et résoudre les scénarios courants où des plantages se produisent.

Utilisation excessive de la batterie 

Pour réduire les sessions de cadran avec une utilisation excessive de la batterie sur Wear OS, consultez le guide Wear sur l'amélioration et la préservation de la batterie. 

[Nouveau] Wakelocks partiels excessifs

 

Nous avons récemment annoncé que les applications qui dépassent le seuil de wakelocks partiels excessifs pourraient faire l'objet d'un traitement supplémentaire à partir du 1er mars 2026. 

Pour les appareils mobiles, la métrique Android Vitals s'applique aux wakelocks non exemptés acquis lorsque l'écran est éteint et que l'application est en arrière-plan ou exécute un service de premier plan. Android Vitals considère que l'utilisation de wakelocks partiels est excessive si les wakelocks sont maintenus pendant au moins deux heures sur une période de 24 heures et que cela affecte plus de 5 % des sessions de votre application, en moyenne sur 28 jours.

Pour déboguer et résoudre les problèmes de verrouillage de réveil excessif, consultez notre article de blog technique.

Consultez notre documentation Android Vitals et continuez à mieux exploiter Android Vitals.

Niveau 2 : Suivez les tâches liées au score de performances de l'application.

Ensuite, utilisez le score de performances de l'application pour identifier les actions à fort impact qui vous permettront d'améliorer les performances de votre application.

Le score de performances des applications Android est un framework standardisé permettant de mesurer les performances techniques de votre application. Il vous attribue un score entre 0 et 100. Plus le score est bas, plus vous avez de marge de progression.

Pour obtenir des résultats rapides, commencez par le score de performances statiques. Il s'agit souvent de modifications de configuration ou de mises à jour d'outils qui améliorent considérablement les performances.

Étape 1 : Effectuer l'évaluation statique

L'évaluation statique évalue la configuration de votre projet et l'adoption des outils. Il s'agit souvent des moyens les plus rapides d'améliorer les performances.

Accédez à la section "Score statique" de la page du tableau de score, puis procédez comme suit :

  1. Évaluez la version du plug-in Android Gradle (AGP).
  2. Adoptez la minification R8 de manière progressive ou, idéalement, utilisez R8 en mode complet pour minifier et optimiser le code de l'application.
  3. Adoptez les profils de référence, qui améliorent la vitesse d'exécution du code dès le premier lancement et offrent des performances améliorées pour chaque nouvelle installation et chaque mise à jour de l'application.
  4. Adoptez les profils de démarrage pour améliorer la mise en page Dex. Les profils de démarrage sont utilisés par le système de compilation pour optimiser davantage les classes et les méthodes qu'ils contiennent en améliorant la mise en page du code dans les fichiers DEX de votre APK.
  5. Passer à la dernière version de Jetpack Compose

Étape 2 : Effectuer l'évaluation dynamique

Une fois les gains faciles statiques appliqués, utilisez l'évaluation dynamique pour valider les améliorations sur un appareil réel. Vous pouvez d'abord le faire manuellement avec un appareil physique et un chronomètre.

Accédez à la section Score dynamique de la page du tableau de score, puis procédez comme suit :

  1. Configurez votre environnement de test avec un appareil physique. Envisagez d'utiliser un appareil bas de gamme pour exagérer les problèmes de performances et les repérer plus facilement.
  2. Mesurez le temps de démarrage à partir du lanceur d'applications. Démarrez à froid votre application à partir de l'icône du lanceur d'applications et mesurez le temps nécessaire pour qu'elle devienne interactive.
  3. Mesurez le temps de démarrage de l'application à partir d'une notification. L'objectif est de réduire ce temps à quelques secondes.
  4. Mesurez les performances d'affichage en faisant défiler vos écrans et animations principaux.

Une fois ces étapes terminées, vous recevrez un score entre 1 et 100 pour les scores statiques et dynamiques. Vous pourrez ainsi comprendre les performances de votre application et savoir sur quoi vous concentrer.

Niveau 3 : Exploiter les frameworks de test des performances locales

Une fois que vous avez commencé à évaluer les performances dynamiques, vous pouvez trouver trop fastidieux de les mesurer manuellement. Envisagez d'automatiser vos tests de performances à l'aide de frameworks de test de performances tels que Macrobenchmarks et UiAutomator.

Macrobenchmark 💚 UiAutomator

Considérez Macrobenchmark et UiAutomator comme deux outils qui fonctionnent ensemble : Macrobenchmark est l'outil de mesure. Il s'agit d'un chronomètre et d'un compteur de fréquence d'images qui s'exécutent en dehors de votre application. Il est responsable du démarrage de votre application, de l'enregistrement des métriques (comme le temps de démarrage ou les images perdues) et de l'arrêt de l'application. UiAutomator est l'utilisateur robot. La bibliothèque vous permet d'écrire du code pour interagir avec l'écran de l'appareil. Il peut trouver une icône, appuyer sur un bouton,  faire défiler une liste et plus encore.

Écrire un test

Lorsque vous écrivez un test, vous encapsulez votre code UiAutomator dans un bloc Macrobenchmark.

  1. Définir le test : utilisez @MacrobenchmarkRule.
  2. Commencez à mesurer : appelez benchmarkRule.measureRepeated.
  3. Pilotez l'UI : dans ce bloc, utilisez le code UiAutomator pour lancer votre application, trouver des éléments d'UI et interagir avec eux.

Voici un exemple d'extrait de code qui montre comment tester une liste Compose pour détecter les saccades de défilement.

  benchmarkRule.measureRepeated(

    // ...

    metrics = listOf(

        FrameTimingMetric(),

    ),

    startupMode = StartupMode.COLD,

    iterations = 10,

) {

    // 1. Launch the app's main activity

    startApp()

    // 2. Find the list using its resource ID and scroll down

    onElement { viewIdResourceName == "$packageName.my_list" }

        .fling(Direction.DOWN)

}

4. Examiner les résultats : chaque série de tests fournit des informations mesurées avec précision pour vous donner les meilleures données sur les performances de votre application.

  timeToInitialDisplayMs  min  1894.4,   median 2847.4,   max  3355.6


frameOverrunMs          P50 -3.2,  P90  6.2, P95  10.4, P99  119.5

Cas d'utilisation courants

Macrobenchmark fournit plusieurs métriques de base prêtes à l'emploi. StartupTimingMetric vous permet de mesurer précisément le démarrage de l'application. FrameTimingMetric vous permet de comprendre les performances d'affichage d'une application pendant le test.

Nous avons créé un guide complet et détaillé sur l'utilisation des Macrobenchmarks et d'UiAutomator, ainsi que des exemples de code pour vous aider à continuer votre apprentissage.

Niveau 4 : Utilisez des outils d'analyse de trace comme Perfetto 

Les outils d'analyse de trace tels que Perfetto sont utilisés lorsque vous avez besoin d'aller au-delà de votre propre code d'application. Contrairement aux débogueurs ou profileurs standards qui ne voient que votre processus, Perfetto capture l'état complet de l'appareil (planification du noyau, fréquence du processeur, autres processus et services système), ce qui vous donne un contexte complet pour les problèmes de performances.

Consultez notre playlist YouTube sur le débogage des performances pour obtenir des instructions vidéo sur le débogage des performances à l'aide des traces système, du Profileur Android Studio et de Perfetto.

Utiliser Perfetto pour déboguer les performances

Le workflow général pour déboguer les performances à l'aide d'outils d'analyse des traces consiste à enregistrer, charger et analyser la trace. 

Étape 1 : Enregistrez une trace

Vous pouvez enregistrer une trace système de plusieurs manières : 

Étape 2 : Charger la trace

Une fois que vous avez le fichier de trace, vous devez le charger dans l'outil d'analyse.

  1. Ouvrez Chrome et accédez à ui.perfetto.dev.
  2. Glissez-déposez votre fichier .perfetto-trace (ou .pftrace) directement dans la fenêtre du navigateur.
  3. L'interface utilisateur traite le fichier et affiche la timeline.

Étape 3 : Analysez la trace

Vous pouvez utiliser l'interface utilisateur Perfetto ou le Profileur Android Studio pour examiner les problèmes de performances. Découvrez cet épisode de la série MAD Skills sur les performances, dans lequel notre ingénieure en performances Carmen Jackson présente Perfetto Traceviewer.

Scénarios d'inspection des traces système à l'aide de Perfetto

Perfetto est un outil expert qui peut fournir des informations sur tout ce qui s'est passé sur l'appareil Android pendant la capture d'une trace. Cela est particulièrement utile lorsque vous ne parvenez pas à identifier la cause racine d'un ralentissement à l'aide des journaux standards ou des profileurs de base.

Déboguer les saccades (images perdues)

Si votre application saccade lors du défilement, Perfetto peut vous indiquer précisément pourquoi un frame spécifique n'a pas respecté son délai.

Si le problème est dû à l'application, vous pouvez voir votre thread principal s'exécuter pendant une longue durée en effectuant une analyse lourde. Cela indique les scénarios dans lesquels vous devez déplacer le travail vers un traitement asynchrone.

Si le problème est dû au système, il est possible que votre thread principal soit prêt à s'exécuter, mais que le planificateur de noyau du processeur ait donné la priorité à un autre service système, ce qui laisse votre application en attente (concurrence du processeur). Cela indique les scénarios dans lesquels vous devrez peut-être optimiser l'utilisation des API de la plate-forme.

Analyser le démarrage lent d'une application

Le démarrage est complexe, car il implique l'initialisation du système, la duplication de processus et le chargement de ressources. Perfetto visualise cette chronologie avec précision.

Vous pouvez voir si vous êtes en attente d'appels Binder (communication inter-processus). Si votre onCreate attend longtemps une réponse du système PackageManager, Perfetto affichera clairement cet état bloqué. 

Vous pouvez également vérifier si votre application effectue plus de travail que nécessaire au démarrage. Par exemple, si vous créez et disposez plus de vues que l'application n'a besoin d'afficher, vous pouvez voir ces opérations dans la trace.

Examiner la décharge de la batterie et l'utilisation du processeur

Comme Perfetto voit l'ensemble du système, il est idéal pour trouver les pertes d'énergie invisibles.

Vous pouvez identifier les processus qui maintiennent des wakelocks, empêchant l'appareil de se mettre en veille, dans les pistes "État de l'appareil". Pour en savoir plus, consultez notre article de blog sur les wake locks. Utilisez également Perfetto pour vérifier si vos tâches en arrière-plan s'exécutent trop souvent ou réveillent le processeur inutilement.

Niveau 5 : Créez votre propre framework de suivi des performances

Le dernier niveau est destiné aux applications dont les équipes disposent des ressources nécessaires pour maintenir un framework de suivi des performances. 

Pour créer un framework de suivi des performances personnalisé sur Android, vous devez exploiter plusieurs API système afin de capturer des données tout au long du cycle de vie de l'application, du démarrage à la fermeture, et lors de scénarios spécifiques à forte charge.

En utilisant ApplicationStartInfo, ProfilingManager et ApplicationExitInfo, vous pouvez créer un système de télémétrie robuste qui fournit des informations sur le démarrage de votre application, des informations détaillées sur ce qu'elle a fait pendant son exécution et la raison de son arrêt.

ApplicationStartInfo : suivi du démarrage de l'application

Disponible à partir d'Android 15 (API 35), ApplicationStartInfo fournit des métriques détaillées sur le démarrage des applications sur le terrain. Les données indiquent s'il s'agissait d'un démarrage à froid, tiède ou à chaud, ainsi que la durée des différentes phases de démarrage. 

Cela vous aide à développer une métrique de démarrage de référence à l'aide de données de production pour optimiser davantage ce qui peut être difficile à reproduire localement. Vous pouvez utiliser ces métriques pour effectuer des tests A/B afin d'optimiser le flux de démarrage.

L'objectif est d'enregistrer précisément les métriques de lancement sans instrumenter manuellement chaque phase d'initialisation.

Vous pouvez interroger ces données de manière différée quelque temps après le lancement de l'application.

ProfilingManager : capture de la raison de la lenteur

ProfilingManager (API 35) permet à votre application de déclencher par programmation des traces système sur les appareils des utilisateurs. Cela permet de détecter les problèmes de performances temporaires que vous ne pouvez pas reproduire en local.

L'objectif est d'enregistrer automatiquement une trace lorsqu'un parcours utilisateur spécifique et très critique est détecté comme s'exécutant lentement ou rencontrant des problèmes de performances.

Vous pouvez enregistrer un écouteur qui se déclenche lorsque des conditions spécifiques sont remplies ou le déclencher manuellement lorsque vous détectez un problème de performances tel qu'un à-coup, une mémoire excessive ou une décharge de la batterie.

Consultez notre documentation sur la capture d'un profil, la récupération et l'analyse des données de profilage, et l'utilisation des commandes de débogage.

ApplicationExitInfo : suivi de la raison pour laquelle l'application s'est arrêtée

ApplicationExitInfo (API 30) vous indique pourquoi votre processus précédent s'est arrêté. Cela est essentiel pour trouver les plantages natifs, les erreurs ANR ou les arrêts système dus à une utilisation excessive de la mémoire (OOM). Vous pourrez également obtenir une trace détaillée de la tombe en utilisant l'API getTraceInputStream.

L'objectif de l'API est de comprendre les problèmes de stabilité qui ne déclenchent pas les rapports d'erreur Java standards (comme les erreurs de mémoire insuffisante).

Vous devez déclencher cette API lors du prochain lancement de l'application.

Étapes suivantes

L'amélioration des performances d'Android est un processus progressif. Nous avons hâte de voir comment vous allez améliorer vos performances grâce à ces outils !

Ne manquez pas Ask Android demain

Vous avez réduit la taille de votre application avec R8 et optimisé votre environnement d'exécution avec l'optimisation guidée par le profil. Mesurez les performances de votre application.

Rejoignez-nous demain pour la session en direct "Ask Android". Posez vos questions dès maintenant avec le hashtag #AskAndroid et obtenez des réponses d'experts.

Écrit par :

Lire la suite