Базовые профили тестирования с помощью библиотеки 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 . Для получения дополнительной информации обо всех типах метрик см. Capture Macrobenchmark metrics .

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

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

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

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

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