Benchmark-Referenzprofile mit der MacroBenchmark-Bibliothek

Wir empfehlen, Jetpack MacroBenchmark zu verwenden, um die Leistung einer Anwendung zu testen, wenn Baseline-Profile aktiviert sind, und diese Ergebnisse dann mit einer Benchmark zu vergleichen, in der Baseline-Profile deaktiviert sind. Mit diesem Ansatz können Sie die Startzeit der App – sowohl die Zeit bis zur ersten als auch die vollständige Anzeige – oder die Laufzeit-Rendering-Leistung messen, um festzustellen, ob die erzeugten Frames Verzögerungen verursachen können.

Mit Makro-Benchmarks können Sie die Kompilierung vor der Messung mithilfe der CompilationMode API steuern. Verwenden Sie verschiedene CompilationMode-Werte, um die Leistung mit verschiedenen Kompilierungsstatus zu vergleichen. Das folgende Code-Snippet zeigt, wie Sie mit dem Parameter CompilationMode den Nutzen von Baseline-Profilen messen:

@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)
    }
}

Achtung :Führen Sie die Benchmarks auf einem physischen Gerät aus, um die Leistung in der Praxis zu messen. Die Leistungsmessung mit einem Android-Emulator führt wahrscheinlich zu falschen Ergebnissen, da Ressourcen mit dem Hostcomputer geteilt werden.

Im folgenden Screenshot sehen Sie die Ergebnisse für die Now in Android-Beispiel-App, die auf Google Pixel 7 ausgeführt wurde, direkt in Android Studio. Die Ergebnisse zeigen, dass die Anwendung mit Baseline-Profilen (229.0ms) am schnellsten gestartet wird, im Gegensatz zu keiner Kompilierung (324.8ms).

Abbildung 1. Ergebnisse von ColdStartupBenchmark, die die Zeit bis zur ersten Anzeige für keine Kompilierung (324 ms), vollständige Kompilierung (315 ms), Teilkompilierung (312 ms) und Referenzprofile (229 ms) anzeigen.

Tipp: Sie können die Ergebnisse auch als JSON-Datei abrufen, um sie als Teil Ihrer CI-Pipeline zu parsen. Weitere Informationen finden Sie unter Benchmarking in CI.

Das vorherige Beispiel zeigt die mit StartupTimingMetric erfassten Ergebnisse beim Start einer Anwendung. Es gibt aber auch andere wichtige Messwerte, die Sie sich ansehen sollten, z. B. FrameTimingMetric. Weitere Informationen zu allen Arten von Messwerten finden Sie unter MakroBenchmark-Messwerte erfassen.

Zeit bis zur vollständigen Anzeige

Im vorherigen Beispiel wird die Zeit bis zur ersten Anzeige (Time to initial display, TTID) gemessen, also die Zeit, die die App benötigt, um ihren ersten Frame zu erstellen. Dies entspricht jedoch nicht unbedingt der Zeit, bis der Nutzer mit Ihrer App interagieren kann. Der Messwert Time to Full Display (TTFD) ist nützlicher, um die Codepfade zu messen und zu optimieren, die für einen vollständig nutzbaren App-Status erforderlich sind.

Wir empfehlen, sowohl für TTID als auch für TTFD zu optimieren, da beide wichtig sind. Eine niedrige TTID zeigt dem Nutzer, dass die Anwendung tatsächlich gestartet wird. Ein möglichst kurzes TTFD-Element ist wichtig, damit der Nutzer schnell mit der App interagieren kann.

Strategien zur Berichterstellung für eine vollständig gezeichnete Anwendungs-UI finden Sie unter Genauigkeit des Startzeitpunkts verbessern.