Что такое Jetpack Compose и чем он отличается от традиционной системы View в Android?

Сравнение: счётчик на View vs Compose

// === VIEW SYSTEM ===
// activity_main.xml:
// <TextView android:id="@+id/tvCount" .../>
// <Button android:id="@+id/btnIncrement" .../>

class MainActivity : AppCompatActivity() {
    private var count = 0

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val tvCount = findViewById<TextView>(R.id.tvCount)
        val btnIncrement = findViewById<Button>(R.id.btnIncrement)

        tvCount.text = count.toString()  // ← вручную синхронизируем UI с данными

        btnIncrement.setOnClickListener {
            count++
            tvCount.text = count.toString()  // ← вручную обновляем при каждом изменении
        }
    }
}

// === JETPACK COMPOSE ===
@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Column {
        Text(text = count.toString())   // ← автоматически обновится при изменении count
        Button(onClick = { count++ }) {
            Text("Increment")
        }
    }
}
// Вызов: setContent { Counter() }

Декларативный vs императивный подход

Традиционная View system работает императивно: разработчик создаёт XML-разметку, получает ссылки через findViewById и вручную обновляет каждый элемент при изменении данных. Compose работает декларативно: вы описываете, как UI должен выглядеть при конкретном состоянии, а Compose сам определяет, что нужно перерисовать.

Ключевые отличия

Как Compose обновляет UI: recomposition

Когда state изменяется, Compose запускает recomposition — повторный вызов composable-функций, которые читают этот state. Compose умный: он пересобирает только те части дерева, где данные изменились, а не весь экран. Функции, параметры которых не изменились, пропускаются.

Interop: использовать оба подхода вместе

Compose и View system совместимы. В существующем приложении на View можно добавлять Compose-экраны через ComposeView, а в Compose встраивать старые View через AndroidView. Это упрощает постепенную миграцию.

// Embed Compose inside Fragment/Activity:
val composeView = ComposeView(context).apply {
    setContent { MyComposable() }
}

// Embed existing View inside Compose:
AndroidView(
    factory = { context -> LegacyChartView(context) },
    update = { view -> view.setData(chartData) }
)

Подводные камни

• Переносить мышление View в Compose — нельзя искать «элемент по id и менять его». В Compose UI — это функция от state, а не объект с методами.
• Изменять state вне remember — обычная переменная var count = 0 не вызовет recomposition. Только mutableStateOf внутри remember или StateFlow из ViewModel.
• Вызывать composable не из composable-контекста — composable-функции можно вызывать только внутри других composable или setContent. Иначе — runtime crash.
• Игнорировать lifecycle при side effects — запускать корутины или подписки нужно в LaunchedEffect/DisposableEffect, не в теле composable напрямую.
• Ожидать XML-инструменты — Layout Editor частично поддерживает Compose через Preview, но полного паритета с XML editor нет. Compose Preview — основной инструмент дизайна.

• Объяснять «Jetpack Compose и View system» только как синтаксис и не описывать поведение runtime/compiler.
• Игнорировать важный риск: Нельзя описывать Compose как XML view system: это ведет к неверной модели state и lifecycle.
• Давать пример без edge case: отмены, null, recomposition, platform boundary или ошибки.

• Формулирует суть темы «Jetpack Compose и View system» своими словами и связывает ее с кодом.
• Называет механизм: Compose строит composition, выполняет recomposition при изменении state и применяет layout/drawing без imperative findViewById.
• Видит production-последствие: Нельзя описывать Compose как XML view system: это ведет к неверной модели state и lifecycle.