Внутреннее устройство Android-приложения

Для разработки Android-приложений предоставляется четыре строительных блока, которые можно использовать в сочетании друг с другом. Информация о том, какие из этих блоков будут использованы в конкретном приложении, хранится в файле манифеста AndroidManifest.xml. Ниже эти блоки представлены в графическом виде.

Кратко рассмотрим назначение каждого из блоков.

Activity (Действие)

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

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

Для перемещения между экранами используется специальный класс Intent (Намерение), который описывает, какие действия хочет выполнить приложение. Наиболее важными составными частями намерения являются действие и данные, над которыми это действие выполняется. Например, чтобы посмотреть контактную информацию конкретного человека, вам нужно создать намерение, действием для которого будет VIEW (Просмотр), а данными – идентификатор этого человека, называемый URI (Uniform Resource Identifier – унифицированный идентификатор ресурса).

Как было сказано выше, Intent нужно для указания действий, которые хочет выполнить приложение. А для того, чтобы Activity знало, как реагировать на эти действия, используется класс IntentFilter (фильтр намерений). Например, чтобы на экран можно было вывести контактную информацию о человеке, нужно опубликовать IntentFilter, который сообщит экрану, как обрабатывать действием VIEW связанные с ним данные о человеке. Все действия публикуют свои фильтры намерений в файле манифеста.

Таким образом, когда приложению нужно что-либо сделать, вы вызываете экран с нужным вам намерением (например, просмотр контактных данных). Т.е. ОС просматривает фильтры намерений всех приложений и отбирает тот экран, чьи фильтры намерений лучше всего соответствуют указанному вами намерению. Отобранное Activity сообщает вызвавшему её намерению о том, что оно запустилось. С этого момента намерение считается разрешенным (выполненным).

Intent Receiver (Приёмник намерений)

IntentReceiver используется, когда вы хотите, чтобы ваше приложение реагировало на внешние события, например, звонок телефона. Приёмник намерений не имеет пользовательского интерфейса, но он может использовать менеджер извещений, чтобы оповестить пользователя, когда что-либо произошло. Приёмники намерений также регистрируются в файле манифеста, но есть возможность опубликовать их и непосредственно в коде программы с помощью метода registerReceiver абстрактного класса Context. Вам не нужно самому запускать программу, когда произошло какое-либо внешнее событие. Как только IntentReceiver прореагирует на возникшее событие, ОС сама запустит ваше приложение. Намерения, которые реализует ваша программа, также могут быть внешними событиями для остальных приложений, т.е. IntentReceiver аналогичным способом будет реагировать на ваши события, как и в случае с другими внешними событиями. Это реализуется методом broadcastIntent того же метода Context.

Service (Служба)

Служба - это компонент приложения, который позволяет работать ему в фоновом режиме без использования интерфейса пользователя, например фоновое проигрывание музыки. Служба будет работать, пока вы ее не остановите. Таким образом, вы можете слушать музыку и работать с другими приложениями одновременно. Также вы можете управлять службой (например, поставить на паузу или остановить проигрывание музыки) при помощи метода bindService класса Context.

Content Provider (Контент-провайдер)

Программы могут хранить свои данные в файлах, базах данных SQLite и т.п. Контент-провайдеры служат удобным механизмом, посредством которого данные ваших приложений могут совместно использоваться другими приложениями. Класс ContentProvider реализует множество методов для работы с данными (сохранение, поиск и т.п.).

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

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

Вы должны ясно понимать, что при использовании различных компонентов приложения (Activity, Service, IntentReceiver) очень сложно воздействовать на время жизни процесса этого приложения. Если использовать эти компоненты не правильно, это может привести к уничтожению процесса, выполняющего какие-либо важные функции.

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

1. Активный процесс имеет наивысший приоритет важности. Он владеет действием (экраном), которое активно в данный момент (был вызван метод onResume), или текущим исполняемым приёмником намерений (был вызван метод onReceiveIntent). Завершение данного типа процесса практически исключено, это возможно только в случае очень маленького объема памяти в системе.
2. Видимый процесс владеет действием, видимым для пользователя, но не активным в данный момент (был вызван метод onPause). Это особенно заметно, если активное действие отображается в виде диалога, что позволяет видеть другие действия, находящиеся за ним. Такой тип процесса очень важен и не будет уничтожен, если он требуется для работы активного процесса.
3. Процесс службы владеет службой, которая была запущена методом startService. Несмотря на то, что эти службы не видны пользователю (фоновое проигрывание музыки или скачивание файлов из сети), они всегда будут выполняться до тех пор, пока не будет достаточно памяти для активных и видимых процессов.
4. Фоновый процесс владеет действием, котором не видно в данный момент для пользователя (был вызван метод onStop). Этот тип процесса не взаимодействует напрямую с пользователем. Система может уничтожить такой процесс в любой момент и освободить память для трех вышеприведенных типов процессов. Если в системе выполняются множество таких фоновых процессов, система помещает их в список LRU (Least Recently Used, неиспользовавшихся дольше всех). При малом количестве памяти уничтожен будет последний процесс из этого списка.
5. Пустой процесс не имеет активных компонентов приложения. Ролью этого процесса является кэширование, при использование которого приложение будет запускаться быстрей в следующий, когда потребуется использование каких-либо компонент. Такие образом, такие процессы уничтожаются довольно часто, чтобы сохранялся общий баланс между этими пустыми кэшами и основным кэшем ядра.

Каждый из строительных блоков по-разному влияет на жизненный цикл приложения. Более подробно об этих блоках и об их влиянии на жизненный цикл программы я расскажу в следующих статьях.

Автор и источник: Максим Юдин