Основной файл который описывает из чего состоит приложение называется
Android — операционная система, основанная на Linux с интерфейсом программирования Java. Это предоставляет нам такие инструменты, как компилятор, дебаггер и эмулятор устройства, а также его (Андроида) собственную виртуальную машину Java (Dalvik Virtual Machine — DVM). Android создан альянсом Open Handset Alliance, возглавляемым компанией Google.
Android использует специальную виртуальную машину, так званую Dalvik Virtual Machine. Dalvik использует свой, особенный байткод. Следовательно, Вы не можете запускать стандартный байткод Java на Android. Android предоставляет инструмент «dx», который позволяет конвертировать файлы Java Class в файлы «dex» (Dalvik Executable). Android-приложения пакуются в файлы .apk (Android Package) программой «aapt» (Android Asset Packaging Tool) Для упрощения разработки Google предоставляет Android Development Tools (ADT) для Eclipse. ADT выполняет автоматическое преобразование из файлов Java Class в файлы dex, и создает apk во время развертывания.
2. Основные компоненты Android
Android-приложения состоят из следующих частей:
Другими частями Android являются виджеты, или живые папки (Live Folders), или живые обои (Live Wallpapers). Живые папки отображают источник любых данных на «рабочем столе» без запуска соответствующих приложений.
3. Безопасность и разрешения
Android определяет конкретные разрешения для определенных задач.
Android-приложения описываются файлом «AndroidManifest.xml». В этих файлах должны быть объявлены все активити, службы, приемники и контент-провайдеры приложения. Также он должен содержать требуемые приложением разрешения. Детальное описание полей смотри в здесь.
5. R.java, Resources и Assets
Каталог «gen» в Android-проекте содержит генерированные значения.
Тогда как каталог „res“ хранит структурированные значения, известные платформе Android, каталог „assets“ может быть использован для хранения любых данных. В Java Вы можете получить доступ к этим данным через AssetsManager и метод getAssets().
6. Активити и Макеты (layout)
Пользовательский интерфейс для деятельности (Activity) определяется с помощью макетов. Во время исполнения макеты — экземпляры «android.view.ViewGroups». Макет определяет элементы пользовательского интерфейса, их свойства и расположение. Элементы UI основываются на классе «android.view.View».
Макет может быть определен с помощью Java-кода или с помощью XML.
7. Активити и жизненный цикл
Операционная система контролирует жизненный цикл Вашего приложения.
Наиболее важные методы:
onSaveInstanceState() — вызывает, если активити остановлено. Используется для сохранения данных при восстановлении состояния активити, если активити возобновлено
onPause() — всегда вызывается, если активити завершилось, может быть использовано, для освобождения ресурсов или сохранения данных
onResume() — вызвано, если активити возобновлено, может быть использовано для инициализации полей
8. Контекст
Класс android.content.Context представляет связи с системой Android. Это интерфейс для глобальной информации про окружение приложения. Контекст также предоставляет метод getSystemService, позволяющий получить объект управления для различных частей оборудования. Так как Activities и Services расширяют класс «Context», вы можете получить прямой доступ к контексту с помощью «this».
Итак, мы уже говорили о происхождении архитектуры ОС Android и о шаблонах, реализованных в этой архитектуре. Теперь настала пора поговорить о том, из чего состоит Android-приложение.
В этой статье будут представлены основные «персонажи» архитектуры Android-приложения.
В общем случае, Android-приложение состоит из:
- Java-классов, являющихся подклассами основных классов из Android SDK (View, Activity, ContentProvider, Service, BroadcastReciever, Intent) и Java-классов, у которых нет родителей в Android SDK.
- Ресурсов наподобие строк, изображений и т.п.
- Файлов
Java классы
На следующей диаграмме представлена иерархия основных классов из Android SDK, с которыми предстоит иметь дело разработчику:
На самом деле классов намного больше, но это основные. Выделенные жёлтым — те, с которыми разработчик работает непосредственно (в частности, наследуются от них). Остальные так же важны, но они реже используются напрямую.
View — базовый класс для всех виджетов пользовательского интерфейса (GUI widgets). Интерфейс Android-приложения представляет собой дерево экземпляров наследников этого класса. Можно создать это дерево программно, но это неправильно. Пользовательский интерфейс определяется с помощью XML (файлы слоёв, layout files), а во время исполнения автоматически превращается (inflate, термин Android) в дерево соответствующих объектов.
Класс Activity и его подклассы содержат логику, лежащую за пользовательским интерфейсом. При ближайшем рассмотрении этот класс соответствует ViewModel в архитектурном шаблоне Model-View-ViewModel (MVVM). Отношение между подклассом Activity и пользовательским интерфейсом — это отношение один к одному; обычно каждый подкласс Activity имеет только один связанный с ним слой пользовательского интерфейса, и наоборот. Activity имеет жизненный цикл.
В течении жизненного цикла Activity может находиться в одном из трёх состояний:
- Активно и выполняется — этот пользовательский интерфейс находится на переднем плане (говоря технически — на вершине стека активити)
- Приостановлено — если данный интерфейс пользователя потерял фокус, но всё ещё видим. В таком состоянии никакой код не выполняется.
- Завершено — если интерфейс пользователя невидим. В таком состоянии код не выполняется.
Класс ContentProvider и его подклассы представляют model в архитектуре MVVM. В большинстве практических случаев это обёртка над базой данных SQLite с немного причудливым способом доступа на основе URI. Теоретически, никто не мешает разработчику создать ContentProvider на основе чего-то ещё, кроме базы данных. Тем не менее, существующий метод query() контент-провайдера возвращает объект Cursor, который крайне похож на JDBC ResultSet интерфейсом и тем, как он работает. Поэтому вряд ли кто-то усомнится, что настоящее назначение контент-провайдеров — инкапсулировать базу данных.
Я не знаю, как комманда Android пришла к такому дизайну, но, по-моему, здесь соединены две хороших, но не слишком совместимых идеи.
И вот почему я так считаю. Основная идея контент-провайдеров, похоже, базируется на архитектуре AJAX приложений. AJAX приложения обычно используют архитектуру MVVM, где модель представлена как URI на стороне сервера (тем не менее, это изменилось с поялвинем HTML5, который позволяет хранить данные локально). В самом деле, тот факт, что контент-провайдеры запрашиваются с помощью URI и создают расширение с помощью типов MIME указывает на то, что в основе лежит AJAX. Напомню, ребята из Google создали большое количество AJAX приложений, таких как Gmail, Google Docs и т.п., поэтому вполне естественно, что идеи заимствовались из архитектуры AJAX.
Возможно, кто-то ещё пришёл с ещё одной отличной идеей: как было бы здорово иметь полноценную реляционную базу на мобильном устройстве! (замечу, это было примерно в 2005 году, когда мобильные телефоны были намного слабее, чем сейчас). И, как результат, они соединили две хороших идеи в один класс ContentProvider. Как это обычно и случается в разработке ПО, соединение двух хороших идей не всегда даёт в результате хорошую идею; в случае Android мы имеем несколько обескураживающий дизайн контент-провайдеров.
Класс Service и его подклассы я затрудняюсь как-то классифицировать. Я думаю, ребята из Google испытывают те же трудности (прочтите, пожалуйста, их документацию). Их классификация, в основном, говорит, чем этот класс не является. Я лично думаю, что сервис — это разновидность Model, обслуживающая несколько иные варианты использования, нежели ContentProvider.
По-моему, архитектурный дизайн Android Service навеян сервисами OSGI.
Думаю, сервисы были созданы ребятами из Google как решение логической проблемы, возникшей из-за модели потоков Android.
Подумайте над этим: Activity активно и выполняется только когда его пользовательский интерфейс находится на переднем плане. Как только интерфейс другого Activity закрывает собой текущее, последнее останавливается, даже если оно что-то делало. А что, если вам нужно выполнять некую операцию, даже если процесс, которые её выполняет, не на переднем плане? С помощью Activity вы не сможете этого сделать. Вы не сможете это сделать и с помощью ContentProvider, поскольку у них нет собственного жизненного цикла, и они могут выполняться только пока Activity, использующее его, активно.
И тут на помощь приходят сервисы. Они могут выполняться даже когда процесс, в котором они работают, не на переднем плане. Так, если вы разрабатываете активити, выполняющее растянутую во времени операцию, которая должна завершиться даже работая в фоне, вы должны создать Service, реализующий эту операцию, и запустить его из Activity.
Service так же имеет жизненный цикл. Это означает, что он может быть инстанцирован и запущен Android-приложением по некому условию (мы обсудим это позже).
Как я уже упоминал, Service, как model, приследует более общие цели, нежели ContentProvier. Он может использовать базу данных, но его API не связано с БД, как в случае ContentProvider. В большинстве случаев сервисы используются для связи с внешними серверами.
Класс BroadcastReceiver и его подклассы представляют собой «подписчика» в механизме взаимодейтсвия издатель/подписчик, реализованном в архитектуре Android.
Мы уже говорили о механизмах взаимодействия в предыдущей статье.
Конечно, разработчик под Android не ограничен одним только расширением классов из Android SDK. Он может писать собственные классы так, как захочет. Но все они будут только хелперами («helper classes») для классов из Andoird SDK.
Манифест Android
Манифест Android — ещё одна важная часть Android-приложения. Идея была навеяна манифестами плагинов для Eclipse.
Манифест Android представляет собой XML файл и выполняет несколько функций. Вот как их описывает Google:
Обратите внимание на второй пункт. Имеется ввиду, что если некий класс расширяет Activity, ContentProvider, BroadcastReceiver или Service в вашем приложении, этот класс не может быть использован до тех пор, пока он не описан в манифесте.
Ресурсы
Каждое современное GUI приложение в той или иной форме использует ресурсы. Android-приложения — не исключение. Они используют следующие типы ресурсов:
- Изображения
- Слои GUI (XML файлы)
- Объявления меню (XML файлы)
- Текстовые строки
Давайте рассмотрим следующий пример. Файл с именем mybutton.jpg содержит картинку для кнопки. Разработчик совершает ошибку и набирает mybuton.jpg, ссылаясь на ресурс из кода. Как итог, код пытается использовать несуществующий ресурс, но компиляция пройдёт успешно. Ошибка может быть обнаружена только в ходе тестирования (а может и не быть обнаружена вовсе).
Ребята из Google нашли элегантное решение этой проблемы. При сборке Android-приложения генерируется специальный Java-класс с именем R (всего лишь одна буква). Этот класс содержит несколько static final наборов данных. Каждый такой набор данных — ссылка на отдельный ресурс. Эти ссылки используются в коде приложения для связи с ресурсами. Теперь каждая ошибка в ссылке на ресурсы проявляет себя в процессе компиляции.
Файлы
Android-приложение использует несколько разных типов файлов:
- Файлы «общего назначения»
- Файлы БД
- Файлы Opaque Binary Blob (OBB) (они представляют собой зашифрованную файловую систему, которая может быть монтирована для приложения)
- Закешированные файлы
API для работы с файлами реализован классом Context, от которого порождены классы Activity и Service. Этот класс уже обсуждался нами здесь.
На сегодня это всё. В следующей статье мы поговорим о том, как различные части Android-приложения взаимодействуют между собой.
Android -приложения могут быть простыми и сложными, но строение приложений всегда будет одинаковым. Есть обязательные элементы приложений, а есть опциональные, которые используются по мере необходимости. Android - приложение состоит из нескольких основных компонентов: манифест приложения, набор различных ресурсов и исходный код программы .
Следующая таблица демонстрирует обязательные и возможные составляющие структуры Android -приложения:
1.5.1. Файл манифеста AndroidManifest.xml
Файл манифеста AndroidManifest.xml предоставляет системе основную информацию о программе. Каждое приложение должно иметь свой файл AndroidManifest.xml. Редактировать файл манифеста можно вручную, изменяя XML-код или через визуальный редактор Manifest Editor, который позволяет осуществлять визуальное и текстовое редактирование файла манифеста приложения.
- описывает компоненты приложения – Activities, Services, Broadcast receivers и Content providers;
- содержит список необходимых разрешений для обращения к защищенным частям API и взаимодействия с другими приложениями;
- объявляет разрешения, которые сторонние приложения обязаны иметь для взаимодействия с компонентами данного приложения;
- объявляет минимальный уровень API Android, необходимый для работы приложения;
- перечисляет связанные библиотеки.
Корневым элементом манифеста является . Помимо данного элемента обязательными элементами являются теги и . Элемент является основным элементом манифеста и содержит множество дочерних элементов, определяющих структуру и работу приложения. Порядок расположения элементов, находящихся на одном уровне, произвольный. Все значения устанавливаются через атрибуты элементов. Кроме обязательных элементов, упомянутых выше, в манифесте по мере необходимости используются другие элементы. Перечислим некоторые из них:
По умолчанию Eclipse создает элемент с четырьмя атрибутами:
xmlns:android определяет пространство имен Android.
package определяет уникальное имя пакета приложения.
android:versionCode указывает на внутренний номер версии.
android:versionName указывает номер пользовательской версии.
Наиболее распространненные разрешения:
INTERNET – доступ к интернету
READ_CONTACTS – чтение (но не запись) данных из адресной книги пользователя
WRITE_CONTACTS – запись (но не чтение) данных в адресную книгу пользователя
RECEIVE_SMS – обработка входящих SMS
ACCESS_FINE_LOCATION – точное определение местонахождения при помощи GPS
android:minSdkVersion определяет минимальный уровень API, требуемый для работы приложения. Система Android будет препятствовать тому, чтобы пользователь установил приложение, если уровень API системы будет ниже, чем значение, определенное в этом атрибуте.
android:maxSDKVersion позволяет определить самую позднюю версию, которую готова поддерживать программа.
targetSDKVersion позволяет указать платформу, для которой разрабатывалось и тестировалось приложение.
android.hardware.camera – требуется аппаратная камера.
android.hardware.camera.autofocus – требуется камера с автоматической фокусировкой.
1.5.2. Ресурсы
В Android принято хранить такие объекты, как изображения, строковые константы, цвета, анимацию, стили и тому подобное, за пределами исходного кода. Система поддерживает хранение ресурсов во внешних файлах. Внешние ресурсы легче поддерживать, обновлять и редактировать.
В основном, ресурсы хранятся в виде XML-файлов в каталоге res с подкаталогами values, drawable-ldpi, drawable-mdpi, drawable-hdpi, layout. Но также бывают еще два типа ресурсов: raw и assets.
Для удобства система создает идентификаторы ресурсов и использует их в файле R.java (класс R, который содержит ссылки на все ресурсы проекта), что позволяет ссылаться на ресурсы внутри кода программы. Статический класс R генерируется на основе заданных ресурсов и создается во время компиляции проекта. Так как файл R генерируется автоматически, то нет смысла его редактировать вручную, потому что все изменения будут утеряны при повторной генерации.
В общем виде ресурсы представляют собой файл (например, изображение) или значение (например, заголовок программы), связанные с создаваемым приложением. Удобство использования ресурсов заключается в том, что их можно изменять без повторной компиляции или новой разработки приложения.
Самыми распространенными ресурсами являются, пожалуй, строки (string), цвета (color) и графические рисунки (bitmap).
В следующей таблице перечислены основные ресурсы Android-приложения:
Помимо изображений в каталоге res/drawable могут храниться ресурсы простых геометрических фигур. Вот лишь некоторые из возможных атрибутов:
- android:shape задает тип фигуры: rectangle (прямоугольник), oval (овал), line (линия), ring (окружность);
- создает закругленные углы для прямоугольника;
- задает градиентную заливку для фигуры; в Android можно создавать три типа градиентов: Linear (линейный), Radial (радиальный) и Sweep (разверточный);
- задает размеры фигуры;
- задает сплошной цвет для фигуры.
Анимация в Android бывает двух видов:
- Frame Animation – кадровая анимация, традиционная анимация при помощи быстрой смены последовательных изображений, как на кинопленке.
- Tween Animation – анимация преобразований может выполняться в виде ряда простых преобразований: изменение позиции (класс TranslateAnimation), размера (ScaleAnimation), угла вращения (RotateAnimation) и уровня прозрачности (AlphaAnimation). Команды анимации определяют преобразования, которые необходимо произвести над объектом. Преобразования могут быть последовательными или одновременными. Последовательность команд анимации определяется в XML-файле (предпочтительно) или в программном коде.
В Android имеется еще один каталог, в котором моrут храниться файлы, предназначенные для включения в пакет – /assets . Это не ресурсы, а просто необработанные файлы. Этот каталог находится на том же уровне, что и /res. Для файлов, располагающихся в /assets, в R.java не генерируются идентификаторы ресурсов. Для их считывания необходимо указать путь к файлу. Путь к файлу является относительным и начинается с /assets. Этот каталог, в отличие от подкаталога res/, позволяет задавать произвольную глубину подкаталогов и произвольные имена файлов.
1.5.3. Разметка
В Android-приложениях, пользовательский интерфейс построен на View и ViewGroup объектах. Класс ViewGroup является основой для подкласса Layout (разметка).
Разметка (также используются термины компоновка или макет) хранится в виде XML-файла в папке /res/layout . Это сделано для того, чтобы отделить код от дизайна, как это принято во многих технологиях (HTML и CSS, Visual Studio и Expression Blend). Кроме основной компоновки для всего экрана, существуют дочерние компоновки для группы элементов. По сути, компоновка – это некий визуальный шаблон для пользовательского интерфейса приложения, который позволяет управлять элементами, их свойствами и расположением. В своей практике вам придется познакомиться со всеми способами размещения.
Android-плагин для Eclipse включает в себя специальный редактор для создания разметки двумя способами. Редактор имеет две вкладки: одна позволяет увидеть, как будут отображаться элементы управления, а вторая – создавать XML-разметку вручную.
Создавая пользовательский интерфейс в XML-файле, можно отделить дизайн приложения от программного кода. Можно изменять пользовательский интерфейс в файле разметки без необходимости изменения программного кода. Например, можно создавать XML-разметки для различных ориентаций экрана мобильного устройства (portrait, landscape), размеров экрана и языков интерфейса. Впрочем, элементы интерфейса можно создавать и программно, когда это необходимо.
Каждый файл разметки должен содержать только один корневой элемент компоновки, который должен быть объектом View или ViewGroup. Внутри корневого элемента можно добавлять дополнительные объекты разметки или дочерние элементы интерфейса, чтобы постепенно формировать иерархию элементов, которую определяет создаваемая разметка.
Существует несколько стандартных типов разметок:
- FrameLayout является самым простым типом разметки. Обычно это пустое пространство на экране, которое можно заполнить только дочерним объектом View или ViewGroup . Все дочерние элементы FrameLayout прикрепляются к верхнему левому углу экрана. В разметке FrameLayout нельзя определить различное местоположение для дочернего объекта View. Последующие дочерние объекты View будут просто рисоваться поверх предыдущих представлений, частично или полностью затеняя их, если находящийся сверху объект непрозрачен
- LinearLayout выравнивает все дочерние объекты в одном направлении – вертикально или горизонтально. Направление задается при помощи атрибута ориентации android:orientation . Все дочерние элементы помещаются в стек один за другим, так что вертикальный список представлений будет иметь только один дочерний элемент в строке независимо от того, насколько широким он является. Горизонтальное расположение списка будет размещать элементы в одну строку с высотой, равной высоте самого высокого дочернего элемента списка.
- TableLayout позиционирует свои дочерние элементы в строки и столбцы. TableLayout не отображает линии обрамления для рядов, столбцов или ячеек. TableLayout может иметь ряды с разным количеством ячеек. При формировании разметки таблицы некоторые ячейки при необходимости можно оставлять пустыми. TableLayout удобно использовать, например, при создании логических игр типа Судоку, Крестики-Нолики и тому подобных.
- RelativeLayout позволяет дочерним элементам определять свою позицию относительно родительского представления или относительно соседних дочерних элементов.
Все описываемые разметки являются подклассами ViewGroup и наследуют свойства, определенные в классе View.
Разметки ведут себя как элементы управления, и их можно группировать. Расположение элементов управления может быть вложенным. Например, можно использовать RelativeLayout в LinearLayout и так далее. Однако, слишком большая вложенность элементов управления вызывает проблемы с производительностью.
Вот и пришла пора поговорить непосредственно о внутренней организации приложений под Android : обсудить их архитектуру и основные компоненты.
Архитектура Android приложений основана на идее многократного использования компонентов, которые являются основными строительными блоками. Каждый компонент является отдельной сущностью и помогает определить общее поведение приложения .
Система Android выстроена таким образом, что любое приложение может запускать необходимый компонент другого приложения. Например, если приложение предполагает использование камеры для создания фотографий, совершенно необязательно создавать в этом приложении активность для работы с камерой. Наверняка на устройстве уже есть приложение для получения фотографий с камеры, достаточно запустить соответствующую активность , сделать фотографию и вернуть ее в приложение , так что пользователь будет считать, что камера часть приложения, с которым он работает.
Можно выделить четыре различных типа компонентов, каждый тип служит для достижения определенной цели и имеет свой особый жизненный цикл , который определяет способы создания и разрушения соответствующего компонента. Рассмотрим основные компоненты Android -приложений.
Сервисы (Services). Сервис - компонент , который работает в фоновом режиме, выполняет длительные по времени операции или работу для удаленных процессов. Сервис не предоставляет пользовательского интерфейса. Например, сервис может проигрывать музыку в фоновом режиме, пока пользователь использует другое приложение , может загружать данные из сети, не блокируя взаимодействие пользователя с активностью. Сервис может быть запущен другим компонентом и после этого работать самостоятельно, а может остаться связанным с этим компонентом и взаимодействовать с ним.
Контент-провайдеры (Content providers). Контент-провайдер управляет распределенным множеством данных приложения. Данные могут храниться в файловой системе, в базе данных SQLite, в сети, в любом другом доступном для приложения месте. Контент-провайдер позволяет другим приложениям при наличии у них соответствующих прав делать запросы или даже менять данные. Например, в системе Android есть контент-провайдер, который управляет информацией о контактах пользователя. В связи с этим, любое приложение с соответствующими правами может сделать запрос на чтение и запись информации какого-либо контакта. Контент-провайдер может быть также полезен для чтения и записи приватных данных приложения, не предназначенных для доступа извне.
Все рассмотренные компоненты являются наследниками классов, определенных в Android SDK .
Каждое Android - приложение запускается в своем собственном процессе. Поэтому приложение изолировано от других запущенных приложений, и неправильно работающее приложение не может беспрепятственно навредить другим Android -приложениям.
Тем не менее, главным параметром Android -приложения является возможность использовать компоненты других приложений, если они дают на это соответствующие права . Допустим, нам нужен некий компонент с прокруткой для отображения текста, и похожий компонент уже реализован в другом приложении. Тогда у нас есть возможность использовать реализованный компонент . В этом случае наше приложение не копирует необходимый код к себе и не создает ссылку на него. Вместо этого приложение делает запрос на исполнение части кода другого приложения, где есть нужный нам компонент .
В Android существует четыре типа компонентов: Activities , Services , Broadcast receivers и Content providers .
1.6.1. Activities
Приложение может состоять из одного Activity или из нескольких. Это зависит от типа приложения и его дизайна. Одно Activity может вызвать другое. Каждое Activity задает окно для отображения, которое, обычно, занимает весь экран, но может быть меньше и плавать поверх других окон. Activity может использовать дополнительные окна, например, всплывающий диалог, который требует промежуточного ответа пользователя, или окно, которое отображает пользователям важную информацию при выборе элемента, заслуживающего особого внимания.
Визуальный интерфейс строится на основе иерархии визуальных компонентов, производных от базового класса View. Android имеет ряд готовых к использованию компонентов, а также кнопки, текстовые поля, полосы прокрутки, меню, флажки и многие другие.
Activity может находиться в одном из трех состояний:
- Active или Running – находится на переднем плане и имеет фокус для взаимодействия с пользователем.
- Paused – потеряло фокус, но все еще видно пользователю. Сверху находится другое Activity , которое или прозрачно или закрывает не весь экран. Приостановленное Activity полностью "живое" (его состояние сохранено), но может быть уничтожено системой в случае нехватки памяти.
- Stopped – полностью перекрыто другим Activity . Оно больше не видно пользователю и будет уничтожено системой, когда понадобится память.
Если Activity приостановлено или остановлено, система может удалить его из памяти, либо послать запрос на его завершение, или просто уничтожить его процесс. Когда Activity снова отображается пользователю, его состояние полностью восстанавливается.
Переходя от состояния к состоянию, Activity уведомляет об этом, вызывая следующие методы:
- void onCreate()
- void onStart()
- void onRestart()
- void onResume()
- void onPause()
- void onStop()
- void onDestroy()
Жизненный цикл Activity состоит из трех вложенных циклов (Рис. 1.3):
- Жизненный цикл activity начинается с вызова метода onCreate() , в котором производится первоначальная настройка глобального состояния, и завершается вызовом метода onDestroy() , в котором оно освобождает занятые ресурсы.
- Видимая часть жизненного цикла происходит между вызовами onStart() и onStop() . В течение этого времени пользователь может видеть Activity на экране, хотя оно может быть не на переднем плане и не взаимодействовать с пользователем. Методы onStart() и onStop() могут вызываться столько раз, сколько Activity становится видимым или скрытым для пользователя.
- На переднем плане Activity находится между вызовами onResume() и onPause() . В течение этого времени Activity находится поверх других и взаимодействует с пользователем. Activity может часто переходить в состояние паузы и выходить из него. Например, метод onPause() может быть вызван, когда устройство переходит в спящий режим или когда запускается другое Activity , а метод onResume() – при получении результата от закрывающегося Activity .
Следующая таблица более детально описывает каждый из уже перечисленных методов и его место в жизненном цикле Activity .
За ним всегда следует вызов метода onStart() .
За ним всегда следует вызов onResume()
За ним следует вызов onResume() , если Activity переходит на передний план, или onStop() , если оно скрывается.
За ним следует вызов onPause() .
За ним может быть вызван метод onResume() если Activity возвращается на передний план, или метод onStop() , если оно становится невидимым для пользователя.
Затем может быть вызван либо метод onRestart() , если Activity возвращается для взаимодействия с пользователем, либо метод onDestroy() , если оно завершается.
Обратите внимание на колонку "Может ли быть уничтожен?". Она указывает на то, может ли система уничтожить процесс, в котором запущено Activity , в любой момент после возврата из этого метода, не выполняя больше ни одной строчки кода Activity . Три метода: OnPause(), OnStop() и OnDestroy() – отмечены "Да". Но только метод OnPause() будет гарантированно вызван перед уничтожением процесса, поскольку он первый в этом списке, а OnStop() и OnDestroy() могут не вызываться. Поэтому для сохранения измененных данных нужно использовать метод OnPause() . Методы, отмеченные "Нет", защищают процесс, в котором запущено Activity, от уничтожения с момента их вызова.
1.6.2. Типы процессов в Android-приложении
Жизненный цикл приложения тесно связан с жизненным циклом его процесса. Также он зависит от текущего состояния системы. В случае нехватки памяти, Android убивает наименее значимые процессы. Значимость процесса зависит от его типа. Типы процессов, в зависимости от важности, выглядят следующим образом (от наиболее до наименее важных):
- Процесс переднего плана – процесс приложения, с которым пользователь взаимодействует в данный момент. Процесс считается таковым, если его Activity находится на вершине Activity-стека (была вызвана функция onResume() , или его Broadcast Receiver работает в настоящее время (в данный момент исполняется приложением onReceive()) , или же его Service выполняет callback-методы, такие как onCreate() , onStart() или onDestroy() . Как правило, таких процессов очень мало и они закрываются в самую последнюю очередь.
- Видимый процесс — процесс, который имеет Activity, видимый конечному пользователю в данный момент времени. Процессов, которые выводятся на экран, очень мало, поэтому их работа прерывается только в крайнем случае, если не хватает ресурсов для активных приложений.
- Служебный процесс – процесс, содержащий Service, для которого была вызвана функция startService() , при условии, что данный Service сейчас работает.
- Процесс заднего фона. Данный процесс не имеет видимых пользователю Activity (была вызвана функция onStop()) . Как правило, существует множество фоновых процессов, работа которых завершается по принципу "последний запущенный закрывается последним", чтобы освободить ресурсы для приложений, работающих на переднем плане.
1.6.3. Services
Service – это некий процесс, который запускается в фоновом режиме. Как пример, Service может получать данные по сети, выполнять какие-либо длительные вычисления. Хорошим примером Service служит проигрыватель музыки. Пользователь может выбрать любую песню в проигрывателе, включить ее и закрыть плеер занявшись чем-нибудь другим. Музыка будет проигрываться в фоновом процессе. Service проигрывания музыки будет работать, даже если Activity плеера закрыта.
Подобно Activity, Service имеет свои методы жизненного цикла:
- void onCreate()
- void onStart(Intent intent)
- void onDestroy()
В полном жизненном цикле Service существует два вложенных цикла:
- полная целая жизнь Service – промежуток между временем вызова метода onCreate() и временем возвращения onDestroy() . Подобно Activity , для Services производят начальную инициализацию в onCreate() и освобождают все остающиеся ресурсы в onDestroy() ;
- активная целая жизнь Service – начинается с вызова метода onStart() . Этому методу передается объект Intent, который передавался в startService() .
Как и Activities, Services запускаются в главном потоке процесса приложения. По этой причине их следует запускать в отдельном потоке, чтобы они не блокировали другие компоненты или пользовательский интерфейс.
1.6.4. Broadcast receivers
Когда программа возвращается из onReceive() , приемник становится неактивным и система полагает, что работа объекта Broadcast receiver закончена. Процесс с активным широковещательным получателем защищен от уничтожения системой. Однако процесс, содержащий неактивные компоненты, может быть уничтожен системой в любое время, когда память, которую он потребляет, будет необходима другим процессам.
1.6.5. Content providers
Content providers предоставляют доступ к данным (чтение, добавление, обновление). Content provider может предоставлять доступ к данным не только своему приложению, но и другим. Данные могут размещаться в файловой системе, в базе данных.
Читайте также: