Benchmark-Referenzprofile mit der MacroBenchmark-Bibliothek

Wir empfehlen, mit Jetpack Macrobenchmark zu testen, wie sich eine App verhält, wenn Baseline-Profile aktiviert sind, und diese Ergebnisse dann mit einem Benchmark zu vergleichen, bei dem Baseline-Profile deaktiviert sind. Mit diesem Ansatz können Sie die App-Startzeit (sowohl die Zeit bis zur ersten als auch zur vollständigen Anzeige) oder die Rendering-Leistung zur Laufzeit messen, um festzustellen, ob die gerenderten Frames Ruckeln verursachen können.

Mit Makrobenchmarks können Sie die Kompilierung vor der Messung mit der CompilationMode API steuern. Verwenden Sie unterschiedliche CompilationMode-Werte, um die Leistung bei verschiedenen Kompilierungsstatus zu vergleichen. Das folgende Code-Snippet zeigt, wie Sie den Parameter CompilationMode verwenden, um den Nutzen von Baseline-Profilen zu 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)
    }
}

Im folgenden Screenshot sehen Sie die Ergebnisse direkt in Android Studio für die Now in Android-Beispiel-App, die auf einem Google Pixel 7 ausgeführt wurde. Die Ergebnisse zeigen, dass der App-Start am schnellsten ist, wenn Baseline Profiles verwendet werden (229,0 ms), im Gegensatz zu keiner Kompilierung (324,8 ms).

Im vorherigen Beispiel werden App-Start-Ergebnisse mit StartupTimingMetric erfasst. Es gibt jedoch auch andere wichtige Messwerte, die berücksichtigt werden sollten, z. B. FrameTimingMetric. Weitere Informationen zu allen Arten von Messwerten finden Sie unter Macrobenchmark-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 den ersten Frame zu rendern. Dies spiegelt jedoch nicht unbedingt die Zeit wider, 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 vollständig nutzbaren App-Status erforderlich sind.

Wir empfehlen, sowohl TTID als auch TTFD zu optimieren, da beide wichtig sind. Ein niedriger TTID-Wert hilft dem Nutzer zu erkennen, dass die App tatsächlich gestartet wird. Es ist wichtig, die TTFD kurz zu halten, damit Nutzer schnell mit der App interagieren können.

Strategien zum Melden, wenn die App-Benutzeroberfläche vollständig gerendert wurde, finden Sie unter Genauigkeit des Startzeitpunkts verbessern.