Benchmark-Referenzprofile mit der MacroBenchmark-Bibliothek

Wir empfehlen, mit Jetpack Macrobenchmark die Leistung einer App zu testen, 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 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 Vorab-Kompilierung mithilfe der CompilationMode API steuern. Verwenden Sie unterschiedliche CompilationMode-Werte, um die Leistung bei verschiedenen Kompilierungsstatus zu vergleichen. Im folgenden Code-Snippet wird gezeigt, 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)
    }
}

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 das App-Starten mit Baseline-Profilen (229,0 ms) am schnellsten ist, im Vergleich dazu dauert es ohne Kompilierung 324,8 ms.

Ergebnisse von ColdstartupBenchmark
Abbildung 1: Ergebnisse von ColdStartupBenchmark mit der Zeit bis zur ersten Anzeige bei keiner Kompilierung (324 ms), vollständiger Kompilierung (315 ms), teilweiser Kompilierung (312 ms) und Baseline-Profilen (229 ms).

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 Nutzern 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 dargestellt ist, finden Sie unter Genauigkeit des Startzeitpunkts verbessern.

  • Hinweis: Der Linktext wird angezeigt, wenn JavaScript deaktiviert ist.
  • [Write a Macrobenchmark][11]
  • [Makrobenchmark-Messwerte erfassen][12]
  • [Analyse und Optimierung des App-Starts {:#app-startup-analysis-optimization}][13]