Porównywanie profili podstawowych za pomocą biblioteki Macrobenchmark

Zalecamy korzystanie z Jetpack Macrobenchmark do przetestowania wydajności aplikacji, gdy włączone są profile podstawowe, a następnie porównanie tych wyników z wynikami testu porównawczego 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.

Testy porównawcze pozwalają kontrolować kompilację danych przed pomiarem za pomocą interfejsu API CompilationMode. Używaj różnych wartości CompilationMode, aby porównać wydajność z różnymi stanami 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 przedstawia wyniki dotyczące uruchamiania aplikacji rejestrowane za pomocą narzędzia StartupTimingMetric, ale istnieją 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

Poprzedni przykład mierzy czas do początkowego wyświetlenia (TTID), czyli czas potrzebny aplikacji do wygenerowania 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. Niższa wartość TTID pomaga użytkownikowi zobaczyć, że aplikacja faktycznie jest uruchamiana. Krótki czas trwania TTFD jest ważny, aby użytkownik mógł szybko wejść w interakcję z aplikacją.

Strategie raportowania, gdy interfejs aplikacji jest w pełni widoczny, znajdziesz w artykule Zwiększanie dokładności 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]
Wstecz
Skonfiguruj generowanie profilu podstawowego