Configura l'ambiente per i test delle prestazioni
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Puoi identificare potenziali colli di bottiglia e migliorare le prestazioni complessive dell'app registrando l'attività del dispositivo in un breve periodo di tempo e raccogliendo tracce del periodo di avvio dell'app. Questa pagina mostra come configurare l'ambiente per i test delle prestazioni.
Utilizzare la libreria Macrobenchmark
La libreria di Macrobenchmark misura le interazioni più ampie degli utenti finali, ad esempio l'avvio, l'interazione con l'interfaccia utente e le animazioni. La libreria fornisce il controllo diretto
sull'ambiente delle prestazioni che stai testando. Ti consente di controllare la compilazione, l'avvio e l'interruzione dell'app per misurare direttamente il tempo di avvio preciso dell'app. Funziona anche per ridurre al minimo il rumore
e le differenze tra le esecuzioni di test.
Utilizzare dispositivi di fascia media per identificare potenziali problemi di prestazioni
Testa le prestazioni su ogni tipo di dispositivo che ti interessa. I dispositivi di fascia alta con componenti rapidi possono nascondere problemi di prestazioni su dispositivi meno recenti, più lenti o con poca RAM.
I dispositivi di fascia inferiore possono richiedere più tempo per caricare i dati o eseguire il codice, semplificando l'identificazione dei colli di bottiglia. In genere, l'ottimizzazione delle prestazioni per i dispositivi di fascia bassa porta anche l'ottimizzazione per i dispositivi di fascia alta.
Riduci il rumore
- Rete: testa app o processi con velocità Wi-Fi internet elevate e stabili. Se il tempo di avvio dell'app include una richiesta di rete, indicalo come un luogo in cui potrebbe verificarsi una certa variabilità.
- Utilizzo della RAM: non avere altre app in esecuzione in background sul dispositivo durante il test delle prestazioni all'avvio dell'app.
- Batteria: assicurati che il dispositivo sia carico per evitare limitazioni delle prestazioni a bassa potenza specifiche dell'hardware.
Testa le build di release
Usa le build di release per testare le prestazioni. Le build di debug sono non adatte per il debug delle prestazioni, in quanto non offrono ottimizzazione della compilazione e non influiscono significativamente sulle prestazioni.
Tuttavia, puoi utilizzare una build di release non offuscata per identificare classi e nomi delle operazioni. Nello specifico, consigliamo di abilitare minify
(R8) e disabilitare l'offuscamento, con
-dontobfuscate
nel file ProGuard.
È più facile identificare layout, asset e risorse se la build non è offuscata.
Assicurati di includere il flag profileable nel manifest in modo che i tuoi eventi personalizzati siano visibili nelle build non di cui è possibile eseguire il debug. Questo flag è disponibile su Android 10 (livello API 29) e versioni successive.
Aggiungi tracce personalizzate alle operazioni dell'app
Aggiungi tracce personalizzate all'interno dell'app per identificare più facilmente quali operazioni vengono eseguite dalla tua app rispetto ad altre librerie. In questo modo puoi avere più contesto su ciò che l'app sta facendo in ogni momento.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]