Сравните метрики Compose и View

Jetpack Compose ускоряет разработку пользовательского интерфейса и улучшает разработку приложений для Android . Однако следует учитывать, как добавление Compose в существующее приложение может повлиять на такие показатели, как размер APK-файла приложения, скорость сборки и производительность во время выполнения.

Размер APK и время сборки

В этом разделе рассматривается влияние на размер APK и время сборки на примере приложения Sunflower — приложения, демонстрирующего лучшие практики переноса приложений на основе View в Compose.

Размер APK-файла

Добавление библиотек в проект увеличивает размер APK-файла. Ниже приведены результаты для минимизированного APK-файла каждого проекта с включённым сокращением ресурсов и кода в полном режиме R8, измеренные с помощью APK Analyzer .

При первом добавлении Compose в Sunflower размер APK увеличился с 2252 КБ до 3034 КБ, то есть на 782 КБ . Сгенерированный APK состоял из сборки пользовательского интерфейса с элементами Views и Compose. Это увеличение было ожидаемым, поскольку в Sunflower были добавлены дополнительные зависимости.

Напротив, при миграции Sunflower в приложение, работающее только с Compose, размер APK уменьшился с 3034 КБ до 2966 КБ — на 68 КБ . Это уменьшение было связано с удалением неиспользуемых зависимостей View, таких как AppCompat и ConstraintLayout .

Время сборки

Добавление Compose увеличивает время сборки вашего приложения, поскольку компилятор Compose обрабатывает компонуемые объекты в вашем приложении. Следующие результаты были получены с помощью автономного инструмента gradle-profiler , который выполняет сборку несколько раз, чтобы можно было получить среднее время сборки для отладочной сборки Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

При первом добавлении Compose в Sunflower среднее время сборки увеличилось с 299 до 399 мс, то есть на 100 мс . Эта длительность обусловлена тем, что компилятор Compose выполняет дополнительные задачи по преобразованию кода Compose, определённого в проекте.

Напротив, среднее время сборки сократилось до 342 мс, то есть на 57 мс , после завершения миграции Sunflower на Compose. Это сокращение можно объяснить несколькими факторами, которые в совокупности сокращают время сборки, такими как удаление привязки данных , миграция зависимостей, использующих kapt, в KSP и обновление нескольких зависимостей до последних версий.

Краткое содержание

Внедрение Compose фактически увеличит размер APK-файла вашего приложения, а также повысит производительность сборки благодаря компиляции кода Compose. Однако эти компромиссы необходимо сопоставлять с преимуществами Compose , особенно с учетом повышения производительности разработчиков при использовании Compose. Например, команда Play Store обнаружила, что написание пользовательского интерфейса требует значительно меньше кода, иногда до 50% , что повышает производительность и удобство поддержки кода.

Больше примеров вы можете прочитать в статье Adopt Compose for Teams .

Производительность во время выполнения

В этом разделе рассматриваются темы, связанные с производительностью выполнения Jetpack Compose, чтобы помочь понять, как производительность Jetpack Compose соотносится с производительностью системы View, а также как ее можно измерить.

Умные перекомпозиции

Если части пользовательского интерфейса недействительны, Compose пытается перекомпоновать только те части, которые необходимо обновить. Подробнее об этом читайте в документации по жизненному циклу компонуемых элементов и фазам Jetpack Compose .

Базовые профили

Базовые профили — отличный способ ускорить работу пользователей. Включение базового профиля в приложение может повысить скорость выполнения кода примерно на 30% с первого запуска, избегая этапов интерпретации и JIT-компиляции для включённых ветвей кода.

Библиотека Jetpack Compose включает собственный базовый профиль, и вы автоматически получаете эти оптимизации при использовании Compose в своём приложении. Однако эти оптимизации влияют только на пути кода внутри библиотеки Compose, поэтому мы рекомендуем добавить базовый профиль в своё приложение, чтобы охватить пути кода вне Compose.

Сравнение с системой View

Jetpack Compose имеет множество улучшений по сравнению с системой View. Эти улучшения описаны в следующих разделах.

Все расширяется. Вид

Каждое View , отображаемое на экране, например, TextView , Button или ImageView , требует выделения памяти, явного отслеживания состояния и различных обратных вызовов для поддержки всех вариантов использования. Более того, владелец пользовательского View должен реализовать явную логику, чтобы предотвратить перерисовку без необходимости, например, при повторяющейся обработке данных.

Jetpack Compose решает эту проблему несколькими способами. В Compose нет явных обновляемых объектов для представления чертежей. Элементы пользовательского интерфейса — это простые компонуемые функции, информация о которых записывается в композицию в воспроизводимом виде. Это помогает сократить явное отслеживание состояния, выделение памяти и обратные вызовы только для тех компонуемых элементов, которым требуются эти функции, вместо того, чтобы требовать их для всех расширений данного типа View .

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

Несколько проходов макета

Традиционные ViewGroups обладают высокой выразительностью в своих API измерения и компоновки, что делает их склонными к многократным проходам компоновки. Эти многократные проходы компоновки могут привести к экспоненциальному росту нагрузки, если они выполняются в определённых вложенных точках иерархии представлений.

Jetpack Compose обеспечивает единый проход макета для всех компонуемых макетов через API-контракт. Это позволяет Compose эффективно обрабатывать глубокие древовидные структуры пользовательского интерфейса. Если требуется несколько измерений, Compose располагает встроенными измерениями .

Посмотреть производительность запуска

Система View должна заполнять XML-макеты при первом отображении конкретного макета. Jetpack Compose экономит эти затраты, поскольку макеты пишутся на Kotlin и компилируются так же, как и всё остальное приложение.

Benchmark Compose

В Jetpack Compose 1.0 наблюдаются заметные различия между производительностью приложения в режимах debug и release . Для получения репрезентативных результатов всегда используйте сборку release , а не debug , при профилировании приложения.

Чтобы проверить производительность кода Jetpack Compose, воспользуйтесь библиотекой Jetpack Macrobenchmark . Чтобы узнать, как использовать её с Jetpack Compose, см. проект MacrobenchmarkSample .

Команда Jetpack Compose также использует Macrobenchmark для выявления любых возможных регрессий. Например, ознакомьтесь с бенчмарком для столбца «ленивый» и его панелью управления для отслеживания регрессий.

Установка профиля Compose

Поскольку Jetpack Compose — это нераспакованная библиотека, она не использует преимущества Zygote , которая предварительно загружает классы и элементы управления пользовательским интерфейсом View. Jetpack Compose 1.0 использует установку профилей для релизных сборок. Установщики профилей позволяют приложениям указывать критически важный код, который должен быть скомпилирован заранее (AOT) во время установки. Compose включает правила установки профилей, которые сокращают время запуска и снижают задержки в приложениях Compose.