Profiler un microbenchmark

Par défaut, les microbenchmarks vous fournissent des informations sur la temporalité et les allocations du code exécuté. Si vous souhaitez savoir pourquoi le code mesuré est lent, inspectez la trace de méthode (capturée par défaut sur les versions d'OS compatibles) ou sélectionnez d'autres configurations de profilage.

Pour sélectionner la configuration du profileur, ajoutez l'argument d'exécuteur d'instrumentation androidx.benchmark.profiling.mode avec un argument MethodTracing (par défaut), StackSampling ou None, comme illustré dans l'extrait suivant.

Pour en savoir plus sur ces options, consultez Enregistrer des méthodes Java/Kotlin. MethodTracing est l'équivalent du traçage, tandis que StackSampling est l'équivalent de l'échantillonnage, comme défini dans ce document.

Groovy

android {
    defaultConfig {
        // must be one of: 'None', 'StackSampling', or 'MethodTracing'
        testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"]= 'StackSampling'
    }
}

Kotlin

android {
    defaultConfig {
        // must be one of: 'None', 'StackSampling', or 'MethodTracing'
        testInstrumentationRunnerArguments["androidx.benchmark.profiling.mode"] = "StackSampling"
    }
}

Lorsque vous profilez un benchmark, un fichier .trace de sortie est copié sur l'hôte dans le répertoire avec les résultats JSON. Pour inspecter les résultats du profilage dans Android Studio, sélectionnez le lien Trace de méthode ou Trace d'échantillonnage de pile dans les résultats du microbenchmark.

Remarque : La bibliothèque Microbenchmark capture automatiquement le traçage système, mais en désactivant les sections de traçage personnalisé (les appels à Trace.beginSection and endSection sont ignorés) pour éviter toute interférence due à une surcharge de traçage.

MethodTracing

Le traçage de méthode est utile lorsque vous essayez d'optimiser votre code, car il peut vous aider à identifier les méthodes dont l'exécution prend plus de temps que les autres. Vous pouvez ensuite vous concentrer sur l'optimisation des méthodes qui ont le plus d'impact sur les performances.

Le profilage se produit après la mesure du code. Votre test génère donc des résultats précis sur le plan de la temporalité et du profilage.

Le traçage des méthodes est activé par défaut.

Remarque:Sur certaines versions d'Android OS et d'ART, le traçage des méthodes est désactivé par défaut. Dans ce cas, Android Studio génère un avertissement.

Échantillonnage de pile (StackSampling)

Le traçage d'échantillon peut également permettre d'identifier des méthodes coûteuses sans ralentir les performances du traçage de méthode. Toutefois, si votre application saisit une méthode après la capture d'une pile d'appel et quitte la méthode avant la capture suivante, l'appel de méthode n'est pas consigné. Pour suivre correctement les méthodes avec des cycles de vie courts, utilisez le traçage de méthode au lieu du traçage d'échantillon.

Avec l'échantillonnage de pile, les échantillons de benchmark appellent des piles une fois la préparation terminée. Vous pouvez contrôler le comportement d'échantillonnage, comme la fréquence d'échantillonnage et la durée d'échantillonnage, à l'aide d'arguments d'instrumentation.

Sur Android 10 (API 29) ou version ultérieure, l'échantillonnage de pile utilise Simpleperf pour échantillonner les piles d'appels d'application, y compris le code C++. Sous Android 9 (API 28) et versions antérieures, il utilise Debug.startMethodTracingSampling pour capturer des échantillons de pile.

Vous pouvez configurer ce mode de profilage en ajoutant d'autres arguments d'instrumentation :

• androidx.benchmark.profiling.sampleFrequency

  • Nombre d'échantillons de pile à capturer par seconde
  • Type d'argument : entier
  • La valeur par défaut est de 1 000 échantillons par seconde.

• androidx.benchmark.profiling.sampleDurationSeconds

  • Durée d'exécution du benchmark.
  • Type d'argument : entier
  • La valeur par défaut est de 5 secondes.

• androidx.benchmark.profiling.skipWhenDurationRisksAnr

  • Ignore le traçage de la méthode lorsqu'il est susceptible de provoquer une erreur ANR. Vous devez laisser cette option activée pour les exécutions de CI, car les erreurs ANR peuvent entraîner des problèmes lors de longues exécutions de CI.
  • Type d'argument: booléen
  • La valeur par défaut est true.

Aucune

Cet argument ne capture pas de fichier de profilage. Les informations sur la temporalité et les allocations sont toujours mesurées.