La bibliothèque Jetpack Microbenchmark vous permet de comparer rapidement votre code Android natif (Kotlin ou Java) à partir d'Android Studio. Elle gère la préparation, mesure les performances du code et le nombre d'allocations, et génère des résultats d'analyse comparative dans la console Android Studio ainsi que dans un fichier JSON détaillé.
Nous vous recommandons de profiler votre code avant d'écrire une analyse comparative. Cela vous permet d'identifier les opérations coûteuses qui valent la peine d'être optimisées. Cette approche peut également expliquer pourquoi les opérations sont lentes en montrant ce qu'il se passe pendant leur exécution : elles peuvent s'exécuter sur un thread à faible priorité, être mises en veille en raison de l'accès au disque ou appeler de manière inattendue une fonction coûteuse, telle qu'un décodage bitmap.
Les microbenchmarks sont particulièrement utiles pour les opérations de processeur exécutées dans votre application, aussi appelées chemins de code à chaud. Par exemple : le défilement RecyclerView avec un élément affiché à la fois, les conversions/traitement de données et d'autres éléments de code qui sont utilisés de façon répétée.
D'autres types de code sont plus difficiles à mesurer avec la bibliothèque Microbenchmark. Étant donné que les benchmarks s'exécutent en boucle, tout code qui n'est pas souvent exécuté ou qui fonctionne différemment lorsqu'il est appelé plusieurs fois peut ne pas convenir à l'analyse comparative.
Pour apprendre à utiliser la bibliothèque dans un environnement d'intégration continue (CI), consultez Exécuter des benchmarks dans une intégration continue.
Éviter de mesurer le cache
Tâchez de ne pas mesurer seulement le cache. Par exemple, il est possible que le benchmark de la mise en page d'une vue personnalisée ne mesure que les performances du cache de mise en page. Pour éviter cela, vous pouvez transmettre différents paramètres de mise en page dans chaque boucle. Dans d'autres cas, par exemple lors de la mesure des performances du système de fichiers, cela peut s'avérer difficile, car l'OS met en cache le système de fichiers dans une boucle.
Code peu exécuté
Le code qui s'exécute une fois au démarrage de l'application est peu susceptible de faire l'objet d'une compilation JIT par Android Runtime (ART). Pour cette raison, l'analyse comparative de ce code avec Microbenchmark, où il s'exécute en boucle étroite, n'est pas un moyen réaliste de mesurer ses performances.
Pour analyser ce type de code, nous vous recommandons d'utiliser Jetpack Macrobenchmark, qui permet de mesurer les interactions utilisateur de niveau supérieur telles que le lancement de l'application et les performances de défilement.
Obtenir des benchmarks cohérents
Sur les appareils mobiles, les horloges passent d'un état élevé (pour les performances) à un état faible (pour économiser de l'énergie ou lorsque l'équipement devient chaud). Ces différentes horloges peuvent faire varier vos chiffres de benchmark. La bibliothèque fournit donc des solutions pour résoudre ce problème.
Verrouillage des horloges (requiert un appareil en mode root)
Le verrouillage des horloges constitue le meilleur moyen d'obtenir des performances stables. Cette méthode garantit que les horloges ne seront jamais suffisamment élevées pour chauffer l'appareil, ou trop basses lorsqu'un benchmark n'utilise pas complètement le processeur. Le verrouillage s'applique automatiquement lors de l'exécution de microbenchmarks avec Gradle, ou manuellement dans l'intégration continue. Bien que ce soit le meilleur moyen de garantir des performances stables, cette approche n'est pas prise en charge par la plupart des appareils, car elle nécessite un appareil Android en mode root.
Mode Performances soutenues
Window.setSustainedPerformanceMode() est une fonctionnalité compatible avec les appareils qui permettent à une application d'opter pour une fréquence de processeur maximale inférieure. Lorsqu'elle s'exécute sur des appareils compatibles, la bibliothèque Microbenchmark utilise une combinaison de cette API et lance sa propre activité pour empêcher la limitation thermique ainsi que pour stabiliser les résultats.
Cette fonctionnalité est activée par défaut par le testInstrumentationRunner défini par le plug-in Gradle. Si vous souhaitez utiliser un exécuteur personnalisé, vous pouvez sous-classer l'AndroidBenchmarkRunner et l'utiliser comme testInstrumentationRunner.
L'exécuteur lance une activité opaque en plein écran pour s'assurer que le benchmark s'exécute au premier plan et sans aucun autre dessin d'application.
Mise en veille automatique de l'exécution
Si ni le verrouillage de l'horloge, ni les performances soutenues ne sont utilisés, la bibliothèque effectue une détection automatique de la limitation thermique. Lorsque cette option est activée, le benchmark interne s'exécute régulièrement pour déterminer à quel moment la température de l'appareil est suffisamment élevée pour réduire les performances du processeur. Lorsque des performances de processeur réduites sont détectées, la bibliothèque suspend l'exécution pour laisser l'appareil refroidir et effectue une nouvelle tentative du benchmark actuel.
Exemples
Ressources supplémentaires
Envoyer un commentaire
Pour signaler des problèmes ou soumettre des demandes de fonctionnalités lors de l'analyse comparative, consultez l'outil public Issue Tracker.