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.

Makroanalizy porównawcze pozwalają kontrolować kompilację przed pomiarem za pomocą CompilationMode API. Używaj różnych wartości CompilationMode, aby porównywać wydajność w różnych stanach kompilacji. Poniżej znajduje się fragment kodu, Jak używać parametru CompilationMode do pomiaru korzyści ze stosowania punktu odniesienia Profile:

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

Uwaga: aby zmierzyć rzeczywistą wydajność, uruchom testy porównawcze na fizycznym urządzeniu. Pomiar wydajności za pomocą emulatora Androida prawdopodobnie zapewnia nieprawidłowe wyniki, ponieważ zasoby są udostępniane maszynie hostującej ten serwer.

Na poniższym zrzucie ekranu widać wyniki bezpośrednio w Android Studio w przypadku przykładowej aplikacji Now na Androidzie, która została uruchomiona na telefonie Google Pixel 7. wyniki pokazują, że uruchamianie aplikacji najszybciej przebiega w przypadku korzystania z profili podstawowych (229,0 ms) w przeciwieństwie do braku kompilacji (324,8 ms).

Rysunek 1. Wyniki: ColdStartupBenchmark czas do początkowego wyświetlenia bez kompilacji (324 ms), pełna kompilacja (315 ms), kompilacja częściowa (312 ms) i profile podstawowe (229ms).

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 uzyskane za pomocą StartupTimingMetric, ale istnieją też inne ważne dane, które warto wziąć pod uwagę, np. FrameTimingMetric. Aby uzyskać więcej informacji na temat wszystkich typów przeczytaj artykuł Rejestrowanie danych makroporównania.

Czas do pełnego wyświetlenia

Poprzedni przykład mierzy czas do początkowego wyświetlenia (TTID), który wynosi czas potrzebny aplikacji na utworzenie pierwszej klatki; Nie oznacza to jednak, musi odzwierciedlać czas, do którego użytkownik może zacząć korzystać z aplikacji. Dane czas do pełnego wyświetlenia (TTFD) są bardziej przydatne do mierzenia optymalizować ścieżki kodu niezbędne do osiągnięcia w pełni możliwego stanu aplikacji.

Zalecamy optymalizację zarówno pod kątem TTID, jak i TTFD, ponieważ obie te informacje 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.