Porównywanie profili podstawowych za pomocą biblioteki Macrobenchmark

Zalecamy użycie testu porównawczego Jetpacka do sprawdzenia wydajności aplikacji przy włączonych profilach podstawowych, a następnie porównanie tych wyników z testem porównawczym 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. Aby porównać wydajność przy różnych stanach kompilacji, użyj różnych wartości CompilationMode. 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ą funkcji 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 Zapisywanie 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 zarówno TTID, jak i TTFD, ponieważ obie te wartości są ważne. Niski identyfikator TTID pomaga użytkownikowi sprawdzić, czy aplikacja się uruchamia. Krótki komunikat TTFD jest ważny, ponieważ pozwala użytkownikowi szybko wejść w interakcję z aplikacją.

Strategie raportowania, gdy interfejs użytkownika aplikacji jest w pełni narysowany, znajdziesz w artykule 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]