La bibliothèque Jetpack Microbenchmark vous permet de comparer votre code natif Android (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. Cela peut également expliquer pourquoi les opérations sont lentes en montrant ce qui se passe pendant l'exécution, par exemple une exécution sur un thread à faible priorité, la veille en raison d'un accès au disque ou l'appel inattendu dans une fonction coûteuse, comme le 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/traitements 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.
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 aide à garantir 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. Vous pouvez l'appliquer avec une tâche Gradle (gradlew lockClocks) ou manuellement dans l'intégration continue. Bien qu'il s'agisse du 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 de choisir 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 Android 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 vous n'utilisez pas le verrouillage de l'horloge ni les performances soutenues, 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. Lorsqu'elle détecte une baisse des performances du processeur, la bibliothèque suspend l'exécution pour laisser l'appareil refroidir, puis retente l'analyse comparative actuelle.
Exemples
Consultez les exemples suivants dans le dépôt GitHub :
Ressources supplémentaires
Envoyer des commentaires
Pour signaler des problèmes ou soumettre des demandes de fonctionnalités lors de l'analyse comparative, consultez l'outil public Issue Tracker.
Recommandations personnalisées
- Remarque : Le texte du lien s'affiche lorsque JavaScript est désactivé
- Effectuer une analyse comparative de votre application
- Créer des profils de référence {:#creating-profile-rules}
- Bibliothèque JankStats