Compose или XML: что выбрать

Введение: вопрос, который задают и в проектах, и на собеседованиях

«Compose или XML?» — этот выбор встаёт перед каждым: начинаете новый проект — что закладывать? Идёте на собеседование — вас спросят, что вы выберете и почему. Правильный ответ не «Compose, потому что модно», а разбор по критериям.

Сразу важная поправка, которую часто не замечают: противопоставление «Compose против XML» технически неверно. XML — это формат разметки, а Compose — фреймворк. Реальное противопоставление — Compose против View-системы (той самой, что читает XML-разметку через setContentView). Но на собеседовании вопрос сформулируют именно так, поэтому разберём его в привычных терминах.

Что важно понять: разница не в файлах, а в модели работы с UI. Отсюда и пляшут все критерии сравнения.

Разные модели: императив против декларатива

XML-разметка описывает структуру экрана, но жизнь UI на этом не заканчивается. После setContentView начинается императивное управление: найти виджет через findViewById, обновить через setText, добавить элемент в контейнер. При каждом изменении данных вы вручную синхронизируете дерево виджетов.

<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:gravity="center">

    <TextView
        android:id="@+id/text_counter"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Счёт: 0" />

    <Button
        android:id="@+id/button_increment"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="+1" />
</LinearLayout>

val counter = findViewById<TextView>(R.id.text_counter)
buttonIncrement.setOnClickListener {
    counter.text = "Счёт: ${++count}"
}

В Compose вы описываете экран как функцию от состояния: поменялось состояние — Compose сам пересобирает описание и применяет изменения. Никаких findViewById и ручной синхронизации.

@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }

    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(text = "Счёт: $count", style = MaterialTheme.typography.headlineMedium)
        Button(onClick = { count++ }) {
            Text("+1")
        }
    }
}

Официальная документация называет Compose декларативным UI-тулкитом и описывает, как работает эта модель — «Мыслить в композиции».

Сравнение по критериям: без фанатизма

Теперь по-честному, по пунктам, которые важны в реальном проекте.

Скорость разработки. Compose выигрывает на динамичных экранах: состояние, списки, анимации. Предпросмотр (@Preview) показывает экран без запуска приложения, а Live Edit обновляет изменения мгновенно. XML быстрее для статичных простых форм — но таких экранов в современных приложениях всё меньше.

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

Кастомизация и дизайн-системы. Material 3 из коробки — это про Compose. Темы, компоненты, адаптивность под разные форм-факторы — вся новая функциональность идёт только туда. XML-версия Material Components заморожена.

Экосистема. Вот где View ещё держится: библиотеки вроде карт или сложных графиков легче встраиваются как View. Но Compose умеет встраивать View-компоненты через интероп (AndroidView), так что это не блокер, а нюанс.

Команда. Если команда годами писала на View, переход пугает. На практике кривая входа короткая: Compose — это обычный Kotlin, новый синтаксис вроде Modifier и remember осваивается за пару недель практики. Плюс @Preview и Live Edit сокращают цикл «написал — увидел», что особенно ценится новичками. Сложнее всего переучиваться не писать императивно — но именно этот переход и прокачивает уровень.

Миграция: можно ли совмещать

Ключевой факт, который снимает половину страхов: Compose и View официально совместимы. Compose-функция AndroidView позволяет встроить любой View-компонент, а ComposeView — вставить Compose в существующий XML-экран. Миграция идёт экран за экраном, без «дня X», когда всё переписывается разом.

Реальные сценарии:

• Новый модуль в старом приложении — пишется на Compose, остальное живёт как жило.
• Новые экраны — на Compose, старые переписываются по мере необходимости.
• Полный переход — когда Compose закрывает все потребности проекта, View-слои выпиливаются.

Почему мигрировать вообще нужно: Google объявила Android подходом «Compose-first». Классический View-тулкит переведён в режим сопровождения — только критические исправления, никаких новых возможностей. То же с View-версиями библиотек: RecyclerView, ViewPager2, Fragment, Material Components — режим сопровождения. Новые инструменты Android Studio делаются только для Compose. Официальное заявление — на странице «Android is Compose-first».

Что выбрать в 2026 году и как ответить на собеседовании

Практический вывод такой.

Новый проект. Закладывайте Compose. Не потому что «так все делают», а потому что развитие идёт туда: новые API, Material 3, инструменты, документация. Начинать новый проект на XML в 2026 году — значит взять технологию, у которой нет будущего, и платить за это долгие годы.

Существующий проект. Оценивайте по экранам: новое — на Compose, критичные View-экраны — как есть, интероп решает стыки. Полная миграция — вопрос приоритетов, а не технологий.

Собеседование. Здесь проверяют умение рассуждать. Отвечайте структурой: разница в парадигме (императив против декларатива), критерии выбора (скорость разработки, состояние, экосистема), направление индустрии (Compose-first, View в режиме сопровождения), план миграции (интероп, поэтапность).

• «XML — это старое, Compose — новое, всё». Нет аргументов — нет баллов. Нужны критерии и понимание, почему.
• «Compose нельзя использовать с View». Можно, через AndroidView и ComposeView.
• «Compose медленный». Без конкретики это миф; узкие места находятся профилировщиком.
• «Мигрировать надо за один раз». Нет, миграция поэтапная, экран за экраном.

Уверенный ответ выглядит так: «Я бы выбрал Compose для нового функционала: быстрее разработка, лучше работа с состоянием, туда идёт развитие экосистемы. Для legacy-экранов оставил бы View с интеропом, миграцию вёл бы поэтапно». Это ответ инженера, а не фаната.

И последний практический совет: принимайте решение не абстрактно, а от задачи. Список с фильтрами, чат, лента — экраны, где Compose даёт максимальный выигрыш. Простая статичная форма с двумя полями и кнопкой в legacy-проекте — повод оставить View, а не героически переписывать. Умение не трогать работающее — тоже часть middle-уровня.

Кто это пишет: про автора

Меня зовут Рустем Бикбулатов. Я senior Android-разработчик, провожу технические собеседования и менторю в Яндекс Практикуме. За моей спиной более ста учеников и разборов.

Я помогаю Android-разработчикам с опытом один-два года перейти на уровень middle за четыре-восемь недель: закрываю пробелы в Kotlin, корутинах и архитектуре, тренирую ответы на собеседованиях — Яндекс, Авито и другие сильные компании. Умение аргументированно выбирать технологии — часть middle-уровня, и вопросы «Compose или XML» это проверяют лучше всего.

Итоги

Вопрос «Compose или XML» — это на самом деле вопрос «как вы принимаете технические решения». Правильный ответ всегда взвешенный, по критериям, а не по моде.

• Разница: XML-разметка + императивное обновление против полностью декларативной модели Compose.
• Выбор: новый проект — Compose; legacy — поэтапная миграция через интероп (AndroidView, ComposeView).
• Направление: View-тулкит в режиме сопровождения, Compose-first — вся новая функциональность идёт в Compose.

Если чувствуете, что знаете отдельные темы, но на собеседовании не можете собрать ответ в структуру — это тренируется, и быстрее всего в формате мок-собеседования. Напишите в Telegram, разберём вашу ситуацию и составим план подготовки.