Porównywanie profili podstawowych za pomocą biblioteki Macrobenchmark

Zalecamy użycie narzędzia Jetpack Macrobenchmark do przetestowania wydajności aplikacji, gdy włączone są profile podstawowe, a następnie porównaj uzyskane wyniki ze testem porównawczym z wyłączonymi profilami bazowymi. Dzięki temu możesz mierzyć czas uruchamiania aplikacji – zarówno do początkowego, jak i pełnego wyświetlenia – lub wydajności renderowania w czasie działania, aby sprawdzić, czy utworzone klatki mogą powodować zacinanie.

Makroporównania pozwalają kontrolować kompilację wstępnych pomiarów 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 używać parametru CompilationMode do pomiaru korzyści z profili podstawowych:

@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 zrzucie ekranu poniżej możesz zobaczyć wyniki bezpośrednio w Android Studio dla aplikacji Now in Android sample (Próbka aplikacji Now in Android) uruchomionej na telefonie Google Pixel 7. Wyniki pokazują, że uruchamianie aplikacji odbywa się najszybciej przy korzystaniu z profili podstawowych (229,0 ms), a przy tym bez kompilacji (324,8 ms).

wyniki testu ColdstartupBenchmark
Rysunek 1. Wyniki działania ColdStartupBenchmark pokazujące czas do początkowego 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 rejestrowane za pomocą StartupTimingMetric, ale są też inne ważne dane, które warto wziąć pod uwagę, np. FrameTimingMetric. Więcej informacji o wszystkich typach danych znajdziesz w artykule Rejestrowanie danych analizy porównawczej.

Czas do pełnego wyświetlenia

W poprzednim przykładzie mierzymy czas do początkowego wyświetlenia (TTID), czyli czas potrzebny aplikacji na wygenerowanie pierwszej klatki. Nie musi to jednak odzwierciedlać czasu, po którym użytkownik może zacząć korzystać z Twojej aplikacji. Wskaźnik czasu do pełnego wyświetlenia (TTFD) jest bardziej przydatny przy pomiarze i optymalizacji ścieżek kodu niezbędnych do uzyskania pełnego wykorzystania stanu aplikacji.

Zalecamy optymalizację pod kątem TTID i TFD, ponieważ obie te wartości są ważne. Niski identyfikator TTID pozwala użytkownikowi zobaczyć, że aplikacja rzeczywiście się uruchamia. Krótkie zastosowanie TTFD ma istotne znaczenie dla umożliwienia użytkownikowi szybkiej interakcji z aplikacją.

Strategie dotyczące raportowania, gdy interfejs aplikacji jest w pełni wyświetlony, znajdziesz w artykule Zwiększanie dokładności czasu uruchamiania.

  • Uwaga: tekst linku jest wyświetlany, gdy JavaScript jest wyłączony
  • [Tworzenie makroporównania][11]
  • [Przechwytywanie danych analizy porównawczej [makroporównawczych]][12]
  • [Analiza i optymalizacja uruchamiania aplikacji {:#app-startup-analysis-Optimization}][13]
Wstecz
Skonfiguruj generowanie profilu podstawowego