Benchmark-Referenzprofile mit der MacroBenchmark-Bibliothek

Wir empfehlen, mit Jetpack MacroBenchmark die Leistung einer Anwendung zu testen, wenn Baseline-Profile aktiviert sind. Anschließend können Sie diese Ergebnisse mit einer Benchmark vergleichen, bei der Baseline-Profile deaktiviert sind. Mit diesem Ansatz können Sie die Startzeit der Anwendung – sowohl die Zeit bis zur ersten als auch die vollständigen Anzeige – messen oder die Leistung des Laufzeit-Renderings messen, um festzustellen, ob die erzeugten Frames eine Verzögerung verursachen können.

Mit Makro-Benchmarks können Sie die Kompilierung vor der Messung über die CompilationMode API steuern. Verwenden Sie unterschiedliche CompilationMode-Werte, um die Leistung bei verschiedenen Kompilierungsstatus zu vergleichen. Das folgende Code-Snippet zeigt, wie Sie mit dem Parameter CompilationMode die Vorteile 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 in einem Android-Emulator liefert wahrscheinlich falsche Ergebnisse, da Ressourcen für den Hostingcomputer freigegeben werden.

Im folgenden Screenshot siehst du die Ergebnisse für die Beispiel-App „Now in Android“, die auf Google Pixel 7 ausgeführt wurde, direkt in Android Studio. Die Ergebnisse zeigen, dass der Anwendungsstart bei Verwendung von Referenzprofilen (229.0ms) am schnellsten ist, im Gegensatz zu 324.8ms ohne Kompilierung.

Abbildung 1: Ergebnisse von ColdStartupBenchmark mit der Zeit bis zur ersten Anzeige für keine Kompilierung (324 ms), vollständig kompiliert (315 ms), teilweise Kompilierung (312 ms) und Referenzprofile (229 ms).

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

Das vorherige Beispiel zeigt Ergebnisse für den Anwendungsstart, die mit StartupTimingMetric erfasst wurden. Es gibt aber noch weitere wichtige Messwerte, z. B. FrameTimingMetric. Weitere Informationen zu allen Messwerttypen finden Sie unter Makro-Benchmark-Messwerte erfassen.

Zeit bis zur vollständigen Anzeige

Im vorherigen Beispiel wird die Zeit bis zur ersten Anzeige (Time to Initial Display, TTID) gemessen. Dies ist die Zeit, die die App benötigt, um den ersten Frame zu erstellen. Allerdings muss hier nicht unbedingt die Zeit berücksichtigt werden, bis der Nutzer mit Ihrer App interagieren kann. Der Messwert Zeit bis zur vollständigen Anzeige (Time to Full Display, TTFD) ist nützlicher, um die Codepfade zu messen und zu optimieren, die für einen voll nutzbaren App-Status erforderlich sind.

Wir empfehlen eine Optimierung sowohl für TTID als auch für TTFD, da beide wichtig sind. Eine niedrige TTID zeigt dem Nutzer, dass die App tatsächlich gestartet wird. Die TTFD-Datei sollte kurz gehalten werden, damit Nutzer schnell mit der Anwendung interagieren können.

Strategien für die Berichterstellung, wenn die App-UI vollständig gezeichnet ist, finden Sie unter Genauigkeit beim Startzeitpunkt verbessern.