Jetpack Compose: что это и зачем

Введение: вопрос, который задают всё чаще

«Что такое Jetpack Compose?» — с этого вопроса начинается почти каждое собеседование на Android-разработчика в 2026 году. И ответ «это фреймворк для UI» уже не засчитывается: интервьюер ждёт, что вы понимаете, почему Compose появился и как он устроен.

Jetpack Compose — это современный декларативный инструментарий для создания пользовательского интерфейса Android, как его определяет официальная документация. Если коротко: вы описываете, как должен выглядеть экран при текущих данных, а Compose сам решает, что и когда перерисовать.

Статья для двух случаев: если вы только знакомитесь с Compose и хотите понять суть, и если готовитесь к собеседованию, где тему спросят глубже, чем «какие есть компоненты». Разберём декларативную модель, рекомпозицию, состояние и причины, по которым Google переводит Android на Compose-first.

Декларативная парадигма: в чём разница

Чтобы понять Compose, нужно забыть, как вы работали с View. Исторически иерархия Android-интерфейса — это дерево виджетов, которое вы вручную обновляете при изменении данных: нашли кнопку через findViewById, вызвали setText, добавили элемент в контейнер. Документация прямо говорит: ручное управление представлениями увеличивает вероятность ошибок — забыли обновить одно из мест, где показываются данные, и получили рассинхрон UI.

Декларативный подход переворачивает модель: вы описываете, как экран выглядит в зависимости от состояния, и при изменении состояния Compose перестраивает UI сам. Вы не даёте команды «обнови это поле», вы описываете: «вот данные — вот как они отображаются».

@Composable
fun Greeting(name: String) {
    Text(text = "Привет, $name!")
}

Это composable-функция. Обратите внимание на свойства, которые документация считает обязательными: функция принимает данные, генерирует элементы UI, ничего не возвращает и не имеет побочных эффектов. Она просто описывает экран.

Практическое следствие: в Compose нет findViewById, нет геттеров и сеттеров у виджетов. Вы обновляете UI, вызывая ту же функцию с другими аргументами. Код становится проще и предсказуемее.

Рекомпозиция: как Compose обновляет экран

Теперь главный механизм — рекомпозиция. Когда состояние меняется, Compose заново вызывает composable-функции с новыми аргументами. Звучит как «перерисовать всё», но это не так: Compose интеллектуально выбирает, какие части UI нужно перерисовать в каждый момент, и пропускает те, чьи параметры не изменились.

Это накладывает требования на composable-функции: они должны быть быстрыми, идемпотентными и без побочных эффектов. Функция, которая при каждом вызове пишет в глобальную переменную или обращается к random(), ломает модель — Compose может вызывать её в любом порядке и параллельно.

Посмотрите на состояние в действии:

@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")
        }
    }
}

Разбор по строкам: mutableStateOf создаёт наблюдаемое состояние, remember сохраняет его между рекомпозициями, а by — делегирование, которое автоматически перезапускает чтение при изменении. Нажали кнопку — count изменился — Compose перекомпоновал только те части, которые читают count, то есть текст.

Это стандартный ответ на вопрос «как Compose узнаёт, что обновить»: через наблюдение за состоянием и пропуск неизменных частей.

Почему Compose вытесняет View-систему

Теперь «зачем» на уровне индустрии. Google объявила Android подходом «Compose-first»: вся новая документация, коделабы и сэмплы пишутся под Compose, а новые инструменты Android Studio — только для Compose. Классический View-тулкит (android.widget — TextView, ListView и так далее) переведён в режим сопровождения: он получает только критические исправления, новые возможности не добавляются.

Более того, в режиме сопровождения оказались и View-версии популярных библиотек: RecyclerView, ViewPager2, Fragment, Material Components (Views) и другие. Это прямое указание направления: вся новая функциональность идёт в Compose.

Для практики это значит следующее:

• Новые проекты разумно начинать на Compose — не из моды, а потому что туда уходит развитие.
• Существующие проекты мигрируют постепенно: Compose официально поддерживает интероп с View — можно встраивать Compose в старый экран и View в новый.
• Вакансии всё чаще требуют Compose, и на собеседованиях спрашивают не «знаете ли вы», а «понимаете ли вы, как он работает».

Подробности — в официальной документации: как устроена декларативная модель Compose и почему Google перешла на Compose-first.

Что спрашивают на собеседовании

Вопрос «что такое Compose» на собеседовании — это проверка понимания парадигмы, а не памяти. Хороший ответ звучит так: Compose — декларативный UI-тулкит, где экран описывается composable-функциями как функция от состояния; при изменении состояния происходит рекомпозиция, которая пересобирает только изменившиеся части; состояние держится через remember и mutableStateOf; View-система остаётся в режиме сопровождения, поэтому новое пишут на Compose.

• «Compose — это язык разметки». Нет, это Kotlin-фреймворк: UI пишется на обычном Kotlin, без отдельного языка.
• «Compose заменяет только XML». Замена глубже: меняется модель управления UI, а не формат файлов.
• «Рекомпозиция рисует экран заново». Нет, она пересобирает описание UI и пропускает неизменные части.
• «В Compose нельзя использовать View». Можно: есть интероп-механизмы (AndroidView, ComposeView) для постепенной миграции.
• «Compose медленный». Без аргументов — это миф: пропуск рекомпозиции и ленивые списки решают проблему, если UI написан правильно.

Отдельно стоит упомянуть LazyColumn — аналог RecyclerView в Compose, который так же переиспользует элементы и рендерит только видимые. Уверенный рассказ про него закрывает половину вопросов про списки.

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

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

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

Итоги

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

• Суть: декларативный UI-тулкит — экран описывается как функция от данных, а не управляется императивно.
• Механика: composable-функции без побочных эффектов, рекомпозиция с пропуском неизменных частей, состояние через remember и mutableStateOf.
• Направление: Google перешла на Compose-first, View-тулкит в режиме сопровождения — новое пишут на Compose.

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