Сравните метрики 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 состоял из сборки пользовательского интерфейса с сочетанием представлений и создания. Этого увеличения следовало ожидать, поскольку в Sunflower были добавлены дополнительные зависимости.

И наоборот, когда Sunflower был перенесен на приложение только для создания сообщений, размер APK уменьшился с 3034 КБ до 2966 КБ — уменьшение на 68 КБ . Это уменьшение произошло из-за удаления неиспользуемых зависимостей представления, таких как 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 обеспечивает интеллектуальные рекомпозиции , воспроизводя ранее нарисованный результат, если вам не нужно вносить изменения.

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

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

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

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

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

Тестирование компоновки

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

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

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

Создать профиль установки

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