Добавлен: 29.10.2018
Просмотров: 48061
Скачиваний: 190
10.8. Android
881
фонов и далее до «фаблетов», 7-дюймовых планшетов и более крупных 10-дюй-
мовых планшетов.
3. По мере того как платформа предоставляла встроенную поддержку для все боль-
шего количества различной аппаратуры, не только для более крупных экранов, но
и для несенсорных устройств с мышью или без нее, появлялось все больше типов
Android-устройств. В их число вошли телевизионные устройства, такие как Google
TV, игровые устройства, ноутбуки, камеры и т. д.
Существенного объема работы потребовала невидимая часть: чистое разделение соб-
ственных служб Google и Android-платформы с открытым кодом.
При разработке Android 1.0 большая работа была проделана для получения чистого
API-интерфейса для сторонних приложений, не завязанного на собственный код
Google. Но реализация собственного кода Google зачастую не была очищена и имела
зависимости от внутренних частей платформы. У платформы часто даже не было
средств, необходимых собственному коду Google для нормальной интеграции с ней.
Для решения этих проблем вскоре была реализована серия проектов:
1. В 2009 году в Android версии 2.0 была введена архитектура для третьих сторон,
позволяющая им подключать к API-функциям платформы собственные адаптеры
синхронизации, например контакты с базой данных. Код Google, предназначенный
для синхронизации различных данных, перешел на этот четко определенный SDK
API.
2. В 2010 году в Android версии 2.2 была проведена работа над внутренней кон-
струкцией и реализацией собственного кода Google. Такое «великое разделение»
привело к чистой реализации множества основных служб Google, от доставки
обновлений системных программ на основе облачных хранилищ до обмена со-
общениями между облаком и устройством (cloud-to-device messaging), а также
до других служб, работающих в фоновом режиме, в результате чего они могли
доставляться и обновляться независимо от платформы.
3. В 2012 году на устройства было добавлено новое служебное приложение Google
Play, содержащее обновленные и новые свойства для собственных служб Google,
не имеющих отношения к приложениям. Это было следствием выполненного
в 2010 году разделения труда, позволяющего собственным API-функциям, таким
как функции обмена сообщениями между облаком и устройством, полностью до-
ставляться и обновляться компанией Google.
10.8.3. Цели разработки
В процессе разработки платформы Android были сформулированы несколько основ-
ных целей:
1. Предоставить платформу для мобильных устройств с полностью открытым исход-
ным кодом. Та часть Android, которая относится к открытому исходному коду, яв-
ляется упорядоченным снизу вверх стеком операционной системы, включающим
разнообразные приложения, которые могут поставляться как готовый продукт.
2. Осуществить мощную поддержку приложений, являющихся собственностью
сторонних разработчиков, с помощью надежного и стабильного API. Как уже от-
мечалось, для этого пришлось поддерживать платформу, которая, с одной стороны,
882
Глава 10. Изучение конкретных примеров: Unix, Linux и Android
действительно имела открытый код, а с другой — была достаточно стабильной для
приложений, являющихся собственностью сторонних разработчиков. В Android
используется смесь технических решений (задаваемых четко определенным SDK
и разделением между публичными API-функциями и внутренней реализацией)
и нацеленной на них политики требований (с помощью CDD).
3. Позволить всем приложениям сторонних разработчиков, включая таковые от
Google, конкурировать на равных. Открытый код Android сконструирован, чтобы
оставаться нейтральным по отношению к системным свойствам более высоко-
го уровня, надстроенным над ним: от доступа к облачным службам (таким, как
синхронизация данных или API-функции обмена сообщениями между облаком
и устройством) до библиотек (таких, как библиотека отображений Google) и вы-
сокотехнологичных служб (таких, как магазины приложений).
4. Предоставить модель безопасности приложений, в которой пользователям не при-
дется проникаться глубоким доверием к приложениям сторонних разработчиков.
Операционная система должна защитить пользователя не только от неправильного
поведения дефектных приложений, которые могут вызвать аварийную ситуацию,
но и от неверного использования устройства и пользовательских данных на нем.
Чем меньше пользователям нужно будет обращать внимание на доверие к прило-
жениям, тем больше свободы у них будет для их опробования и установки.
5. Обеспечить поддержку взаимодействий, свойственных мобильному пользовате-
лю, — незначительным затратам времени на работу с многими приложениями.
Мобильности свойственна кратковременность взаимодействия с приложения-
ми: просмотр только что полученной электронной почты, получение и отправка
SMS- или IM-сообщений, переход к контактам для помещения в них вызова и т. д.
Системе нужно быть оптимизированной под такие быстрые запуски приложений
и многократные переключения. Вообще-то перед Android стояла цель затрачивать
не более 200 мс на холодный старт основного приложения до момента отображе-
ния на экране интерактивного пользовательского интерфейса.
6. Управлять процессами приложений, упростив восприятие приложений пользо-
вателями до такой степени, чтобы они не волновались по поводу их закрытия
по завершении использования. Мобильные устройства также имеют склонность
к работе без подкачки, что позволяет операционным системам более элегантно
отказывать, когда текущий набор запущенных приложений требует больше опе-
ративной памяти, чем доступно физически. Для решения этих двух требований
система должна занимать более активную позицию при управлении процессами
и решении того, когда они должны запускаться и останавливаться.
7. Поддерживать высокотехнологичные и безопасные способы взаимодействия и со-
трудничества приложений. Мобильные приложения в некотором роде являются
возвращением к командам оболочки: вместо того чтобы постоянно укрупнять
монолитную конструкцию приложений для настольных систем, их нацеливают на
конкретные нужды. Операционная система должна предоставлять новые типы воз-
можностей для таких приложений, чтобы они могли сотрудничать друг с другом
для создания единого целого.
8. Создать полностью универсальную операционную систему. Мобильные устрой-
ства являются новым выражением универсальных вычислений, которые иногда
ничуть не проще тех, что выполняются традиционными операционными систе-
10.8. Android
883
мами настольных машин. Конструкция Android должна быть достаточно высоко-
технологичной, позволяющей совершенствоваться, и по возможностям по крайней
мере не уступать традиционным операционным системам.
10.8.4. Архитектура Android
Android является надстройкой над стандартным ядром Linux, имеющей всего несколь-
ко существенных расширений самого ядра, которые будут рассмотрены позже. А вот
в пространстве пользователя его реализация сильно отличается от традиционных
распространяемых версий Linux и использует множество уже понятных вам свойств
Linux совершенно иными способами.
В традиционной Linux-системе первым Android-процессом в пользовательском про-
странстве является init, который является корневым для всех других процессов. Но
демонов init-процесс Android запускает по-другому, концентрируясь на низкоуровне-
вых деталях (управлении файловыми системами и доступом к оборудованию), а не на
высокоуровневых пользовательских возможностях, таких как планирование заданий
с определенным сроком выполнения (cron jobs). У Android также имеется дополни-
тельный уровень процессов, которые запускают среду языка Java под названием Dalvik.
Эта среда отвечает за выполнение всех частей системы, реализованных на языке Java.
Присущая Android основная структура процессов показана на рис. 10.22. Первым пока-
зан процесс init, который дает начало ряду низкоуровневых процессов-демонов. Одним
из них является процесс zygote, корневой для высокоуровневых процессов языка Java.
appN
phone
system_server
Dalvik
Dalvik
Dalvik
zygote
app1
app2
Dalvik
Dalvik
installd
servicemanager
init
adbd
Ядро
Dalvik
Процессы
приложений
Системные
процессы
Демоны
Рис. 10.22. Иерархия процессов Android
Android-процесс init не запускает оболочку традиционным способом, потому что обыч-
ное Android-устройство не имеет локальной консоли для доступа к оболочке. Вместо
этого демон-процесс adbd прислушивается к удаленным подключениям (например,
884
Глава 10. Изучение конкретных примеров: Unix, Linux и Android
по USB), запрашивающим доступ к оболочке, по необходимости ответвляя для них
процессы оболочки.
Поскольку основная часть Android написана на языке Java, центральными для системы
являются демон zygote и запущенные им процессы. Первый процесс, всегда запускае-
мый zygote, называется system_server и содержит все основные службы операционной
системы. Основными частями являются диспетчер электропитания, диспетчер пакетов,
оконный диспетчер и диспетчер активностей.
По мере необходимости из zygote будут создаваться другие процессы. Некоторые из
них станут постоянными процессами, являющимися частью основной операционной
системы, например телефонный стек в процессе телефона, который должен всегда
оставаться в работе. В ходе работы системы по мере необходимости будут создаваться
и останавливаться дополнительные процессы приложений.
Взаимодействие приложений с операционной системой осуществляется за счет вызо-
вов предоставляемых ею библиотек, совокупность и является средой Android (Android
framework). Некоторые из библиотек могут работать в рамках данного процесса, но
многим понадобится межпроцессный обмен данными с другими процессами. Зачастую
этот обмен ведется со службами в процессе system_server.
Типовая конструкция API-функций среды Android, взаимодействующей с системными
службами, в данном случае с диспетчером пакетов, показана на рис. 10.23. Диспетчер
пакетов предоставляет API-функции среды для приложений, чтобы они могли сделать
вызов в своем локальном процессе, в данном случае вызов класса PackageManager.
Процесс приложения
Системный сервер
Код приложения
PackageManager
PackageManagerService
Диспетчер служб
«Пакет»
Binder IPC
Binder IPC
Binder IPC
Рис. 10.23. Публикация системных служб и взаимодействие с ними
10.8. Android
885
Внутри среды этот класс должен получить подключение к соответствующей службе
в system_server. Для выполнения этой задачи в ходе начальной загрузки system_server
публикует каждую службу под четко определенным именем в диспетчере служб
(service manager), демоне-процессе, запускаемом процессом init. PackageManager в про-
цессе приложения извлекает подключение из service manager в его системную службу,
используя это же имя.
Как только PackageManager подключится к системной службе, он сможет осу-
ществлять адресуемые ей вызовы. Большинство вызовов со стороны приложений
к PackageManager реализуются как обмен данными между процессами с исполь-
зованием Android-механизма Binder IPC, в данном случае осуществляя вызовы
к PackageManagerService в system_server. Реализация PackageManagerService разрешает
конфликты среди клиентских приложений и поддерживает состояние, которое будет
необходимо нескольким приложениям.
10.8.5. Расширения Linux
В целом Android включает в себя основную часть ядра Linux, обеспечивающую вы-
полнение стандартных функций Linux. Наиболее интересными аспектами Android
как операционной системы является метод использования этих, уже существующих
функций Linux. Но есть также ряд важных расширений Linux, на которых базируется
система Android.
Блокировки сна
Управление электропитанием на мобильных устройствах отличается от такового на
традиционных компьютерных системах, поэтому для управления порядком перехода
системы в спящее состояние Android добавляет к Linux новое свойство под названием
блокировка сна
(wake locks) или блокировщик приостановки (suspend blockers).
Традиционная компьютерная система может находиться в двух состояниях энерго-
потребления: работающей и готовой к вводу со стороны пользователя или глубоко
заснувшей и неспособной продолжить работу без внешнего прерывания, например
нажатия кнопки включения питания. В процессе работы второстепенные части обору-
дования могут быть по необходимости включены или выключены, но сам центральный
процессор и основные части оборудования должны оставаться под напряжением для
обработки входящего сетевого трафика и других подобных событий. Переход в спящее
состояние с самым низким потреблением энергии случается довольно редко: либо поль-
зователь явно переводит систему в спящее состояние, либо она самостоятельно пере-
ходит в это состояние из-за относительно продолжительного интервала бездействия
пользователя. Пробуждение требует аппаратного прерывания от внешнего источника,
например нажатия клавиши на клавиатуре, в результате чего устройство выйдет из
спящего состояния и включит свой экран.
У пользователей мобильных устройств бывают разные намерения. Хотя пользователь
может выключить экран, чтобы было похоже на то, что устройство уснуло, в обычное
состояние сна он его погружать не намерен. Пока экран отключен, от устройства по-
прежнему требуется поддержание работоспособного состояния: оно должно иметь воз-
можность принимать входящие телефонные звонки, получать и обрабатывать данные
для входящих сообщений интерактивной переписки и делать многое другое.