Benchmark-Referenzprofile mit der MacroBenchmark-Bibliothek

Wir empfehlen, Jetpack MacroBenchmark zu verwenden, um die Leistung einer Anwendung zu testen, wenn Referenzprofile aktiviert sind, und diese Ergebnisse dann mit einer Benchmark zu vergleichen, in der Baseline-Profile deaktiviert sind. Mit diesem Ansatz können Sie die App-Startzeit messen – sowohl die Zeit bis zum ersten als auch bis zum vollständigen Display – oder die Laufzeit-Rendering-Leistung, um festzustellen, ob die generierten Frames zu Rucklern führen können.

Mit Makrobenchmarks können Sie die Vorabkompilierung mithilfe der 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 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 tatsächliche Leistung 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 direkt in Android Studio für die App Now in Android sample (Jetzt in Android-Beispiel), die auf Google Pixel 7 ausgeführt wurde. 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.

Im vorherigen Beispiel sind Ergebnisse zum App-Start zu sehen, die mit StartupTimingMetric erfasst wurden. Es gibt aber noch weitere wichtige Messwerte, die Sie berücksichtigen sollten, z. B. FrameTimingMetric. Weitere Informationen zu allen Messwerttypen finden Sie unter Makrobenchmark-Messwerte erfassen.

Zeit bis zur vollständigen Anzeige

Im vorherigen Beispiel wird die Zeit bis zur ersten Anzeige (TTID) gemessen. Das ist die Zeit, die die App benötigt, um den ersten Frame zu generieren. 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. 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 zur Berichterstellung für eine vollständig gezeichnete Anwendungs-UI finden Sie unter Genauigkeit des Startzeitpunkts verbessern.