Какие способы сохранения состояния в Android существуют

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

Различаете ли вы три разных сценария: смену конфигурации, убийство процесса системой и обычный перезапуск приложения. Кандидаты часто валят их в одну кучу и предлагают SharedPreferences на всё. Следом спрашивают, что переживёт смерть процесса в фоне и как вы это проверяли.

Как отвечать

Разложите способы по времени жизни данных:

• смена конфигурации (поворот, тема, размер окна): ViewModel держит данные в памяти, пока жив её владелец. В Compose ту же роль на уровне UI играет remember, но он пересоздание не переживает, поэтому нужен rememberSaveable;
• смерть процесса в фоне: система возвращает сохранённый Bundle. Это onSaveInstanceState во вьюшном мире и SavedStateHandle в ViewModel, куда в итоге пишет и rememberSaveable. Сюда кладут идентификаторы, фильтры, позицию скролла, а не сами данные;
• между запусками приложения: DataStore для настроек (Preferences или Proto, вместо устаревшего SharedPreferences), Room поверх SQLite для структурированных данных, файлы в filesDir и cacheDir для крупного, Android Keystore для секретов.

Сформулируйте принцип: единственный источник правды это репозиторий и база, а сохранённое состояние экрана лишь помогает его восстановить. Удобно, что SavedStateHandle умеет отдавать StateFlow, и параметры запроса легко связать с загрузкой данных.

Про проверку скажите отдельно: опция «Не сохранять активности» в настройках разработчика и adb shell am kill показывают, что вы реально тестировали смерть процесса, а не только крутили экран.

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

Считают, что ViewModel переживает всё. Он переживает поворот, но не убийство процесса и не закрытие экрана пользователем.

Кладут в Bundle список из сотен объектов и ловят TransactionTooLargeException: транзакция Binder ограничена примерно мегабайтом на весь процесс.

Хранят в SharedPreferences то, чему место в базе, и вызывают commit() на главном потоке, получая фризы вместо асинхронного apply() или DataStore.