Porównywanie profili podstawowych za pomocą biblioteki Macrobenchmark

Zalecamy użycie testu makrobenchmarku Jetpacka do sprawdzenia wydajności aplikacji przy włączonych profilach podstawowych, a następnie porównanie tych wyników z testem z wyłączonymi profilami podstawowymi. Dzięki temu możesz mierzyć czas uruchamiania aplikacji (zarówno czas do początkowego, jak i pełnego wyświetlenia) lub wydajność renderowania w czasie działania, aby sprawdzić, czy generowane klatki mogą powodować zacięcia.

Makrobenchmarky umożliwiają kontrolowanie kompilacji przed pomiarem za pomocą interfejsu API CompilationMode. Używaj różnych wartości CompilationMode, aby porównywać wydajność w różnych stanach kompilacji. Ten fragment kodu pokazuje, jak za pomocą parametru CompilationMode mierzyć korzyści z profili referencyjnych:

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

Na poniższym zrzucie ekranu możesz zobaczyć wyniki bezpośrednio w Android Studio dotyczące aplikacji Now in Android sample uruchomionej na Google Pixel 7. Wyniki pokazują, że uruchomienie aplikacji jest najszybsze przy użyciu profili referencyjnych (229,0 ms) w porównaniu z brakiem kompilacji (324,8 ms).

Wyniki testu ColdstartupBenchmark
Rysunek 1. Wyniki ColdStartupBenchmark pokazujące czas do wyświetlenia w przypadku braku kompilacji (324 ms), pełnej kompilacji (315 ms), częściowej kompilacji (312 ms) i profili bazowych (229 ms).
.

Poprzedni przykład pokazuje wyniki uruchamiania aplikacji uzyskane za pomocą StartupTimingMetric, ale istnieją też inne ważne dane, które warto wziąć pod uwagę, np. FrameTimingMetric. Więcej informacji o wszystkich typach danych znajdziesz w artykule [GA4] Pomiar danych Macrobenchmark.

Czas do pełnego wyświetlenia

W poprzednim przykładzie zmierzono czas do początkowego wyświetlenia (TTID), czyli czas potrzebny aplikacji na wygenerowanie pierwszej klatki. Nie oznacza to jednak, że użytkownik może od razu zacząć korzystać z aplikacji. Dane Czas do pełnego wyświetlenia są bardziej przydatne do pomiaru i optymalizacji ścieżek kodu niezbędnych do pełnego użycia aplikacji.

Zalecamy optymalizację pod kątem TTID i TTFD, ponieważ obie te wartości są ważne. Niski identyfikator TTID pomaga użytkownikowi sprawdzić, czy aplikacja się uruchamia. Krótki czas trwania TTFD jest ważny, aby użytkownik mógł szybko wejść w interakcję z aplikacją.

Aby dowiedzieć się, jak tworzyć raporty, gdy interfejs użytkownika aplikacji jest w pełni narysowany, zapoznaj się z artykułem Poprawianie dokładności pomiaru czasu uruchamiania.

  • Uwaga: tekst linku jest wyświetlany, gdy obsługa JavaScript jest wyłączona
  • [Write a Macrobenchmark][11]
  • [Pomiar danych Macrobenchmark][12]
  • [Analiza i optymalizacja czasu uruchamiania aplikacji {:#app-startup-analysis-optimization}][13]