Базовые профили тестирования с помощью библиотеки Macrobenchmark

Мы рекомендуем использовать Jetpack Macrobenchmark, чтобы проверить производительность приложения при включенных базовых профилях, а затем сравнить эти результаты с тестом с отключенными базовыми профилями. С помощью этого подхода вы можете измерить время запуска приложения — как время до начального, так и полного отображения — или производительность рендеринга во время выполнения, чтобы увидеть, могут ли создаваемые кадры вызывать зависания.

Макробенчмарки позволяют управлять компиляцией перед измерением с помощью API CompilationMode . Используйте разные значения CompilationMode для сравнения производительности в разных состояниях компиляции. В следующем фрагменте кода показано, как использовать параметр CompilationMode для измерения преимуществ базовых профилей:

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

Внимание: запустите тесты на физическом устройстве, чтобы измерить реальную производительность. Измерение производительности на эмуляторе Android, скорее всего, даст неправильные результаты, поскольку ресурсы используются совместно с хост-компьютером.

На следующем снимке экрана вы можете увидеть результаты непосредственно в Android Studio для примера приложения Now in Android, запущенного на Google Pixel 7. Результаты показывают, что запуск приложения происходит быстрее всего при использовании базовых профилей ( 229,0 мс ) по сравнению с отсутствием компиляции ( 324,8 ). РС ).

Рисунок 1. Результаты ColdStartupBenchmark , показывающие время начального отображения при отсутствии компиляции (324 мс), полной компиляции (315 мс), частичной компиляции (312 мс) и базовых профилях (229 мс).

Совет: Вы также можете получить результаты в виде файла JSON, чтобы проанализировать их в рамках конвейера CI. Дополнительную информацию см. в разделе «Бенчмаркинг в CI» .

Хотя в предыдущем примере показаны результаты запуска приложения, полученные с помощью StartupTimingMetric , есть и другие важные метрики, которые стоит учитывать, например FrameTimingMetric . Дополнительные сведения обо всех типах метрик см. в разделе Захват метрик Macrobenchmark .

Время до полного отображения

В предыдущем примере измеряется время первоначального отображения (TTID), которое представляет собой время, необходимое приложению для создания первого кадра. Однако это не обязательно отражает время, пока пользователь не сможет начать взаимодействовать с вашим приложением. Метрика времени до полного отображения (TTFD) более полезна при измерении и оптимизации путей кода, необходимых для обеспечения полностью пригодного к использованию состояния приложения.

Мы рекомендуем оптимизировать как TTID, так и TTFD, поскольку оба важны. Низкий TTID помогает пользователю увидеть, что приложение действительно запускается. Важно сделать TTFD коротким, чтобы гарантировать, что пользователь сможет быстро взаимодействовать с приложением.

Стратегии создания отчетов о том, что пользовательский интерфейс приложения полностью прорисован, см. в разделе «Повышение точности времени запуска» .

{% дословно %} {% дословно %}