Как происходит сохранение и восстановление инстанса ViewModel

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

Знаете ли вы, за счёт чего ViewModel переживает поворот экрана и почему не переживает смерть процесса. Следом почти всегда спрашивают, как тогда не потерять ввод пользователя, и здесь нужен SavedStateHandle.

Как отвечать

Разведите два сценария.

Смена конфигурации. ViewModel лежит в ViewModelStore, которым владеет ViewModelStoreOwner: ComponentActivity, Fragment или запись бэкстека Navigation. При повороте Activity пересоздаётся, но стор передаётся новому экземпляру через onRetainNonConfigurationInstance. by viewModels() находит в сторе готовый объект по ключу. Когда владелец уходит насовсем (Activity завершена, фрагмент удалён), стор очищается и вызывается onCleared().

Смерть процесса. Приложение в фоне, система убила процесс, при возврате ViewModel создаётся заново. Выживает только сохранённый Bundle:

• SavedStateHandle: хранилище ключ-значение, приходит в конструктор ViewModel, пишется в SavedStateRegistry и восстанавливается после смерти процесса;
• getStateFlow(key, initial): реактивный доступ к значению, запись через set сразу попадает в сохранённое состояние;
• rememberSaveable: то же на уровне Compose для UI-состояния, которому не место в ViewModel.

В Bundle кладут мало: id, текст поиска, позицию. Сохранённый стейт идёт через Binder, и при превышении лимита приложение падает с TransactionTooLargeException. Крупные данные держат в Room или DataStore и перезагружают по сохранённому id.

Смерть процесса проверяют так: свернуть приложение и выполнить adb shell am kill <package>.

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

Говорят, что SavedStateHandle нужен для поворота экрана. Для поворота хватает самой ViewModel, handle нужен именно после смерти процесса.

Держат в ViewModel ссылку на Activity, View или контекст экрана. ViewModel живёт дольше Activity, и получается утечка; нужен контекст, берите AndroidViewModel с Application.

Кладут в SavedStateHandle список на тысячи элементов или картинку и получают падение при уходе в фон.