В чем разница Jetpack Compose и XML разметки в Android

Что проверяют

Понимаете ли вы разницу между декларативным и императивным подходом, а не только «новое против старого».

Как отвечать

XML и View это императивный подход: разметка описывает начальное состояние, а дальше интерфейс изменяют вручную. Нашли элемент, поставили текст, спрятали кнопку. Состояние оказывается в двух местах, в модели и в дереве представлений, и рассинхрон этих копий даёт большую часть ошибок интерфейса.

Compose это декларативный подход: вы описываете, как выглядит экран при данном состоянии, а система сама перерисовывает изменившиеся части. Копия правды одна.

Отличия по пунктам:

• язык: Kotlin вместо разметки, поэтому условия, циклы и переиспользование обычные средства языка, а не отдельный механизм;
• создание элементов: XML раздувается через рефлексию, что дорого, у Compose такого шага нет вовсе;
• связывание: findViewById и ViewBinding исчезают;
• списки: LazyColumn вместо RecyclerView с адаптером, держателем и DiffUtil;
• анимации и темы заметно проще;
• превью прямо в среде разработки, без запуска приложения.

Минусы Compose назвать обязательно:

• своя модель производительности: вместо иерархии представлений нужно понимать перекомпозицию, стабильность типов параметров и лямбды, создаваемые заново на каждом кадре;
• размер приложения немного больше, потому что подключается своя библиотека;
• экосистема: часть библиотек и сложные компоненты вроде карт по-прежнему на View;
• порог входа для команды, привыкшей к XML.

Переход постепенный: ComposeView встраивается в старую разметку, AndroidView встраивает представление в Compose. На практике новые экраны делают на Compose, старые не переписывают без причины.

Где спотыкаются

Называют Compose просто новым способом писать разметку.

Держат состояние внутри функции без remember и удивляются сбросу.

Считают перекомпозицию полной перерисовкой экрана.

Обещают, что Compose быстрее, не понимая, откуда берётся выигрыш.