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

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

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

На заметку! ОС Android запускает каждое приложение в отдельном процессе, каждый из которых содержит собственную виртуальную машину. Это обеспечивает наличие среды с защищенной памятью. Изолируя приложения в отдельных процессах, система может определять, какому из приложений назначить более высокий приоритет. К примеру, фоновый процесс, который выполняет интенсивно загружающую процессор задачу, не должен блокировать входящий телефонный звонок.

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

Рассмотрим типичный сценарий. Пользователь разговаривает с кем-то по телефону, и ему для ответа на заданный вопрос понадобилось открыть почтовое сообщение. Он переходит на домашний экран, открывает почтовое приложение, щелкает на ссылке и, прочитав биржевую котировку на веб-странице, отвечает на вопрос друга. В этой ситуации должны работать четыре приложения: домашнее приложение, приложение телефонного разговора, почтовое приложение и приложение браузера. При переходе пользователя от одного приложения к другому никаких проблем для него не возникает. Однако при этом система сохраняет и восстанавливает состояния приложений. Например, когда пользователь щелкает на ссылке в почтовом сообщении, система сохраняет метаданные выполняющейся активности почтового сообщения, а уже затем запускает активность приложения браузера для перехода по URL. В действительности система сохраняет метаданные любой активности перед запуском другой, чтобы иметь возможность впоследствии вернуться (например, при возврате пользователя по цепочке переходов). Если возникает проблема с памятью, системе придется закрыть процесс, выполняющий активность, а затем при необходимости возобновить его.