Памятка по жизненному циклу Android — часть I. Отдельные Activity
Android спроектирован так, чтобы использование приложения пользователем было максимально интуитивным. Например, пользователи приложения могут повернуть экран, ответить на уведомление или переключиться на другое приложение, и после этих манипуляций они все так же должны иметь возможность продолжить использовать приложение без каких-либо проблем.
Чтобы обеспечить такое взаимодействие с пользователем, вы должны знать, как управлять жизненными циклами компонентов. Компонентом может быть Activity, Fragment, Service, класс Application и даже сам процесс приложения. Компонент имеет жизненный цикл, в течение которого он проходит через различные состояния. Всякий раз, когда происходит переход, система уведомляет вас об этом при помощи методов жизненного цикла.
Чтобы нам было легче объяснить, как работает жизненный цикл в Android, мы определили несколько сценариев (примеров из жизни), которые сгруппированы по компонентам:
Часть 1: Activity — ЖЦ одного активити (этот пост)
Диаграммы также доступны в виде шпаргалки в формате PDF для краткого ознакомления.
Примечание: эти диаграммы соответствуют поведению в Android P/Jetpack 1.0.
Следующие сценарии демонстрируют поведение компонентов по умолчанию, если не указано иное.
Если вы обнаружили ошибки в статье или считаете, что не хватает чего-то важного, напишите об этом в комментариях.
Часть 1: Activity
Пользователь нажимает кнопку Назад или
Вызван метод Activity.finish()
Самый простой сценарий показывает, что происходит, когда приложение с одним активити запускается, завершается и перезапускается пользователем:
Управление состоянием
onSaveInstanceState не вызывается (поскольку активити завершено, вам не нужно сохранять состояние)
onCreate не имеет Bundle при повторном открытии приложения, потому что активити было завершено и состояние не нужно восстанавливать.
Пользователь нажимает кнопку «Домой»
Пользователь переключается на другое приложение (через меню «Все приложения», из уведомления, при принятии звонка и т. д.)
В этом случае система остановит активити, но не завершит его сразу.
Управление состоянием
Когда ваше активити переходит в состояние Stopped, система использует onSaveInstanceState для сохранения состояния приложения на тот случай, если впоследствии система завершит процесс приложения (см. ниже).
Предполагая, что процесс не был убит, экземпляр активити сохраняется в памяти, сохраняя все состояние. Когда активити возвращается на передний план, вам не нужно повторно инициализировать компоненты, которые были созданы ранее.
Изменена конфигурация, такие как поворот экрана
Пользователь изменил размер окна в многооконном режиме
Управление состоянием
Изменения конфигурации, такие как поворот или изменение размера окна, должны позволить пользователям продолжить работу с того места, где они остановились.
Активити полностью уничтожено, но состояние сохраняется и восстанавливается при создании нового экземпляра.
Включён многооконный режим (API 24+) и потерян фокус
Другое приложение частично покрывает работающее приложение: диалоговое окно покупки (in-app purchases), диалоговое окно получения разрешения (Runtime Permission), стороннее диалоговое авторизации и т. д.
Появится окно выбора приложения (при обработке неявного интента), например диалоговое окно шейринга.
Этот сценарий не применим к:
Диалогам в том же приложении. Отображение AlertDialog или DialogFragment не приостанавливает базовое активити.
Уведомлениям. Пользователь, получающий новое уведомление или открывающий панель уведомлений, не приостанавливает текущее активити.
Activity (Активность, Операция)
Одна из активити может быть отмечена как основная (или главная) и тогда она будет появляться первой при запуске приложения. А уже из нее можно запустить другие активити. Причем не только те, которые принадлежат текущему приложению, но и активити из других приложений. Может показаться, что все запускаемые активити являются частями одного приложения. На самом же деле они могут быть определены в разных приложениях и работать в разных процессах.
Создание новой активити
После этого класс, разметка, а также запись в манифесте будут добавлены автоматически.
Настройка активити в манифесте
Рассмотрим более подробно, какую информацию нужно или можно добавлять для элемента в манифесте.
Объявление активити
Помимо обязательного атрибута существуют и другие, с помощью которых каждой активити можно задать уникальные заголовок, иконку, тему и многие другие характеристики. Подробнее с ними можно ознакомиться в моей статье про манифест или в официальной документации.
Объявление intent-фильтров
Скорее всего данная тема будет не особо понятна новичкам, поэтому сначала рекомендую ознакомиться с тем, что такое Intent.
Если у приложения отсутствуют intent-фильтры, то запустить его можно будет только с помощью явного Intent (по имени класса).
Например, активити можно добавить intent-фильтр, который будет говорить, что она умеет отправлять данные.
Выше упоминалось, что активити можно отметить как основную. Это тоже осуществляется с помощью intent-фильтра.
Объявление разрешений
С помощью разрешений можно контролировать, какие приложения могут запускать активити. При этом одна активити не сможет запустить другую, если они не имеют одинаковых разрешений в манифесте.
Например, ваше приложение хочет использовать приложение SocialApp для публикации какой-либо информации в социальных сетях. Приложение SocialApp должно определить разрешение:
И чтобы иметь возможность запускать SocialApp вы должны в своем приложении добавить идентичное разрешение:
Жизненный цикл
При использовании приложения мы постоянно перемещаемся от одного экрана к другому и обратно. Поэтому все активити, с которыми мы взаимодействуем постоянно меняют состояние своего жизненного цикла. А чтобы узнать о смене состояния существуют методы обратного вызова. Т.е. как только активити перешла в другое состояние, сразу же вызывается соответствующий метод обратного вызова. Таким образом можно отслеживать смену состояния и реагировать на него.
Для чего это делать? Чтобы избежать следующих ситуаций:
Это вовсе не означает, что каждый раз нужно реализовывать все методы обратного вызова. Требуется лишь понять для чего каждый из них предназначен, чтобы использовать их в нужный момент.
Методы обратного вызова
onCreate()
Вызывается при создании и перезапуске активити. После создания активити она переходит в состояние “Создана” (Created state), но существует в нём недолго. Как только метод onCreate() будет выполнен, активити переходит в статус “Запущена” (Started state).
Что в нём должно происходить:
Выполнение базовой логики запуска приложения, которая должна происходить только один раз за весь период действия. Например, создание пользовательского интерфейса, привязка данных, создание сервисов (service) и потоков.
onStart()
Также этот метод делает активити видимой для пользователя, но с ней еще нельзя взаимодействовать.
Что в нём должно происходить:
Выполнение кода, который поддерживает пользовательский интерфейс
Следующий метод:
onResume()
onResume()
Следующий метод:
onPause()
onPause()
Вызывается, когда активити теряет фокус и переходит в состояние “Приостановлена” (Paused state). Т.е. активити больше не находится на переднем плане, хотя может быть всё ещё видна пользователю.
Завершение работы метода onPause() не означает, что активити перейдёт в другое состояние. Она будет оставаться в состоянии “Приостановлена” до тех пор, пока либо не перейдёт обратно на передний план (вызовется метод onResume() ), либо пока полностью не станет невидимой (вызовется метод onStop() ).
Что в нём должно происходить:
Приостановка или настройка операций, которые не должны продолжаться пока активити находится в состоянии “Приостановлена”, но ожидается, что вы вскоре их возобновите.
Код должен быть легковесным, так как нет гарантии, что он успеет выполнится.
onStop()
Вызывается, когда активити больше не видна пользователю и переходит в состояние “Остановлена”. Это может произойти, если активити уничтожается, запускается новая активити или возобновляет работу существующая активити, закрывая собой текущую. Несмотря на это, активити остаётся в памяти, но она больше не привязана к диспетчеру окон.
Из состояния “Остановлена” активити либо возвращается к взаимодействию с пользователем (вызывается метод onRestart() ), либо завершается (вызывается метод onDestroy() ).
Что в нём должно происходить:
Остановка функций, работа которых не нужна пока активити невидима для пользователя. Например, остановка анимаций, сохранение информации в базе данных.
onRestart()
Вызывается, когда активити в состоянии “Остановлена” повторно отображается пользователю.
Что в нём должно происходить:
Выполнение действий, которые должны выполняться при повторном запуске активити в рамках одного жизненного цикла приложения.
onDestroy()
Следующий метод:
Последний метод жизненного цикла.
Схема состояний активити
Исходя из вышеописанного можно сделать простенькую схему для лучшего понимания того, как активити переходит из одного состояния своего жизненного цикла в другое. Я делаю акцент именно на состояниях (а не на методах обратного вызова), потому что на мой взгляд это легче для восприятия (особенно новичкам).
Разбираемся с launchMode Android Activity: standard, singleTop, singleTask и singleInstance
Activity — это одна из самых ярких концепций в Android (самой популярной мобильной операционной системе с хорошо продуманной архитектурой управления памятью, которая отлично реализует многозадачность).
Так или иначе, с запуском Activity на экран не все так однозначно. Способ, которым оно было запущено, также важен. Нюансов в этой теме очень много. Одним из действительно важных является launchMode, о котором мы и поговорим в этой статье.
Каждое Activity создается для работы с разными целями. Некоторые из них предназначены для работы отдельно с каждым Intent, например, отправленным Activity для составления электронной почты в почтовом клиенте. В то время как другие предназначены для работы в качестве синглтона, например, Activity почтового ящика.
Вот почему важно указывать, нужно ли создавать новое Activity или использовать существующее, иначе это может привести к плохому UX или сбоям. Благодаря разработчикам ядра Android, это легко сделать с помощью launchMode, который был специально для этого разработан.
Определение launchMode
По сути, мы можем определить launchMode напрямую в качестве атрибута тега activity> в AndroidManifest.xml :
Доступно 4 типа launchMode. Давайте рассмотрим их по очереди.
Это режим «по умолчанию».
Поведение Activity, установленного в этот режим, будет всегда создавать новую Activity, чтобы работать отдельно с каждым отправленным Intent. По сути, если для составления электронного письма отправлено 10 Intent-ов, должно быть запущено 10 Activity, чтобы обслуживать каждый Intent отдельно. В результате на устройстве может быть запущено неограниченное количество таких Activity.
Поведение на пре-Lollipop Android
Этот вид Activity будет создан и помещен в верх стека в той же задаче, которая и отправила Intent.
На рисунке ниже показано, что произойдет, когда мы поделимся изображением со стандартным Activity. Оно будет расположено в стеке в той же задаче, как описано выше, хотя они из разных приложений.
А это то, что вы увидите в диспетчере задач. (Может показаться немного странным)
Если мы переключим приложение на другую задачу, а затем переключимся обратно в Галерею, мы все равно увидим, что стандартный launchMode помещается поверх задачи Галереи. В результате, если нам нужно что-то сделать в Галерее, мы должны сначала закончить нашу работу в этом дополнительном Activity.
Поведение на Lollipop Android
Если эти Activity относятся к одному и тому же приложению, поведение будет таким же, как и в пре-Lollipop реализации — размещение в стеке поверх задачи.
Но в случае, если Intent отправлен из другого приложения, будет создана новая задача и вновь созданное Activity будет размещено в качестве корневого, как показано ниже.
Это то, что вы увидите в диспетчере задач.
Это происходит потому, что в Lollipop модифицирована система управления задачами — она стала лучше и понятнее. В Lollipop вы можете просто переключиться обратно в Галерею, поскольку она находится в другой задаче. Вы можете отправить другой Intent, будет создана новая задача, которая будет обслуживать Intent так же, как и предыдущая.
Примером такого вида Activity является Compose Email Activity (составление письма) или Social Network’s Status Posting Activity (обновление статуса в соцсети). Если у вас на уме Activity, которое отдельно обрабатывает каждый Intent, то вы думаете именно о standard Activity.
singleTop
Пример использования этого режима — функция поиска. Давайте подумаем о создании окна поиска, которое направляет вас к SearchActivity, чтобы увидеть результаты поиска. Для лучшего UX обычно мы всегда помещаем окно поиска на страницу результатов поиска, чтобы позволить пользователю выполнить следующий поиск, не возвращаясь назад.
А теперь представьте, что если мы всегда запускаем новое SearchActivity, чтобы обслуживать новый результат поиска, то мы получим 10 новых Activity для 10 итераций поиска. Было бы очень странно возвращаться назад, так как вам нужно было бы нажимать назад 10 раз, чтобы пройти через все результаты поиска, чтобы вернуться к корневой Activity.
Вместо этого, если SearchActivity уже находится наверху стека, лучше отправить Intent в существующий экземпляр Activity и позволить ему обновить результат поиска. Теперь будет только одно SearchActivity, размещенное наверху стека, и вы можете просто нажать кнопку «Назад» один раз, чтобы вернуться к предыдущему Activity. В этом больше смысла.
В любом случае singleTop работает в той же задаче, что и вызывающая сторона. Если вы ожидаете, что Intent будет отправлен в существующее Activity, помещенное поверх любой другой задачи, я должен вас разочаровать, сказав, что там это так уже не работает. В случае, если Intent отправлен из другого приложения в singleTop Activity, новое Activity будет запущено в том же аспекте, что и для standart launchMode (пре-Lollipop: помещено поверх вызывающей задачи, Lollipop: будет создана новая задача).
singleTask
Работая в одном приложении
Если в системе еще не было экземпляра singleTask Activity, будет создан новый, и он будет просто помещен вверх стека в той же задаче.
Это не имеет смысла с точки зрения пользовательского опыта, но оно он разработано именно таким образом…
Вы можете заметить один нюанс, который упоминается в документации:
Система создает новую задачу и инстанцирует экземпляр activity в корне новой задачи.
Если вы хотите, чтобы singleTask Activity вело себя так, как описано в документе: создайте новую задачу и поместите Activity в качестве корневого Activity. Вам нужно определить атрибут taskAffinity для singleTask Activity следующим образом.
Ваша задача решить, использовать taskAffinity или нет в зависимости от желаемого поведения Activity.
Взаимодействуя с другим приложением
Как только Intent отправлен из другого приложения, и в системе еще не создано ни одного экземпляра Activity, будет создана новая задача с новым Activity, размещенным в качестве корневого Activity.
Если не существует задачи, которая бы являлась владельцем вызывающей singleTask Activity, вместо нее будет выведено наверх новое Activity.
В случае, если в какой-либо задаче существует экземпляр Activity, вся задача будет перемещена вверх, и для каждого отдельного Activity, расположенного над singleTask Activity, будет завершен жизненный цикл. Если нажата кнопка «Назад», пользователь должен пройти через Activity в стеке, прежде чем вернуться к вызывающей задаче.
Примером использования этого режима является любое Entry Point Activity, например, страница «Входящие» почтового клиента или таймлайн соцсети. Эти Activity не предполагают более чем одного экземпляра, поэтому singleTask отлично справится со своей задачей. В любом случае вы должны использовать этот режим с умом, так как в этом режиме Activity могут быть уничтожены без подтверждения пользователя, как описано выше.
singleInstance
Этот режим очень похож на singleTask, где в системе мог существовать только один экземпляр Activity. Разница в том, что задача, которая располагает этим Activity, может иметь только одно Activity — то, у которого атрибут singleInstance. Если из этого вида Activity вызывается другое Activity, автоматически создается новое задание для размещения этого нового Activity. Аналогичным образом, если вызывается singleInstance Activity, будет создана новая задача для размещения этого Activity.
Вот что происходит, когда вызывается singleInstance Activity, в то время как в стеке уже существует какое-либо Activity.
А вот что мы видим в диспетчере задач.
Поскольку эта задача может иметь только одно Activity, мы больше не можем переключаться обратно на задачу № 1. Единственный способ сделать это — перезапустить приложение из лаунчера, но, как в итоге получится, singleInstance задача будет скрыта в фоновом режиме.
Во всяком случае, есть некоторые обходные пути для этой проблемы. Как и в случае с singleTask Activity, просто назначьте атрибут taskAffinity для singleInstance Activity, разрешающим существование нескольких задач в диспетчере задач.
Теперь картина имеет больше смысла.
Этот режим используется редко. Некоторые из вариантов использования на практике — это лаунчер-Activity или приложение, для которого вы на 100% уверены, что там должно быть только одно Activity. В любом случае, я предлагаю вам не использовать этот режим, если на то нет крайней необходимости.
Intent-флаги
запустит StandardActivity с условием singleTop launchMode.
Есть довольно много флагов, с которыми вы можете работать. Вы можете найти больше информации об этом здесь.
Activity
Activity и жизненный цикл приложения
Жизненный цикл приложения
Все приложения Android имеют строго определенный системой жизненный цикл. При запуске пользователем приложения система дает этому приложению высокий приоритет. Каждое приложение запускается в виде отдельного процесса, что позволяет системе давать одним процессам более высокой приоритет, в отличие от других. Благодаря этому, например, при работе с одними приложениями Android позволяет не блокировать входящие звонки. После прекращения работы с приложением, система освобождает все связанные ресурсы и переводит приложение в разряд низкоприоритетного и закрывает его.
После запуска activity проходит через ряд событий, которые обрабатываются системой и для обработки которых существует ряд обратных вызовов:
Схематично взаимосвязь между всеми этими обратными вызовами можно представить следующим образом
onCreate()
onStart
onResume
При вызове метода onResume activity переходит в состояние Resumed и отображается на экране устройства, и пользователь может с ней взаимодействовать. И собственно activity остается в этом состоянии, пока она не потеряет фокус, например, вследствии переключения на другую activity или просто из-за выключения экрана устройства.
onPause
onStop
В этом методе activity переходит в состояние Stopped. В этом состоянии activity полностью невидима. В методе onStop следует особождать используемые ресурсы, которые не нужны пользователю, когда он не взаимодействует с activity. Здесь также можно сохранять данные, например, в базу данных.
При этом во время состояния Stopped activity остается в памяти устройства, сохраняется состояние всех элементов интерфейса. К примеру, если в текстовое поле EditText был введен какой-то текст, то после возобновления работы activity и перехода ее в состояние Resumed мы вновь увидим в текстовом поле ранее введенный текст.
onDestroy
В целом переход между состояниями activity можно выразить следующей схемой:
Управление жизненным циклом
Мы можем управлять этими событиями жизненного цикла, переопределив соответствующие методы. Для этого возьмем из прошлой главы класс MainActivity и изменим его следующим образом:
И при запуске приложения мы сможем увидеть в окне Logcat отладочную информацию, которая определяется в методах жизненного цикла activity:
Activity (Активность, Деятельность)
Что такое Activity
Разработчики со стажем могут воспринимать Активность как форму. Простые приложения состоят из одной активности. Более сложные приложения могут иметь несколько окон, т.е. они состоят из нескольких активностей, которыми надо уметь управлять и которые могут взаимодействовать между собой.
Активность, которая запускается первой, считается главной. Из нее можно запустить другую активность. Причем не только ту, которая относится к нашему приложению, но и другого приложения. Пользователю будет казаться, что все запускаемые им активности являются частями одного приложения, хотя на самом деле они могут быть определены в разных приложениях и работают в разных процессах. Попробуйте воспринимать активности как страницы разных сайтов, открываемых в браузерах по ссылке.
Обычно активность занимает весь экран устройства, но это не является обязательным требованием. Вы можете создавать полупрозрачные и плавающие окна активностей. И с развитием Android такой подход набирает обороты.
Чтобы создать активность, нужно унаследоваться от класса Activity и вызвать метод onCreate(). В результате мы получим пустой экран. Толку от такого экрана никакого. Поэтому в активность добавляют компоненты, фрагменты с помощью разметки.
Жизненный цикл активности
Активность имеет жизненный цикл — начало, когда Android создает экземпляр активности, промежуточное состояние, и конец, когда экземпляр уничтожается системой и освобождает ресурсы. Активность может находиться в трех состояниях:
Если активность, которая была уничтожена системой, нужно снова показать на экране, она должна быть полностью перезапущена и восстановлена в своем предыдущем состоянии.
Активность в виде диалогового окна
Помните, изучая темы, мы создали вторую активность в виде диалогового окна. С таким же успехом вы можете создать окно и для основной активности. Добавим в манифесте для активности строчку:
Напишем код для запуска:
Обратите внимание, что в данном примере мы не используем разметку, а программно создаём экземпляр класса TextView с необходимыми свойствами (текст, отступы) и передаём его в метод setContentView().
Програмнное создание активности
В основном мы пользуемся XML-разметкой для формирования внешнего вида активности. Это рекомендованный способ и в 99% вы будете использовать именно его. Но в некоторых случаях возможно вам понадобится создать активность программно. Сложного там ничего нет, для общего развития пригодится.
Если в стандартном случае мы подключаем XML-файл в методе setContentView(R.layout.activity_main), то при программном создании данный метод нам не понадобится. Удаляем его и пишем код:
В данном примере мы также присваиваем компонентам идентификаторы через метод setId(), хотя необходимости в этом не было. В примере эта возможность показана для демонстрации. Если вы используете идентификаторы, то в файле res/values/stings.xml добавьте строчки:
Обычно опытные программисты создают отдельный файл для идентификаторов, например, res/values/ids.xml.
Классы Activity в Android
Android SDK включает набор классов, наследованных от Activity. Они предназначены для упрощения работы с виджетами, которые часто встречаются в обычном пользовательском интерфейсе. Перечислим некоторые из них (наиболее полезные).