Какие методы жизненного цикла фрагмента в Android существуют и в каком порядке вызываются

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

Знаете ли вы актуальный жизненный цикл из AndroidX, а не схему десятилетней давности, и понимаете ли, что у фрагмента и его представления разные жизни. Следом почти всегда спрашивают, что вызовется, когда фрагмент заменили с добавлением в back stack, а потом вернулись назад.

Как отвечать

Порядок при создании и показе:

• onAttach(): фрагмент привязан к хосту, доступен context;
• onCreate(): инициализация без разметки, чтение аргументов;
• onCreateView(): создание разметки. Если передать id разметки в конструктор Fragment(R.layout.screen), переопределять его не нужно;
• onViewCreated(): разметка готова, здесь настраивают view binding, слушатели и подписки;
• onViewStateRestored(): восстановлено состояние view;
• onStart() и onResume(): фрагмент виден, затем доступен для взаимодействия.

При уходе обратный порядок: onPause(), onStop(), при необходимости onSaveInstanceState(), затем onDestroyView(), onDestroy(), onDetach().

onActivityCreated() устарел: вместо него используют onViewCreated(), а на события активности подписываются через её lifecycle.

Главное, что стоит сказать: при replace с addToBackStack() старый фрагмент доходит только до onDestroyView(). Сам объект жив, а при возврате снова вызываются onCreateView() и onViewCreated(). Поэтому у фрагмента есть отдельный viewLifecycleOwner, который живёт от onCreateView() до onDestroyView(), и подписки на LiveData или сбор Flow через repeatOnLifecycle привязывают к нему.

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

Называют onActivityCreated() обязательным шагом. Метод устарел, и ответ выдаёт подготовку по старым материалам.

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

Хранят ссылку на binding после onDestroyView(). Фрагмент в back stack держит уничтоженное дерево view, это утечка памяти. Ссылку обнуляют в onDestroyView().