Часть 2: XML или Compose — что выбрать, и что нужно знать перед выбором

Автор: Android-разработчик с 7+ годами опыта, знающий толк в FrameLayout, merge, include, RecyclerView, а теперь и Modifier.padding.

Введение

Если вы стоите перед выбором: продолжать с XML или начать писать UI на Jetpack Compose, — значит, вы уже на полпути к новому уровню. Но этот выбор должен быть осознанным. Compose — это не всегда “давай всё перепишем”. Это шаг в сторону новой архитектурной модели. А значит, нужно задать себе несколько правильных вопросов.

Вопросы, которые стоит задать себе (и команде)

1. Проект новый или уже живой?

• ✅ Новый проект: Compose — логичный выбор. Нет смысла тащить наследие.

• ⚠ Живой проект: возможно, стоит идти через Gradual Migration (например, экраны по одному).

2. Какой уровень знаний команды?

• Если команда на “ты” с Kotlin, Coroutines, StateFlow — Compose зайдёт быстро.

• Если всё ещё в парадигме MVP и LiveData — будет больно, но полезно.

3. Как устроен текущий UI-фреймворк?

• Используется DataBinding? ViewBinding? MVVM?

• Есть ли сложные кастомные View или анимации?

4. Требуется ли WebView, MapView, ExoPlayer?

• Эти штуки пока требуют танцев в Compose, либо использовать AndroidView.

Под капотом: что важно знать, прежде чем делать выбор

Размер библиотек

• XML (ViewSystem):

  • Лёгкая на старте, всё уже встроено.

  • Не тянет ничего сверху.

• Jetpack Compose:

  • Библиотеки по модулям (foundation, material, ui-tooling и т.д.).

  • В среднем добавляют от 1 до 4 МБ в зависимости от используемых компонентов.

  • Kotlin Compiler Plugin и Compose Compiler тоже увеличивают сборку.

⚠ Если size-critical приложене, стоит быть осторожным с preview, tooling, animation

Размеры основных библиотек Jetpack Compose (release-сборка)

• Если ты используешь Material 3, она весит больше, чем Material 2, за счёт более сложной темизации, адаптивных компонентов и анимаций.

• Tooling и Preview — включаются только в debug, и не попадают в release.

• В среднем, минимальный рабочий Compose стек (без Material, без Navigation) добавляет примерно 2–3 МБ к финальному .apk.

• Полноценный стек с material3, animation, navigation, foundation, и пр. — до 5–6 МБ в зависимости от Proguard и R8 оптимизации.

Как работает рендеринг

XML

• LayoutInflater → создаёт дерево View-объектов.

• MeasureSpec + onMeasure/onLayout/onDraw.

• Всё связано с ViewRootImpl, Choreographer, Handler.

Compose

• Компайлится в SlotTable — структура, хранящая UI как функции.

• Recomposer отслеживает состояние, вызывает только изменённые Composables.

• LayoutNode → RenderNode → Skia → Canvas.

• Нет View, нет LayoutInflater, нет findViewById.

📌 State меняется → recomposition → только часть UI обновляется → минимальный overdraw.

Жизненный цикл

• XML → завязан на Activity/Fragment lifecycle напрямую.

• Compose → использует remember, DisposableEffect, LaunchedEffect, SideEffect, и Composition Lifecycle.

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

Критические отличия, которые не видны сразу

Когда точно стоит брать Compose

• Создаёте дизайн с большим количеством состояний.

• Хотите избавиться от Adapter и ViewHolder.

• Мечтаете про анимации без боли.

• Пишите Kotlin и не хотите прыгать между XML и кодом.

Что почитать глубже

• Understanding SlotTable in Compose

• Recomposition explained

• Compose Compiler Source

Заключение

Выбор между XML и Compose — это не просто про удобство. Это про то, насколько вы готовы отпустить старый способ мышления и довериться системе. Compose требует доверия, но как только вы его дадите — он удивит вас скоростью, гибкостью и контролем.

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