Автор: Android-разработчик с опытом 7+ лет, переживший времена RelativeLayout, ConstraintLayout, Fragments, и встретивший Compose с легким скепсисом… который быстро исчез.
Введение
Jetpack Compose — не просто «альтернатива XML». Это совершенно другой парадигмальный сдвиг в том, как Android отрисовывает и управляет UI. Но чтобы по-настоящему понять, чем Compose отличается от привычного XML, давайте посмотрим, что происходит под капотом в каждом случае.
XML: декларативность на бумаге, императивность на деле
Когда мы пишем XML, например:
<TextView
android:id="@+id/helloText"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="Hello World!" />Android делает следующее:
При запуске активити setContentView() парсит XML в дерево View-объектов.
Каждая View создается через LayoutInflater, вручную.
Все привязки (findViewById, ViewBinding) происходят после создания дерева.
Вся логика реакций (клики, данные и т.д.) — императивная: view.setOnClickListener
Под капотом:
Создание View и ViewGroup объектов.
XML превращается в байткод (через aapt2), но всё равно требует inflate.
Связь данных — вручную или через DataBinding/LiveData/BindingAdapter.
Compose: декларативность в действии
Jetpack Compose выглядит так:
Text(text = "Hello World!")И это не View. Под капотом это:
Kotlin-функция, вызываемая внутри @Composable контекста.
При первом запуске — выполняется, создается дерево UI-элементов (но не View!).
При изменении данных — функция перезапускается, но только изменившиеся куски рекомпозируются.
Все изменения идут через снапшоты (snapshot state), обеспечивая минимальное обновление UI.
Под капотом:
Compose UI работает поверх android.graphics и RenderNode/LayoutNode.
Вместо View — создается LayoutNode дерево.
Используется собственный алгоритм сравнения (Recomposer + SlotTable) для вычисления изменений.
Используется Skia для отрисовки (через Canvas API).
Технические различия
XML + View System | Jetpack Compose | |
Элементы UI | Наследники android.view.View | Функции @COMPOSER |
Layout | ViewGroup, MeasureSpec | LayoutModifier, Constraints |
Изменение данных | Через findViewById / Binding | Через mutableStateOf, remember |
Производительность | Тяжелая иерархия View | Компактное дерево LayoutNode |
State & Lifecycle | Разрозненные | Единый state + lifecycle-aware |
Отрисовка | Android View → Canvas | Compose → RenderNode / Skia |
Ключевая мысль
XML + View System | Compose |
императивный подход, где вы управляете каждым элементом вручную: создаете, обновляете, удаляете. | реактивная декларативная система: вы описываете, что должно быть, и система сама решает, как это нарисовать и что нужно обновить. |
Как это влияет на разработку
Меньше багов при обновлении UI — всё зависит от state, а не от manual-логики.
Быстрее итерации — особенно в UI-heavy фичах.
Более выразительный код — меньше ceremony, больше смысла.
Что стоит помнить
Compose — это не «быстрее» по умолчанию. Если плохо управлять state или recomposition — будет хуже, чем XML.
Compose требует другого мышления. Это как переход с for и while на Flow и map.
Заключение
Jetpack Compose — не просто «новый способ писать UI». Это новый runtime, новый rendering engine, и новая архитектурная философия.
Если XML — это «нарисуй мне UI вручную», то Compose — это «вот данные, покажи их правильно, сам реши как».
Переход на Compose — это не вопрос «стоит ли», а вопрос **«когда» и «с какими знаниями» ты туда пойдешь.
