Какая архитектура используется сейчас на Android?

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

Знание актуальных рекомендаций и умение объяснить, зачем поток данных однонаправленный. За вопросом стоит проверка, не застрял ли кандидат на связке AsyncTask плюс MVP.

Как отвечать

Опорная схема это рекомендованная Google архитектура из трёх слоёв:

• UI layer: экраны на Compose или View плюс держатель состояния, обычно ViewModel, которая отдаёт один иммутабельный UiState.
• Domain layer (опциональный): юзкейсы для логики, переиспользуемой несколькими ViewModel.
• Data layer: репозитории как единственный источник правды, за ними сетевой источник (Retrofit или Ktor) и локальный (Room, DataStore).

Ключевой принцип это однонаправленный поток данных: события идут вниз, от UI к данным, а состояние поднимается вверх одним объектом. По сути это MVI, в терминах Google просто UDF, и спорить о названии смысла нет: MVVM с одним StateFlow<UiState> и MVI на практике совпадают.

Актуальный стек:

• Kotlin, корутины и Flow вместо колбэков и RxJava в новом коде;
• StateFlow вместо LiveData, подписка в Compose через collectAsStateWithLifecycle(), чтобы поток не собирался, пока экран в фоне;
• Jetpack Compose как основной способ вёрстки, Navigation Compose с типизированными маршрутами;
• внедрение зависимостей через Hilt, встречаются Koin и ручные контейнеры;
• Room с возвратом Flow, офлайн-первый подход, где сеть только обновляет локальный кэш;
• WorkManager для отложенной работы, SavedStateHandle для состояния, переживающего смерть процесса;
• разбиение на модули по фичам ради времени сборки и явных границ, эталонный пример это репозиторий Now in Android.

Про MVP стоит сказать честно: он работоспособен и живёт в легаси, но требует ручного отвязывания вью и сам по себе не переживает смену конфигурации, поэтому новые экраны на нём не пишут.

Если спрашивают про конкретный проект, назвать точки трения: сколько осталось на View и как оно уживается с Compose через ComposeView, как обрабатываются разовые события, чем тестируются ViewModel (runTest, Turbine для потоков), как устроена многомодульность.

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

Перечисляют MVC, MVP, MVVM и MVI как равнозначный список, не отвечая, что применяется сейчас и почему. Второй провал: называют LiveData актуальным выбором для Kotlin-проекта на Compose и не могут объяснить, чем collectAsStateWithLifecycle лучше обычного collectAsState.