В каких случаях View уничтожается, а Fragment живет? Зачем это может быть нужно?

Это происходит, когда:

▶️ Fragment переходит в состояние onDestroyView(), но не в onDestroy()

Пример:
При навигации внутри ViewPager (до ViewPager2) или при использовании фрагментов с FragmentTransaction().replace() / addToBackStack(), когда пользователь покидает экран, но Fragment остаётся в памяти, потому что:

Android освобождает ресурсы UI (View), но сохраняет сам Fragment, чтобы быстрее восстановить UI при возврате назад.

Инстанс Fragment-а всё ещё в back stack’е!

Почему это сделано? Зачем так нужно?

1. Экономия памяти
   View-иерархия может быть тяжёлой (особенно если в ней RecyclerView, картинки и т.п.). Когда Fragment не отображается, Android может уничтожить View, но оставить Fragment в памяти — он легче, особенно если в нём только бизнес-логика.
2. Сохранение бизнес-состояния / данных
   Fragment может содержать:
   • ссылки на ViewModel (через activityViewModels() или viewModels())
   • состояние, нужное при возвращении на экран
3. Плавный UX при возврате
   Когда пользователь возвращается назад (popBackStack()), Fragment может восстановить View, используя те же данные (из ViewModel или сохранённого состояния).

Вопрос на проверку: «Почему нельзя использовать binding после onDestroyView()?»

Потому что binding больше не ссылается на актуальную View!

Когда вызывается onDestroyView(), вся иерархия View фрагмента уничтожается. Если ты попытаешься использовать binding после этого (например, в onDestroy() или в callback’е корутины/LiveData), ты получишь:

1. ❗ IllegalStateException: View not attached to window manager
2. ❗ Потенциальную утечку памяти (если ты хранишь binding как val и не обнуляешь)
3. ❗ Доступ к null-ссылке или уже переприсвоенной View, если фрагмент пересоздался

Аналогия

Представь, что ты открыл Excel-файл, прочитал из него ссылки на ячейки, а потом удалил файл — попытка использовать эти ссылки приведёт к сбою. То же самое с binding.