Использовался ли в проектах single activity или несколько активностей

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

Хотят понять, работали ли вы с современной навигацией в Android и понимаете ли, почему выбран тот или иной подход, а не просто «так было в проекте». Следом обычно спрашивают, как вы передавали данные между экранами и где жили общие ViewModel.

Как отвечать

Начните с фактов о своих проектах: какая архитектура, на чём UI (View и фрагменты или Jetpack Compose), какая библиотека навигации. Примеры и детали должны быть ваши.

Затем покажите, что понимаете компромисс:

• single activity: одна activity как контейнер, экраны на фрагментах с Navigation Component или на Compose с Navigation Compose. Google рекомендует этот подход по умолчанию. Плюсы: единый граф навигации и диплинки в одном месте, общие ViewModel на уровне графа (navGraphViewModels, hiltNavGraphViewModels), нет передачи данных через Intent между экранами, одинаковые анимации переходов;
• несколько activity: оправданы там, где нужны отдельные точки входа. Экран, который открывается из «Поделиться» другого приложения, настройка виджета, звонок или режим «картинка в картинке» со своим launchMode. Часто это и наследие: старые экраны живут в своих activity, а новые пишутся уже внутри одной;
• смешанный вариант: одна основная activity плюс несколько узкоспециализированных, самая частая картина в зрелом приложении.

Если работали только с одним подходом, так и скажите, а затем объясните, что выбрали бы на новом проекте и почему. В Compose вопрос почти снят: экраны это composable-функции, и вторая activity нужна только для отдельного входа.

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

Повторяют, что single activity подходит для простых приложений, а несколько activity для сложных. Скорее наоборот: чем больше экранов и диплинков, тем выгоднее единый граф.

Во фрагментах подписываются на LiveData или Flow с this вместо viewLifecycleOwner. После возврата из back stack подписок становится две, и события приходят дважды.

Передают крупные объекты через Bundle и ловят TransactionTooLargeException: буфер binder-транзакций около 1 МБ на процесс. Большие данные передают через общий репозиторий или ViewModel.