Что происходит с жизненным циклом Fragment при добавлении в back stack в Android

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

Понимаете ли вы разницу между уничтожением представления и уничтожением самого фрагмента, и знаете ли, где держать состояние, чтобы оно пережило возврат назад. Это базовая проверка на умение читать жизненный цикл, а не заучивать список колбэков.

Как отвечать

• addToBackStack() сохраняет не фрагмент, а транзакцию. Что случится с экраном, зависит от операции: replace уводит прежний фрагмент в состояние CREATED, add оставляет его жить, просто поверх появляется второй.
• При replace с добавлением в стек экземпляр фрагмента остаётся жив, а его представление уничтожается: onPause, onStop, onDestroyView. onDestroy и onDetach не вызываются, поля объекта сохраняются.
• При возврате назад транзакция откатывается, и тот же экземпляр проходит onCreateView, onViewCreated, onStart, onResume. Иерархия представлений собирается заново, а состояние вьюх с идентификаторами, вроде текста поля и позиции прокрутки, восстанавливается системой.
• Без addToBackStack() при replace фрагмент уничтожается целиком, возврата к нему нет, кнопка «Назад» закроет экран.
• onSaveInstanceState при уходе в стек не вызывается: он про сохранение состояния при смене конфигурации и смерти процесса. Данные экрана держат в ViewModel, которая переживает и стек, и поворот.

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

Ждут, что фрагмент из стека вернётся с живым представлением, и трогают вьюхи или биндинг в промежутке между onDestroyView и новым onCreateView. Отсюда падения в колбэках, которые пришли, пока экран лежал в стеке. Биндинг обнуляют в onDestroyView именно поэтому.

Второе: подписываются на LiveData или Flow с владельцем this вместо viewLifecycleOwner. Фрагмент живёт дольше своего представления, поэтому после возврата из стека подписок становится две, и обработчик срабатывает дважды.

Третье: считают onCreate парным к onCreateView и кладут инициализацию в создание представления. При возврате из стека onCreate не вызывается, а onCreateView вызывается снова, и код отрабатывает повторно: лишние запросы в сеть, сброшенные фильтры, дубли в списке.