Базовые профили тестирования с помощью библиотеки 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()
        }
    ) {
        uiAutomator {
            startApp(packageName)
            onElement(5_000) { viewIdResourceName == "my-content"}
        }
    }
}

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

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

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

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

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

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

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

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

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

{% verbatim %} {% endverbatim %}