Porównywanie profili podstawowych za pomocą biblioteki Macrobenchmark

Zalecamy użycie Jetpack Macrobenchmark do przetestowania działania aplikacji z włączonymi profilami Baseline, a następnie porównanie tych wyników z testem porównawczym z wyłączonymi profilami Baseline. 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 wygenerowane klatki mogą powodować zacinanie się.

Testy Macrobenchmark umożliwiają kontrolowanie kompilacji przed pomiarem za pomocą interfejsu API CompilationMode. Użyj różnych wartości CompilationMode, aby porównać wydajność w różnych stanach kompilacji. Poniższy fragment kodu pokazuje, jak używać parametru CompilationMode do pomiaru korzyści z profili Baseline:

@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()
        }
    ) {
        uiAutomator {
            startApp(packageName)
            onElement(5_000) { viewIdResourceName == "my-content"}
        }
    }
}

Uwaga: aby zmierzyć rzeczywistą wydajność, uruchom testy porównawcze na urządzeniu fizycznym. Pomiar wydajności w emulatorze Androida prawdopodobnie da nieprawidłowe wyniki, ponieważ zasoby są współdzielone z maszyną hostującą.

Na zrzucie ekranu poniżej widać wyniki bezpośrednio w Android Studio dla przykładowej aplikacji Now in Android uruchomionej na Google Pixel 7. Wyniki pokazują, że uruchamianie aplikacji jest najszybsze, gdy używane są profile Baseline (229,0 ms), w porównaniu z brakiem kompilacji (324,8 ms).

Rysunek 1. Wyniki ColdStartupBenchmark pokazujące czas do początkowego wyświetlenia bez kompilacji (324 ms), z pełną kompilacją (315 ms), z częściową kompilacją (312 ms) i z profilami podstawowymi (229 ms).

Wskazówka: wyniki możesz też pobrać jako plik JSON, aby przeanalizować je w ramach potoku CI. Więcej informacji znajdziesz w artykule Analiza porównawcza w CI.

Poprzedni przykład pokazuje wyniki uruchamiania aplikacji zarejestrowane za pomocą StartupTimingMetric, ale warto wziąć pod uwagę inne ważne dane, takie jak FrameTimingMetric. Więcej informacji o wszystkich typach danych znajdziesz w artykule Przechwytywanie danych makrotestu porównawczego.

Czas do pełnego wyświetlenia

Poprzedni przykład mierzy 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 aplikacji. Dane dotyczące czasu do pełnego wyświetlenia (TTFD) są bardziej przydatne do mierzenia i optymalizowania ścieżek kodu niezbędnych do uzyskania w pełni użytecznego stanu aplikacji.

Zalecamy optymalizację pod kątem obu tych wskaźników, ponieważ oba są ważne. Niski TTID pomaga użytkownikowi zobaczyć, że aplikacja faktycznie się uruchamia. Krótki czas TTFD jest ważny, ponieważ pozwala użytkownikowi szybko wejść w interakcję z aplikacją.

Strategie raportowania, gdy interfejs aplikacji jest w pełni wyrenderowany, znajdziesz w artykule Poprawianie dokładności czasu uruchamiania.