Почему используется Jetpack ViewModel в Android

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

Понимаете ли вы настоящую причину появления ViewModel: она переживает пересоздание экрана при смене конфигурации, а не просто «хранит данные». Заодно смотрят, знаете ли границу ответственности и что происходит при смерти процесса.

Как отвечать

Опишите механику. ViewModel хранится в ViewModelStore, привязанном к владельцу, поэтому поворот экрана уничтожает Activity, но не её ViewModel, и данные не перезапрашиваются. onCleared() вызывается только когда владелец уходит окончательно. Оттуда же берётся viewModelScope: корутины отменяются автоматически вместе с ViewModel, и это снимает целый класс утечек.

Вторая половина ответа про границы. ViewModel не знает про View, Activity и Context, состояние отдаёт наружу потоком, а экран его собирает: collectAsStateWithLifecycle в Compose, repeatOnLifecycle(STARTED) во View-мире. Так подписка живёт ровно пока экран виден.

Третье, что стоит сказать самому: ViewModel не переживает смерть процесса. Система может убить приложение в фоне, и после возврата пользователь получит пустой экран. Для этого есть SavedStateHandle, куда кладут минимум для восстановления, идентификатор, поисковый запрос, позицию.

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

Держат в ViewModel ссылку на Activity, Fragment или View. Это утечка ровно на тот срок, ради которого ViewModel и заводили: экран уничтожен, а ссылка на него жива до конца.

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

Запускают загрузку из жизненного цикла экрана. Вызов загрузки в onCreate после поворота повторяет запрос, хотя данные уже лежат в живой ViewModel, поэтому старт делают в самой ViewModel один раз. Обратная ошибка рядом: сбор потока в lifecycleScope.launch без привязки к состоянию продолжает работать, когда экран не виден, и обновляет то, чего нет.