Почему используется single activity архитектура в Android проектах

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

Понимаете ли вы, какую конкретную проблему решает подход, или повторяете тезисы из доклада. Следом спрашивают про глубокие ссылки и смерть процесса, а ещё когда одной Activity мало.

Как отвечать

Суть: приложение держит одну Activity, экраны это фрагменты или composable-назначения, а переходами управляет граф навигации.

• навигация в одном месте: NavHostFragment с графом или Navigation Compose. Бэкстек один и восстанавливается системой, аргументы типобезопасны через Safe Args;
• общее состояние: ViewModel в области видимости Activity или подграфа переживает переход между экранами, и данные не надо гонять через extras;
• дешевле переход: старт Activity идёт через системный ActivityManager с созданием окна, а смена фрагмента это работа внутри процесса. Отсюда плавные анимации и общие переходы элементов;
• обработка «назад» в одной точке: OnBackPressedDispatcher и колбэки экранов, это упрощает поддержку предиктивного жеста назад;
• глубокие ссылки: одна точка входа, ссылка разворачивается в цепочку экранов графа вместо набора Intent с флагами и taskAffinity.

Обязательно назовите цену. Activity остаётся границей с системой: шаринг, выбор файла, камера, вход из уведомления. Граф на сотню экранов нечитаем, его режут на вложенные подграфы по фичам. Жизненный цикл фрагмента и его view различаются, подписки надо привязывать к viewLifecycleOwner, иначе течёт. Смерть процесса никуда не девается: состояние восстанавливается из SavedStateHandle, а не из полей.

Сильный финал: подход не догма. Отдельная Activity оправдана для онбординга, полноэкранного плеера или экрана из уведомления.

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

Главной причиной называют производительность и экономию ресурсов. Выигрыш на старте экрана есть, но главное это единый бэкстек и одна точка управления навигацией.

Считают, что single activity убирает проблемы жизненного цикла. Он их переносит на фрагменты, где пересоздание view и разница между this и viewLifecycleOwner ловят не меньше.

Не могут ответить, где живёт состояние при смерти процесса, и говорят «во ViewModel». ViewModel переживает поворот экрана, но не убийство процесса.