Как оценить профили базовой конфигурации с помощью библиотеки Macrobenchmark

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

Макротесты позволяют управлять компиляцией перед измерением с помощью 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 Studio для приложения Now in Android sample, запущенного на Google Pixel 7. Результаты показывают, что запуск приложения происходит быстрее всего при использовании профилей Baseline (229,0 мс) по сравнению с отсутствием компиляции (324,8 мс).

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

Время до полного показа

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

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

Подробнее о том, как повысить точность измерения времени запуска…