Как сравнить Jetpack Compose с альтернативами по performance, UX, доступу к platform APIs, найму и долгосрочной поддержке?

Performance: измерение, а не ощущения

Сравнение производительности Jetpack Compose с альтернативами требует конкретных метрик, а не общих слов. Ключевые инструменты замера: Android Systrace / Perfetto, Compose compiler metrics (freeCompilerArgs += "-P", "plugin:androidx.compose.compiler.plugins.kotlin:metricsDestination=...") и Macrobenchmark с ComposeStartupBenchmark.

Compose vs XML Views: при правильно настроенном stability (аннотации @Stable, @Immutable, использование ImmutableList из kotlinx.collections) Compose показывает сопоставимую производительность. Основной риск — избыточные рекомпозиции. Инструмент диагностики: Layout Inspector → Recomposition Counts.

Compose vs Flutter: Flutter рисует UI через собственный Impeller/Skia engine, минуя Android View system. Это даёт стабильные 60/120 fps на сложных анимациях, но увеличивает binary size (~5–10 МБ overhead) и исключает нативные платформенные виджеты — всё рисуется кастомно.

Compose vs React Native (New Architecture): RN с Fabric и JSI убрал async bridge, синхронные вызовы нативного кода через JSI дают сравнимую с Compose производительность. Однако JS thread по-прежнему является bottleneck для анимаций без использования react-native-reanimated с worklets на UI thread.

UX и доступность

Compose имеет Semantics API для accessibility: каждый composable может иметь semantics-дерево, читаемое TalkBack. Минус — кастомные composables требуют явного заполнения semantics, тогда как стандартные View-компоненты имели часть accessibility out-of-the-box.

// Кастомный компонент с явными semantics
Box(
    modifier = Modifier
        .semantics {
            contentDescription = "Кнопка удалить элемент $itemName"
            role = Role.Button
            onClick(label = "Удалить") { onDelete(); true }
        }
        .clickable { onDelete() }
) {
    Icon(Icons.Default.Delete, contentDescription = null)
}

Flutter имеет Semantics widget, но его маппинг на Android AccessibilityNodeInfo иногда требует ручной настройки. React Native маппит JS-компоненты на нативные accessibility API автоматически лучше, чем Flutter.

Доступ к Platform APIs

Compose: прямой доступ к Bluetooth, Camera2, NFC, Biometric API через стандартный Android SDK. Никаких абстракций — вызываете нативный API напрямую из ViewModel или UseCase.

Flutter: доступ через Platform Channels или готовые pub.dev-плагины (camera, bluetooth_classic). Сложные или редкие API часто требуют написания собственного platform channel на Kotlin/Swift — это дополнительный слой maintenance.

React Native: Native Modules на Kotlin/ObjC или готовые npm-пакеты. New Architecture (TurboModules) улучшила производительность вызовов, но написание собственных модулей требует знания нативных языков.

Найм и экосистема

Долгосрочная поддержка

Compose активно развивается Google; Android View system переходит в maintenance mode. Для новых проектов инвестиции в Compose оправданы: API стабилизировался после 1.0, Material3 поддерживается нативно, Compose Multiplatform позволяет переиспользовать UI на iOS и Desktop.

Flutter поддерживается Google с долгосрочными обязательствами. React Native — Meta, с открытым сообществом. Оба имеют production-использование в крупных приложениях (Google Pay → Flutter, Microsoft Teams → React Native).

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

• Compose Multiplatform != стабильная iOS-замена — на iOS ряд компонентов всё ещё в beta/alpha, особенно Text rendering и IME handling.
• Flutter binary size — Flutter добавляет ~5 МБ к APK (compressed); критично для рынков с низкой пропускной способностью.
• Переоценка «одна кодовая база» — в Flutter/RN platform-специфичный код (permissions, deeplinks, push notifications) всё равно пишется под каждую платформу отдельно.
• Compose Compiler metrics игнорируют — без проверки restartable/skippable функций через compiler reports легко получить 2x лишних рекомпозиций в production.
• React Native Hermes engine — без явного включения Hermes JS-движка производительность заметно хуже; с Hermes + New Architecture разрыв с нативным решением минимален.
• Platform Channel latency в Flutter — синхронные platform channel calls блокируют UI thread; для частых вызовов (IMU-данные, real-time audio) это создаёт заметный lag.
• Найм «Compose-разработчика» != «Android-разработчика» — знание Compose без понимания Android lifecycle, WorkManager, Room приводит к архитектурным ошибкам в production.

• Сравнивать Jetpack Compose с альтернативами по одному признаку
• Путать личную привычку с инженерным критерием выбора
• Не учитывать migration cost и vendor/ecosystem lock-in

• Сравнивает Jetpack Compose по нескольким инженерным осям
• Не путает популярность с пригодностью
• Понимает migration cost и долгосрочную поддержку