Analyse comparative des profils de référence avec la bibliothèque Macrobenchmark

Nous vous recommandons d'utiliser Jetpack Macrobenchmark pour tester les performances d'une appli lorsque les profils de référence sont activés, puis de comparer ces résultats à une analyse comparative avec les profils de références désactivés. Cette approche vous permet de mesurer le temps de démarrage de l'appli (temps d'affichage initial et complet) ou les performances d'affichage de l'environnement d'exécution pour déterminer si les images produites peuvent provoquer des à-coups.

Les bibliothèques Macrobenchmark vous permettent de contrôler la compilation avant mesure via l'API CompilationMode. Utilisez différentes valeurs CompilationMode pour comparer les performances avec différents états de compilation. L'extrait de code suivant montre comment utiliser le paramètre CompilationMode pour mesurer les avantages des profils de référence :

@RunWith(AndroidJUnit4ClassRunner::class)
class ColdStartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    // No ahead-of-time (AOT) compilation at all. Represents performance of a
    // fresh install on a user's device if you don't enable Baseline Profiles—
    // generally the worst case performance.
    @Test
    fun startupNoCompilation() = startup(CompilationMode.None())

    // Partial pre-compilation with Baseline Profiles. Represents performance of
    // a fresh install on a user's device.
    @Test
    fun startupPartialWithBaselineProfiles() =
        startup(CompilationMode.Partial(baselineProfileMode = BaselineProfileMode.Require))

    // Partial pre-compilation with some just-in-time (JIT) compilation.
    // Represents performance after some app usage.
    @Test
    fun startupPartialCompilation() = startup(
        CompilationMode.Partial(
            baselineProfileMode = BaselineProfileMode.Disable,
            warmupIteration = 3
        )
    )

    // Full pre-compilation. Generally not representative of real user
    // experience, but can yield more stable performance metrics by removing
    // noise from JIT compilation within benchmark runs.
    @Test
    fun startupFullCompilation() = startup(CompilationMode.Full())

    private fun startup(compilationMode: CompilationMode) = benchmarkRule.measureRepeated(
        packageName = "com.example.macrobenchmark.target",
        metrics = listOf(StartupTimingMetric()),
        compilationMode = compilationMode,
        iterations = 10,
        startupMode = StartupMode.COLD,
        setupBlock = {
            pressHome()
        }
    ) {
        // Waits for the first rendered frame, which represents time to initial display.
        startActivityAndWait()

        // Waits for content to be visible, which represents time to fully drawn.
        device.wait(Until.hasObject(By.res("my-content")), 5_000)
    }
}

Sur la capture d'écran suivante, vous pouvez consulter les résultats directement dans Android Studio pour l'application exemple Now in Android exécutée sur le Google Pixel 7. Les résultats montrent que le démarrage de l'appli est plus rapide lors de l'utilisation de profils de référence (229,0 ms) en comparaison avec aucune compilation (324,8 ms).

Bien que l'exemple précédent affiche des résultats de démarrage d'appli capturés avec StartupTimingMetric, il existe d'autres métriques importantes que vous pouvez prendre en compte, comme FrameTimingMetric. Pour en savoir plus sur tous les types de métriques, consultez Capturer les métriques Macrobenchmark.

Délai d'affichage total

L'exemple précédent mesure le délai d'affichage initial (TTID), qui correspond au temps nécessaire à l'appli pour générer son premier frame. Toutefois, cette valeur ne reflète pas nécessairement combien de temps l'utilisateur doit patienter pour pouvoir commencer à interagir avec votre appli. La métrique Délai d'affichage total (TTFD) est plus utile pour mesurer et optimiser les chemins de code nécessaires afin de fournir une appli entièrement fonctionnelle.

Nous vous recommandons d'optimiser à la fois le TTID et le TTFD, car ils sont tous les deux importants. Un TTID faible permet à l'utilisateur de voir que l'appli se lance. Il est important de limiter le TTFD pour que l'utilisateur puisse interagir rapidement avec l'appli.

Pour connaître les stratégies de reporting une fois que l'interface utilisateur de l'appli est entièrement dessinée, consultez Améliorer la précision du temps de démarrage.