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

Больше примеров успешного внедрения Compose в Teams вы можете прочитать в соответствующей статье.

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

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

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

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

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

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

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

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

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

Всё расширяет View

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

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

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

Многократный проход компоновки

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

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

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

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

Бенчмарк Компози

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

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

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

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

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