Изменения состояния активности

Различные события, некоторые из которых инициируются пользователем, а некоторые — системой, могут привести к переходу Activity из одного состояния в другое. В этом документе описаны некоторые распространенные случаи, когда происходят такие переходы, и способы обработки этих переходов.

Для получения дополнительной информации о состояниях активности см. раздел «Жизненный цикл активности ». Чтобы узнать, как класс ViewModel может помочь вам управлять жизненным циклом активности, см. раздел «Обзор ViewModel» .

Для большинства изменений активности вам не нужно напрямую реагировать на коллбэки в жизненном цикле активности. Поскольку Compose перестраивает пользовательские интерфейсы на основе состояния, вы можете воспользоваться преимуществами автоматической рекомпозиции, убедившись, что состояние хранится в подходящем месте, например, rememberSaveable или ViewModel .

Произошло изменение конфигурации

Существует ряд событий, которые могут инициировать изменение конфигурации. Пожалуй, наиболее ярким примером является переключение между портретной и альбомной ориентацией. Другие случаи, которые могут вызвать изменение конфигурации, включают изменение языковых настроек или устройства ввода.

При изменении конфигурации активность уничтожается и создается заново. Это запускает следующие обратные вызовы в исходном экземпляре активности:

  1. onPause
  2. onStop
  3. onDestroy

Создается новый экземпляр активности, и запускаются следующие функции обратного вызова:

  1. onCreate
  2. onStart
  3. onResume

В Compose обычно не принято напрямую взаимодействовать с этими коллбэками. Вместо этого для отслеживания изменений состояния используется API жизненного цикла. В Compose вы можете использовать LocalLifecycleOwner.current , чтобы получить текущий жизненный цикл и добавить наблюдателя, позволяющего реагировать на события.

Для сохранения состояния пользовательского интерфейса активности при изменении конфигурации используйте комбинацию экземпляров ViewModel , rememberSaveable или постоянного локального хранилища. Выбор способа комбинирования этих вариантов зависит от сложности данных пользовательского интерфейса, сценариев использования вашего приложения и соотношения скорости получения данных и использования памяти. В большинстве случаев следует переносить состояние в ViewModel и использовать rememberSaveable , чтобы гарантировать сохранение состояния как при изменении конфигурации, так и при завершении процесса по инициативе системы. Дополнительную информацию о сохранении состояния пользовательского интерфейса активности см. в разделе «Сохранение состояний пользовательского интерфейса» .

При пересоздании активности из-за изменения конфигурации исходная композиция удаляется. Использование ViewModel или rememberSaveable гарантирует восстановление состояния пользовательского интерфейса в новой композиции.

Для получения дополнительной информации см. раздел «Жизненный цикл в Jetpack Compose» и «Состояние и Jetpack Compose» .

Обработка случаев с несколькими окнами

Когда приложение переходит в многооконный режим, доступный в Android 7.0 (уровень API 24) и выше, система уведомляет запущенное приложение об изменении конфигурации, проходя таким образом описанные ранее этапы жизненного цикла.

Такое поведение также наблюдается, если размер приложения, уже находящегося в многооконном режиме, изменяется. Ваше приложение может самостоятельно обработать изменение конфигурации или позволить системе уничтожить приложение и создать его заново с новыми размерами.

Для получения дополнительной информации о жизненном цикле многооконного режима см. описание жизненного цикла многооконного режима в разделе «Поддержка многооконного режима» .

В многооконном режиме, хотя пользователю видны два приложения, на переднем плане и в фокусе находится только то, с которым пользователь взаимодействует. Это приложение находится в состоянии «Возобновлено», в то время как приложение в другом окне находится в состоянии «Приостановлено».

Когда пользователь переключается с приложения A на приложение B, система вызывает onPause для приложения A и onResume для приложения B. Переключение между этими двумя методами происходит каждый раз, когда пользователь переключается между приложениями.

Для получения более подробной информации о многооконном режиме см. раздел «Поддержка многооконного режима» .

Действие или диалог отображаются на переднем плане.

Если на переднем плане появляется новое действие или диалог, которое захватывает фокус и частично закрывает текущее действие, то закрытое действие теряет фокус и переходит в состояние «Приостановлено». Затем система вызывает onPause для этого действия.

Когда выполняемая задача возвращается на передний план и снова получает фокус, система вызывает onResume .

Если на переднем плане появляется новое действие или диалог, захватывая фокус и полностью перекрывая текущее действие, перекрытое действие теряет фокус и переходит в состояние «Остановлено». Затем система быстро вызывает методы onPause и onStop .

Когда тот же самый экземпляр обрабатываемой активности возвращается на передний план, система вызывает onRestart , onStart и onResume для этой активности. Если в фоновый режим переходит новый экземпляр обрабатываемой активности, система не вызывает onRestart , а только onStart и onResume .

Перекомпозиция не зависит от диалоговых окон, отображаемых на переднем плане. Однако побочные эффекты, связанные с жизненным циклом, такие как потоки и анимации, должны использовать API, учитывающие жизненный цикл (например, collectAsStateWithLifecycle ), для автоматической приостановки и возобновления работы по мере необходимости. Для получения дополнительной информации см. State и Jetpack Compose .

Пользователь нажимает или делает жест назад

Если активность находится на переднем плане и пользователь нажимает кнопку «Назад» или использует жест «Назад», активность проходит через колбэки onPause , onStop и onDestroy . Активность уничтожается и удаляется из стека возврата.

В приложении с одной активностью, как и в большинстве приложений, использующих Compose, rememberSaveable не будет сохранять состояние, если компонент будет удален из стека навигации. Это связано с тем, что при нажатии кнопки «Назад» пользователь не ожидает возвращения к тому же экземпляру, поэтому все состояние очищается.

Для реализации пользовательского поведения при нажатии кнопки «Назад», например, отображения диалогового окна с запросом подтверждения пользователем выхода из приложения, используйте API NavigationEventHandler .

Система завершает процесс приложения.

Если приложение работает в фоновом режиме, и системе необходимо освободить память для приложения, работающего на переднем плане, система может завершить работу фонового приложения. При завершении работы приложения нет гарантии, что в этом приложении будет вызван onDestroy .

Чтобы узнать больше о том, как система принимает решение о том, какие процессы следует уничтожить, прочтите разделы «Состояние активности и извлечение из памяти» и «Процессы и жизненный цикл приложения» .

Чтобы узнать, как сохранить состояние пользовательского интерфейса вашей активности при завершении системой процесса приложения, см. раздел «Сохранение и восстановление временного состояния пользовательского интерфейса» .