Configurer votre environnement pour tester les performances
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous pouvez identifier les goulots d'étranglement potentiels et améliorer les performances globales de l'application en enregistrant l'activité de l'appareil sur une courte période et en collectant des traces de la période de démarrage de votre application. Cette page explique comment configurer votre environnement pour tester les performances.
Utiliser la bibliothèque Macrobenchmark
La bibliothèque Macrobenchmark mesure des interactions plus larges d'utilisateurs finaux, telles que le démarrage, l'interaction avec l'interface utilisateur et les animations. La bibliothèque fournit un contrôle direct sur l'environnement de performances que vous testez. Cela vous permet de contrôler la compilation, le démarrage et l'arrêt de votre application pour mesurer directement son temps de démarrage précis. Mais aussi de minimiser le bruit et les différences entre les exécutions de test.
Identifier les éventuels problèmes de performances à l'aide d'appareils de milieu de gamme
Testez les performances sur chaque type d'appareil qui vous intéresse. Les appareils haut de gamme dotés de composants rapides peuvent masquer les problèmes de performances sur les appareils plus anciens, plus lents ou ayant une capacité de RAM plus faible.
Les appareils d'entrée de gamme peuvent mettre plus de temps à charger des données ou à exécuter du code, ce qui facilite l'identification des goulots d'étranglement. L'optimisation des performances pour les appareils d'entrée de gamme est généralement aussi bénéfique pour les appareils haut de gamme.
Réduire le bruit
- Réseau : testez vos applications (ou processus) avec un débit Wi-Fi élevé et stable. Si le temps de démarrage de l'application inclut une requête réseau, notez qu'une variabilité peut apparaître à ce niveau.
- Utilisation de la RAM : aucune autre application ne doit s'exécuter en arrière-plan sur votre appareil lorsque vous testez les performances de démarrage de l'application.
- Batterie : assurez-vous que votre appareil est chargé pour éviter toute limitation des performances due à une faible charge spécifique au matériel.
Effectuer des tests sur les builds
Utilisez des builds pour tester les performances. Les versions de débogage ne sont pas adaptées au débogage des performances, car elles ne permettent pas d'optimiser la compilation et ont un impact significatif sur les performances.
Toutefois, vous pouvez utiliser une build non obscurcie pour identifier les classes et les noms d'opérations. Plus précisément, nous vous recommandons d'activer minify (R8) et de désactiver l'obscurcissement, avec -dontobfuscate dans le fichier ProGuard.
Il est plus facile d'identifier les mises en page, les composants et les ressources si la compilation n'est pas obscurcie.
Assurez-vous d'inclure l'indicateur profileable dans le fichier manifeste afin que vos événements personnalisés soient visibles dans les compilations non débogables. Cet indicateur est disponible sur Android 10 (niveau d'API 29) ou version ultérieure.
Ajouter des traces personnalisées aux opérations de votre application
Ajoutez des traces personnalisées dans votre application pour faciliter l'identification des opérations qu'elle effectue par rapport aux autres bibliothèques. Vous bénéficiez ainsi de plus de contexte sur les opérations effectuées à tout moment par l'application.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Set up your environment for performance testing\n\nYou can identify potential bottlenecks and improve overall app performance by\nrecording device activity over a short period of time and [collecting traces of\nyour app's startup period](/topic/performance/tracing). This page shows how to\nset up your environment for performance testing.\n\nUse the Macrobenchmark library\n------------------------------\n\nThe [Macrobenchmark\nlibrary](/topic/performance/benchmarking/macrobenchmark-overview) measures\nlarger end-user interactions, such as startup, interacting with the UI, and\nanimations. The library provides direct control over the performance environment\nyou're testing. It lets you control compiling, starting, and stopping your app\nto directly measure precise app startup time. It also works to minimize the\nnoise and differences between test runs.\n\nUse mid-range devices to identify potential performance issues\n--------------------------------------------------------------\n\nTest performance on each device type you care about. High-end devices with fast\ncomponents can hide performance problems on earlier, slower, or low RAM devices.\nLower-end devices can take longer to load data or run code, making it easier to\nidentify bottlenecks. Optimizing performance for low-end devices usually also\nbenefits optimization for high-end devices.\n\nReduce noise\n------------\n\n- Network: test your apps or processes with strong and stable internet Wi-Fi speeds. If the app startup time includes a network request, note this as a place where variability might occur.\n- RAM usage: don't have any other apps running in the background of your device while testing app startup performance.\n- Battery: ensure your device is charged to avoid any hardware-specific low power performance throttling.\n\nTest on release builds\n----------------------\n\nUse release builds to test performance. Debug builds are [unsuitable for\nperformance\ndebugging](/studio/profile/measuring-performance#apk-considerations), as they\ndon't provide compilation optimization and significantly impact performance.\n\nHowever, it's okay to use an unobfuscated release build to identify classes and\noperation names. Specifically, we recommend enabling [minify\n(R8)](/studio/build/shrink-code) and disabling obfuscation, with\n[`-dontobfuscate`](/studio/build/shrink-code#obfuscate) in the proguard file.\nIt's easier to identify layouts, assets, and resources if the build is\nunobfuscated.\n\nMake sure you include the\n[profileable](/guide/topics/manifest/profileable-element) flag in the manifest\nso that your custom events are visible in non-debuggable builds. This flag is\navailable on Android 10 (API level 29) and later.\n\nAdd custom traces to your app operations\n----------------------------------------\n\nAdd [custom traces](/topic/performance/tracing/custom-events) within your app to\nmake it easier to identify what operations are performed by your app compared to\nother libraries. This helps give you more context about what the app is doing at\nall times."]]
