Сравните метрики 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-only, размер 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% с первого запуска, избегая этапов интерпретации и компиляции just-in-time (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 и компилируются, как и остальная часть вашего приложения.

Составить эталонный тест

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

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

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

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

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