Android lifecycle cheat sheet

The Android Lifecycle cheat sheet — part I: Single Activities

Android is designed to empower users and let them use apps in a intuitive way. For example, users of an app might rotate the screen, respond to a notification, or switch to another task, and they should be able to continue using the app seamlessly after such an event.

To provide this user experience, you should know how to manage component lifecycles. A component can be an Activity, a Fragment, a Service, the Application itself and even the underlying process. The component has a lifecycle, during which it transitions through states. Whenever a transition happens, the system notifies you via a lifecycle callback method.

To help us explain how lifecycles work, we’ve defined a series of scenarios which are grouped according to the components that are present:

Part I: Activities — single activity lifecycle (this post)

The diagrams are also available as a cheat sheet in PDF format for quick reference.

Note: these diagrams apply to Android P / Jetpack 1.0 behavior.

The following scenarios showcase the default behavior of the components, unless otherwise noted.

If you find errors or you think something important is missing, report it in the comments.

Part I: Activities

Single Activity — Scenario 1: App is finished and restarted

• The user presses the Back button, or
• The Activity.finish() method is called

The simplest scenario shows what happens when a single-activity application is started, finished and restarted by the user:

• onSaveInstanceState is not called (since the activity is finished, you don’t need to save state)
• onCreate doesn’t have a Bundle when the app is reopened, because the activity was finished and the state doesn’t need to be restored.

Single Activity — Scenario 2: User navigates away

• The user presses the Home button
• The user switches to another app (via Overview menu, from a notification, accepting a call, etc.)

In this scenario the system will stop the activity, but won’t immediately finish it.

When your activity enters the Stopped state, the system uses onSaveInstanceState to save the app state in case the system kills the app’s process later on (see below) .

Assuming the process isn’t killed, the activity instance is kept resident in memory, retaining all state. When the activity comes back to the foreground, the activity recalls this information. You don’t need to re-initialize components that were created earlier.

Single Activity — Scenario 3: Configuration changes

• Configuration changes, like a rotation
• User resizes the window in multi-window mode

Configuration changes like rotation or a window resize should let users continue exactly where they left off.

• The activity is completely destroyed, but the state is saved and restored for the new instance.
• The Bundle in onCreate and onRestoreInstanceState is the same.

Single Activity — Scenario 4: App is paused by the system

• Enabling Multi-window mode (API 24+) and losing the focus
• Another app partially covers the running app (a purchase dialog, a runtime permission dialog, a third-party login dialog…)
• An intent chooser appears, such as a share dialog

This scenario doesn’t apply to:

• Dialogs in the same app. Showing an AlertDialog or a DialogFragment won’t pause the underlying activity.
• Notifications. User receiving a new notification or pulling down the notification bar won’t pause the underlying activity.

Источник

The Android Lifecycle cheat sheet — part IV : ViewModels, Translucent Activities and Launch Modes

The diagrams are also in PDF format for quick reference.

ViewModels

The lifecycle of ViewModel s is quite simple: they have only one callback: onCleared . However, there’s a difference between scoping to an activity or to a fragment:

Note that the initialization happens whenever you obtain the ViewModel , which is normally done in onCreate .

Translucent Activities

Translucent activities have translucent (usually transparent) backgrounds so the user can still see what’s underneath.

When the property android:windowIsTranslucent is applied to an activity’s theme, the diagram changes slightly: the background activity is never stopped, only paused, so it can continue receiving UI updates:

Also, when coming back to a task, both activities are restored and started, and only the translucent is resumed:

Launch Modes

The recommended way to deal with tasks and the back stack is, basically: don’t — you should adopt the default behavior. For more details, read Ian Lake’s post about this topic: Tasks and Back Stack.

If you really need to use SINGLE_TOP , here’s its diagram:

For the sake of comparison, here’s what singleTask would look like (but you probably shouldn’t use it):

Note: If you use Jetpack’s Navigation Architecture Component, you will benefit from Single Top support and automatic synthetic back stack.

If you find errors or you think something important is missing, please report them in the comments. Also, let us know what other scenarios you would like us to write about.

Источник

Жизненный цикл Android-приложений

Авторизуйтесь

Жизненный цикл Android-приложений

Android проектировался таким образом, чтобы расширять возможности пользователей и сделать приложения интуитивно понятными. Например, пользователи приложения могут поворачивать экран, отвечать на уведомления и переключаться на другую задачу. Также у них есть возможность беспрепятственно продолжить работу с приложением после обработки какого-либо события.

Чтобы обеспечить такой UX, вам следует знать, как управлять жизненными циклами компонентов, таких как активности, фрагменты, сервисы, приложение в целом и так далее. Во время работы компонент проходит через состояния, определяемые его жизненным циклом. Система уведомляет о таких переходах через методы обратного вызова (callbacks).

Обратите внимание: Диаграммы описывают поведение в Android P / Jetpack 1.0.

Диаграммы показывают сценарии поведения по умолчанию, если не указано иное.

Жизненный цикл одной активности

Сценарий 1: завершение и повторный запуск приложения

Источники

• Нажатие кнопки «Back».
• Вызов метода Activity.finish() .

Этот простейший сценарий показывает, что происходит, когда приложение с одной активностью завершается и снова запускается пользователем:

Сценарий 1: приложение завершено и перезапущено

Управление состоянием

• onSaveInstanceState() не вызывается (активность завершается, поэтому не нужно сохранять её состояние);
• onCreate() не принимает Bundle, так как предыдущая активность завершилась и не требует восстановления.

Сценарий 2: переход пользователя из приложения

Источники

• Нажатие кнопки «Home».
• Переключение на другое приложение (через кнопку «Overview», ответ на уведомление, приём входящего вызова и т. п.).

Сценарий 2: пользователь покидает приложение

В этом случае система остановит активность, но не будет сразу же завершать её.

Управление состоянием

Когда активность входит в остановленное состояние, система вызывает onSaveInstanceState() для сохранения состояния приложения на случай, если она завершит процесс впоследствии.

17–19 декабря, Онлайн, Беcплатно

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

Сценарий 3: изменение конфигурации

Источники

• Смена конфигурации, например поворот экрана.
• Изменение размера окна в мультиоконном режиме.

Сценарий 3: поворот и другие изменения конфигурации

Управление состоянием

Изменения конфигурации вроде поворота и увеличения или уменьшения окна, должны позволять пользователям продолжать работу именно там, где они остановились:

• предыдущая активность полностью разрушается, но её состояние сохраняется и передаётся новой;
• в onCreate() и onRestoreInstanceState() передаётся один и тот же Bundle.

Сценарий 4: остановка приложения системой

Источники

• Вход в мультиоконный режим (API 24+) и потеря фокуса.
• Другое приложение, частично перекрывающее текущее (диалог покупки, запрос разрешения, сторонний диалог логина).
• Выбор Intent, например «Поделиться».

Сценарий 4 — остановка приложения системой

Сценарий не относится к следующим случаям:

• Диалоги в этом же приложении — показ AlertDialog или DialogFragment не приведёт к остановке активности.
• Уведомления — пользователь, получающий уведомление или открывающий их панель, не остановит активность.

Навигация и стек переходов

Примечание Показанные друг напротив друга группы событий отрабатываются параллельно. Поток выполнения может переключиться с одной группы событий на другую в любой момент времени, поэтому порядок вызовов методов из параллельных групп не определён. Однако последовательный порядок вызовов методов внутри группы гарантирован. Следующие сценарии не применяются к активностям и задачам с кастомным режимом запуска или заданным контекстом задачи (task affinity). За более подробной информацией обратитесь к документации на Android Developers.

Сценарий 1: навигация между активностями

Cценарий 1: завершение и повторный запуск приложения

В этом сценарии при старте новой активности первая останавливается (но не разрушается), что похоже на переход пользователя из приложения (по кнопке «Home»).

После нажатия на кнопку «Back» вторая активность разрушается и завершается.

Управление состоянием

Заметьте, что onSaveInstanceState() вызывается, а onRestoreInstanceState() — нет. Если изменение конфигурации произойдёт в то время, когда вторая активность открыта, то первая разрушится и будет снова создана, когда получит фокус обратно. Вот почему сохранение состояния важно.

Если система убьёт процесс для освобождения ресурсов, будет иметь место другой сценарий, в котором состояние потребуется восстановить.

Сценарий 2: активности в стеке переходов и изменения конфигурации

Сценарий 2: активности в стеке переходов и изменения конфигурации

Управление состоянием

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

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

Завершение процесса

Когда Android нуждается в ресурсах, он завершает фоновые приложения.

Сценарий 3: завершение процесса

Управление состоянием

Несмотря на то, что весь стек переходов сохраняется, в целях эффективного использования ресурсов системы активности восстанавливаются только тогда, когда они заново создаются.

Узнать больше можно здесь.

Жизненный цикл фрагментов

В этой части обсудим поведение прикреплённых к активности фрагментов. Не смущайтесь сценария с добавлением фрагмента в стек переходов назад (подробнее о транзакциях фрагментов и стеке переходов здесь).

Сценарий 1: запуск активности с фрагментом и её завершение

Сценарий 1: запуск активности с фрагментом и её завершение

Гарантировано, что вызов onCreate() активности выполнится раньше соответствующих вызовов фрагментов. Однако противолежащие методы обратного вызова, такие как onStart() и onResume() , выполняются параллельно, и поэтому порядок их вызовов не определён. Например, система может выполнить метод onStart() активности перед методом onStart() фрагмента, но выполнить метод onResume() фрагмента перед методом onResume() активности.

Примечание Будьте осторожны при управлении потоками выполнения и избегайте состояния гонки.

Сценарий 2: поворот активности с фрагментом

Сценарий 2: поворот действия с фрагментом

Управление состоянием

Сохранение и восстановление фрагментов очень похоже на сохранение и восстановление активностей. Различие заключается в том, что у фрагментов нет метода onRestoreInstanceState() , но им доступен Bundle в методах onCreate() , onCreateView() и onActivityCreated() .

Фрагменты могут быть сохранены, то есть при изменении конфигурации активности будет использоваться один и тот же экземпляр фрагмента.

Сценарий 3: поворот активности с сохранённым фрагментом

Сценарий 3: поворот активности с сохранённым фрагментом

После поворота фрагмент не разрушается и не воссоздаётся, потому что после пересоздания активности используется тот же экземпляр фрагмента — при этом в onActivityCreated() всё ещё доступен объект состояния.

Не рекомендуется применять сохраняемые фрагменты, если они не используются для сохранения данных между изменениями конфигурации (в не UI-фрагменте). Класс ViewModel из библиотеки Architecture Components внутри реализован именно так, но он предоставляет более простой API.

ViewModels, полупрозрачные активности и режимы запуска

Модели представления (ViewModels)

Жизненный цикл модели представления достаточно простой — она имеет всего один метод обратного вызова, который называется onCleared() . Тем не менее, для модели представления есть различие между активностью и фрагментом:

Различие между активностью и фрагментом

Стоит обратить внимание, что инициализация случается всякий раз, когда вы получаете ViewModel , что обычно происходит в onCreate() .

Полупрозрачные активности

Из названия понятно, что у полупрозрачной активности полупрозрачный фон (как правило, совсем прозрачный). Таким образом, пользователь видит, что находится под ней.

Когда к теме активности применяется свойство android:windowIsTranslucent , диаграмма немного меняется: фоновая активность никогда не останавливается (только входит в состояние паузы), так что она может продолжать получать обновления UI:

Сравнение обычной и полупрозрачной активностей

Также при возвращении обратно к задаче, обе активности восстанавливаются и запускаются, и только полупрозрачная возобновляется:

Новая полупрозрачная активность: выход из приложения и повторное открытие

Режимы запуска

Рекомендованный способ работы с задачами и стеками переходов в своей основе прост — вы должны следовать поведению по умолчанию. За подробной информацией обратитесь к статье.

Если вам действительно нужен режим SINGLE_TOP , вот диаграмма:

Для сравнения посмотрите на следующей диаграмме режим singleTask (но, скорее всего, вам не нужно его использовать):

Если вы используете Navigation Architecture из Jetpack, то получите выгоду от поддержки Single Top и автоматического искусственного стека переходов.

Источник