Как я уже упоминал, в анализе технологий нужно всегда исходить из проблемы, которую они решают. Я выделил 4 проблемы, которые он может решить. Некоторые притянуты зауши, тем не менее…

Сложность
Основная проблема которую решает Compose это сложность. Очевидно что мы становимся очень привередливыми к UI. Обычные элементы нам уже кажутся скучными. Чтобы у продукта был коммерческий успех у него обязан быть классный UX и красивый дизайн. Градиенты, тени, сложные списки со сложной анимацией все это переходит в разряд обычного приложения и если этого нет, то мы начинаем чувствовать неудобство при использовании.

Все это приводит к страшной запутанности кода. У нас есть верстка в xml, есть Custom View которые описываются кодом. После мы должны написать код для фрагмента, далее поместить его в Activity, Activity в утку, утку в зайца ну вы поняли. У всех этих элементов есть свои ЖЦ и даже простое приложение с одной кнопкой требует кучу кода. Каждый раз тратим на кучу времени на болерплейт, который как кажется можно не писать.

В основе Compose лежит идея описания UI при помощи чистых функций. Ранее я делал посты, как чистые функции помогают сделать код проще, в запиненных сообщениях. Благодаря тому, что делаем все через код, это позволяет на лету заменять расположение элементов на экране. Не нужно теперь создавать свою кнопку если нужно в ней например разместить два TextView, теперь это все доступно их коробки.

Файл с версткой
С версткой какая проблема, мы создаем её через xml, который потом упаковывается в специальный бинарный формат для скорости. В момент когда нам нужно показать экран, нужный файл с версткой сначала подгружается из файловой системы, затем парсится и через рефлексию создаются нужные View. Только после этого они рассчитываются и отрисовываются на экране.

Это конечно уже максимально оптимизированный процесс, однако наличие рефлексии и подгрузки из файла говорит о том, что накладные расходы все же есть.

Состояние у View
В приложении обычно есть как минимум два слоя. UI слой и Presentation. Архитектура UI в Android построена таким образом, что у нее есть состояние. Это состояние чекбоксов, введенный текст, добавленные или удаленные View и т.д. В Presentation слое у нас тоже есть состояние. Основная проблема, что эти состояния нужно синхронизировать.

Это проводит к тому, что у нас логика управления состоянием размазывается. Какую-то часть сохраняем в Bundle, какую-то часть в Presentation. Со временем все это разрастается так, что хочется сменить профессию. Порой стараются не делать состояние в Presentation, и в итоге у нас состояние контролирует UI, что он делать не должен. Есть архитектуры вроде MVI которые сглаживают эту проблему, но не решают окончательно.

Не должно быть у UI своего состояние. Состояние должно быть только у Presentation слоя, который уже передает его UI. Compose именно так и построен. У Compose функций нет своего состояния, мы лишь указываем что хотим получать на экране в зависимости от изменения состояния Presentation.

⬇