Compose против XML: когда что выбирать

Сравниваем Compose и привычную верстку на XML, чтобы понять, что курс даёт на практике.

View-система — классический способ строить Android UI: разметка в XML плюс код на Kotlin/Java для связывания.

Сколько кода уходит на одно и то же

Покажем «карточку с именем» в обоих подходах. Сначала XML — нужен файл разметки и код, который его «надувает» и заполняет:

<LinearLayout
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">
    <TextView android:id="@+id/title" />
</LinearLayout>

Плюс Kotlin-код, который ищет title и ставит текст. В Compose тот же экран — одна функция:

@Composable
fun NameCard(name: String) {
    Column {
        Text(text = name)
    }
}

Нет отдельного файла разметки, нет findViewById, нет рассинхронизации. Логика и внешний вид живут рядом, на одном языке.

Экономия не только в строках. В XML-подходе, чтобы один экран показал три разных состояния (загрузка, ошибка, данные), вы держите все три варианта виджетов в разметке и руками прячете/показываете их через visibility. В Compose вы просто пишете условие на Kotlin: if (isLoading) Spinner() else Content(data) — лишних виджетов в памяти нет, а логика читается сверху вниз как обычный код.

Таблица сравнения

КритерийView / XMLCompose
Язык разметкиXML + Kotlinтолько Kotlin
Обновление UIвручную через idавтоматически по состоянию
Превьюесть, но ограниченноемощное, много вариантов
Шаблонный кодмного (binding, id)мало
Зрелость экосистемыочень высокаярастёт, но младше

Как работает под капотом

Под капотом обе системы в итоге рисуют пиксели на одном и том же Canvas. Разница в слое выше: View хранит изменяемое дерево виджетов и заставляет вас руками держать его в актуальном состоянии. Compose хранит описание и сам сравнивает версии, перерисовывая лишь различия. Поэтому Compose дружелюбнее к состоянию, но требует другого образа мышления.

Частые ошибки

  • Считать, что Compose «всегда быстрее». Производительность зависит от того, как вы пишете код (см. урок про тяжёлую recomposition).
  • Пытаться смешивать подходы бездумно. Compose и View можно совмещать (через AndroidView и ComposeView), но это для миграции, а не для повседневной верстки.
  • Бросать изучение основ View целиком: многие концепции (например, жизненный цикл Activity) остаются актуальными.

Итог

  • Compose убирает XML и ручное связывание: меньше кода, единый язык.
  • UI обновляется по состоянию автоматически, а не вручную по id.
  • View-система зрелее и местами всё ещё нужна; Compose — направление, в котором движется Android.
Проверьте себя
1. Главное преимущество Compose перед версткой на XML — это...
AПолный отказ от Kotlin
BМеньше шаблонного кода и автоматическое обновление UI по состоянию
CНевозможность делать ошибки в верстке
DПоддержка только тёмной темы
2. Можно ли совмещать Compose и старую View-систему в одном приложении?
AНет, это полностью несовместимые технологии
BДа, через AndroidView и ComposeView, обычно при миграции
CДа, но только в превью
DТолько если переписать всё на Java