Основные компоненты системы android

Операционная система Android

Feb 4 · 6 min read

Android — это операционная система с открытым исходным кодом, созданная для мобильных устройств на основе модифицированного ядра Linux. Эта ОС разработана консорциумом Open Handset Alliance, состоящим из крупных технологических компаний при организующей роли Google. Исходный код ОС представлен как часть проекта Android Open Source Project (AOSP) с лицензией Apache. Выпущенный на рынок в 2007 году Android вскоре стал самой продаваемой операционной системой в истории, благодаря своей открытой модели разработки и удобному интерфейсу. Последняя версия Android 11 вышла в 2020 году.

История развития

Проект Android появи л ся в 2003 году с целью разработки интеллектуальных мобильных устройств. Начинался он с разработки ОС для цифровых фотокамер, но вскоре акцент сместился на мобильные телефоны из-за их большой распространенности на рынке. В 2005 году проект приобрел Google и в качестве основы для этой ОС было выбрано ядро Linux за счет его гибкости и возможности обновления.

С целью разработки платформы с открытым исходным кодом для мобильных устройств в 2007 году Google сформировала Open Handset Alliance с несколькими производителями оборудования и операторами беспроводной связи. В то время каждый производитель выпускал мобильные телефоны на базе собственной платформы, с ограниченными возможностями для сторонних приложений. Альянс заявил, что открытая платформа обеспечит тесное сотрудничество между производителями и разработчиками, чтобы ускорить производство недорогих инновационных продуктов и приложений.

Платформа Android была представлена в 2007 году и вышла на рынок на следующий год. Поначалу ей мешал ограниченный набор функций и небольшая база пользователей по сравнению с конкурентами Symbian и Windows. Однако возможность обновления стала самым большим преимуществом этой ОС, поскольку каждое обновление давало новые функции и улучшенную производительность. Из-за «сладости, которую они приносят в нашу жизнь», первые версии были названы в честь десертов, в алфавитном порядке, например Cupcake, Jellybean и KitKat. Однако вскоре у Google закончились десерты, и с 2019 года новые версии ОС получают номера, начинающиеся с Android 10. Лицензия с открытым исходным кодом также помогла увеличить популярность этой ОС среди производителей мобильных устройств, поскольку они могут теперь модифицировать ОС под свои требования, не влияя при этом на разработку приложений.

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

Архитектура

Первоначально Android разрабатывался для архитектуры ARM, а затем был расширен для поддержки архитектур x86 и x86–64. Однако в целом Android не заботится об аппаратном обеспечении устройства из-за разнообразия и множества типов среди компонентов в мобильных устройствах.

Основой ОС Android является модифицированная версия ядра Linux LTS, которая непосредственно взаимодействует с оборудованием. Драйверы, необходимые для работы устройства, реализуются производителями оборудования и добавляются в ядро. Это позволяет производителям оборудования разрабатывать драйверы для хорошо известного ядра, а разработчикам ОС игнорировать разнообразие оборудования. Android 11 поддерживает версии ядра 4.14, 4.19 и 5.4.

Особенности оборудования дополнительно маскируются также реализуемыми производителями уровнями аппаратной абстракции, которые предоставляют стандартные интерфейсы для высокоуровневых структур, чтобы обеспечить доступ к аппаратному обеспечению устройства, не заботясь при этом о реализации драйверов.

Android Runtime (ART) — это виртуальная машина, которая выполняет код приложения, содержащийся в файлах Dalvik Executable (DEX). Она управляет компиляцией кода, отладкой и очисткой памяти. Каждое приложение работает со своим собственным экземпляром ART, то есть в своей собственной виртуальной машине, чтобы обеспечить изоляцию кода. ART заменил Dalvik в качестве виртуальной машины Java для Android в 2013 году, поскольку его компиляция Ahead-of-Time обеспечила лучшую производительность по сравнению с компиляцией Just-in-Time у последней.

Собственные библиотеки C/C ++ являются важной частью операционной системы, поскольку большинство основных компонентов Android написаны на собственном коде. Инфраструктура Java API — это шлюз в ОС для всех пользовательских приложений. Он предоставляет множество сервисов для приложений в виде вызовов Java API, включая менеджеры действий, ресурсов и уведомлений, поставщиков контента и систему просмотра. Именно поэтому приложения для Android в основном разрабатываются на Java, хотя собственные библиотеки обеспечивают некоторую поддержку C/C++. Совсем недавно также поддерживался и Kotlin, он даже предпочитался Google для разработки приложений Android. Код компилируется Android Software Development Kit (SDK) и архивируется в виде пакета Android (APK).

Android против Linux

Хотя некоторые считают Android дистрибутивом Linux, он имеет мало общего с обычной ОС Linux.

В традиционном стеке Linux ядро выполняет большую часть системных функций, включая управление памятью и файлами, аппаратное взаимодействие и планирование процессов. Системные функции предоставляются приложениям через библиотеки и вызовы API на языке Си. Именно поэтому GNU C является более важной библиотекой в Linux. Пользователи взаимодействуют с системой через оболочки, которые транслируют пользовательские команды в системные вызовы.

С другой стороны, Android можно рассматривать как пользовательское приложение, работающее в Linux. ОС использует ядро для взаимодействия с оборудованием и управления системой, а затем предлагает свои функции другим приложениям через интерфейс API. Этот интерфейс написан полностью на Java, и даже функции библиотек C/C ++ предложены в оболочках Java. В Android нет оболочки, хотя некоторые утилиты командной строки поддерживаются через приложение Toybox.

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

Ядро Android

Перед установкой на устройство само ядро Linux подвергается модификации несколькими участниками проекта. Во-первых, разработчики Android оптимизируют ядро LTS для мобильных устройств, вносят коррективы в функции Android и оставляют код как общее ядро AOSP. Разработчики AOSP реализуют большинство изменений в виде драйверов устройств, чтобы гарантировать внесение минимальных изменений в основной код ядра. Это позволяет с минимальными изменениями объединять обновления базового ядра в ACK. Поставщики оборудования добавляют драйверы и уровни абстракции для создания ядра поставщика. Затем, производители устройств обновляют ядро в соответствии со своими требованиями, реализуя новые драйверы или даже улучшая систему. Это ядро, в конечном счете, устанавливается на выпускаемые производителем устройства.

Разработка приложения

Основной принцип разработки в Android заключается в том, чтобы абстрагироваться от вариативности оборудования и предоставить унифицированный интерфейс для приложений. Это достигается запуском всех приложений на виртуальных машинах Java, подобных Dalvik или ART. Еще более способствует этой абстракции и упрощает разработку приложений комплект, состоящий из инфраструктуры Java API и SDK Android. Интерфейс API выполняет всю сложную работу, обеспечивая приложениям доступ к системным ресурсам лишь через вызов функции, в то время как SDK предоставляет визуальные инструменты для создания макетов приложений и управления вводом данных пользователя.

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

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

Заключение

При первых анонсах Open Handset Alliance их планы по взаимодействию при разработке открытой и многоцелевой платформы представлялись не более чем громким заявлением. Однако через десять лет платформа Android произвела революцию, и не только в мобильной индустрии. Фактически, она породила совершенно новые отрасли промышленности и коренным образом изменила наш образ жизни, работы и общения.

Источник

Введение в компоненты архитектуры Android

Android был представлен миру еще в 2005 году, и за эти 12 лет существования платформа достигла удивительного успеха, став самой установливаемой мобильной ОС. За это время было запущено 14 различных версий операционной системы, Android всегда становится более зрелой. Тем не менее, очень важная область платформы по-прежнему игнорировалась: стандартный шаблон архитектуры, способный обрабатывать особенности платформы и достаточно простой, чтобы его мог понять средний разработчик.

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

В этом уроке мы рассмотрим стандартизованную архитектуру, предложенную командой Android в Google I/O, и рассмотрим основные элементы новых компонентов архитектуры: Lifecycle , ViewModel , LifeData и Room . Мы не будем уделять слишком много внимания коду, вместо этого фокусируясь на концепции и логике этих тем. Мы также рассмотрим некоторые простые фрагменты, все они написаны с использованием Kotlin, изумительного языка, который теперь официально поддерживается Android.

1. Чего не хватало Android?

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

Архитектура приложения

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

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

— Руководство по архитектуре и дизайну программного обеспечения Microsoft

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

Старые ошибки

До последнего Google I/O система Android не рекомендовала какую-либо конкретную архитектуру для разработки приложений. Это означает, что вы были совершенно свободны в принятии любой модели: MVP, MVC, MVPP или даже отсутствие какого либо шаблона вообще. Кроме того, инфраструктура Android даже не предоставляла собственные решения проблем, создаваемых самой системой, в частности жизненного цикла компонента.

Итак, если вы хотите использовать шаблон Model View Presenter для вашего приложения, вам нужно было придумать свое собственное решение с нуля, написать много шаблонов кода или взять библиотеку без официальной поддержки. И это отсутствие стандартов создало много плохо написанных приложений, с кодовыми базами, которые трудно поддерживать и тестировать.

Как я уже сказал, эта ситуация подвергалась критике годами. На самом деле, я недавно написал об этой проблеме и о том, как ее решить в разделе «Как использовать модель View Presenter для Android». Но важно то, что через 12 лет команда Android наконец решила выслушать наши жалобы и помочь нам в решении этой проблемы.

2. Android-архитектура

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

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

Новая рекомендуемая архитектура

Архитектура, которую рекомендует Android, не может быть легко отмечена среди стандартных шаблонов, которые мы знаем. Она похожа на шаблон Model View Controller, но она настолько тесно связана с архитектурой системы, что трудно помечать каждый элемент, используя известные соглашения. Однако это не актуально, так как важно, чтобы архитектура основывалась на новых компонентах для создания разделения обязанностей, с хорошей способностью к тестированию и сопровождению. А еще лучше, ее легко реализовать.

Чтобы понять, что предлагает команда Android, мы должны знать все элементы компонентов архитектуры, так как именно они будут делать все тяжелую работу для нас. Есть четыре компонента, каждый из которых имеет определенную роль: Room , ViewModel, LiveData и Lifecycle . У всех этих частей есть свои обязанности, и они работают вместе, чтобы создать прочную архитектуру. Давайте рассмотрим упрощенную схему предлагаемой архитектуры, чтобы лучше понять ее.

Как вы можете видеть, у нас есть три основных элемента, каждый из которых имеет свою ответственность.

1. Activity и фрагмент Fragment собой слой View , который не имеет дело с бизнес-логикой и сложными операциями. Он только настраивает представление, обрабатывает взаимодействие пользователя и, самое главное, наблюдает и демонстрирует элементы LiveData , взятые из ViewModel .
2. ViewModel автоматически отслеживает состояние Lifecycle у представления, сохраняя согласованность во время изменений конфигурации и других событий жизненного цикла Android. Также требуется представление для извлечения данных из Repository , который предоставляется в качестве наблюдаемого LiveData . Важно понимать, что ViewModel никогда не ссылается на View напрямую и что обновления данных всегда выполняются объектом LiveData .
3. Repository не является специальным компонентом Android. Это простой класс без какой-либо конкретной реализации, который отвечает за выборку данных из всех доступных источников, от базы данных до веб-служб. Он обрабатывает все эти данные, как правило, преобразуя их в наблюдаемые LiveData и делая их доступными для ViewModel .
4. База данных Room — это библиотека SQLite, которая облегчает процесс работы с базой данных. Она автоматически записывает кучу готового кода, проверяет ошибки во время компиляции, и, самое главное, она может напрямую возвращать запросы с наблюдаемыми LiveData .

Я уверен, что вы заметили, что мы много говорили о наблюдателях. Шаблон Наблюдатель является одним из базовых для компонентов LiveData и Lifecycle . Этот шаблон позволяет объекту уведомлять список наблюдателей о любых изменениях в его состоянии или данных. Поэтому, когда Activity наблюдает объект LiveData , он будет получать обновления, когда эти данные подвергаются какой-либо модификации.

Еще одна рекомендация для Android состоит в том, чтобы консолидировать свою архитектуру, используя систему Injection Dependency, такую как Dagger 2 от Google, или используя шаблон Service Locator (который проще, чем DI, но без ряда его преимуществ). Мы не будем рассматривать DI или Service Locator в этом уроке, но у Envato Tuts + есть отличные уроки по этим темам. Однако имейте в виду, что есть некоторые особенности работы с Dagger 2 и компонентами Android, которые будут объяснены во второй части этой серии.

3. Компоненты архитектуры

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

Компоненты, связанные с жизненным циклом

У большинства компонентов приложения Android есть привязанные к ним жизненные циклы, которые управляются непосредственно самой системой. До недавнего времени разработчику приходилось следить за состоянием компонентов и действовать соответственно, инициализировать и заканчивать задачи в соответствующее время. Однако было очень легко запутаться и сделать ошибки, связанные с этим типом операции. Но пакет android.arch.lifecycle все это изменил.

Теперь к действиям и фрагментам привязан объект Lifecycle , который можно наблюдать с помощью классов LifecycleObserver , например ViewModel или любого объекта, реализующего этот интерфейс. Это означает, что наблюдатель получит обновления об изменениях состояния объекта, которые он наблюдает, например, когда действие приостановлено или когда оно запущено. Он также может проверять текущее состояние наблюдаемого объекта. Поэтому теперь гораздо проще обрабатывать операции, которые должны учитывать жизненные циклы фреймворка.

На данный момент для создания Activity или Fragment , который соответствует этому новому стандарту, вы должны унаследовать от LifecycleActivity или LifecycleFragment . Однако вполне возможно, что это не всегда будет необходимо, так как команда Android стремится полностью интегрировать эти новые инструменты со своей структурой.

LifecycleObserver получает события Lifecycle и может реагировать через аннотацию. Не требуется переопределение метода.

Компонент LiveData

Компонент LiveData является держателем данных, который содержит значение, которое можно наблюдаться. Учитывая, что наблюдатель предоставил Lifecycle во время создания LiveData , LiveData будет вести себя в соответствии с состоянием Lifecycle . Если состояние Lifecycle наблюдателя STARTED или RESUMED , наблюдатель active ; В противном случае он inactive .

LiveData знает, когда данные были изменены, а также когда наблюдатель active и должен получать обновление. Еще одна интересная характеристика LiveData заключается в том, что она способна удалять наблюдателя, если он находится в состоянии Lifecycle.State.DESTROYED , избегая утечек памяти при наблюдении за действиями и фрагментами.

LiveData должен реализовывать методы onActive и onInactive .

Чтобы наблюдать компонент LiveData , вы должны вызвать observer(LifecycleOwner, Observer ) .

Компонент ViewModel

Одним из наиболее важных классов новых компонентов архитектуры является ViewModel , который предназначен для хранения данных, связанных с пользовательским интерфейсом, сохраняя свою целостность во время изменений конфигурации, таких как вращения экрана. ViewModel может общаться с Repository , получая LiveData от него и делая его доступным, в свою очередь, для наблюдения из отображения. ViewModel также не потребуется создавать новые вызовы в Repostitory после изменений конфигурации, что значительно оптимизирует код.

Чтобы создать модель представления, отнаследуйтесь от класса ViewModel .

Чтобы получить доступ из представления, вы можете вызвать ViewProviders.of(Activity | Fragment).get (ViewModel::class) . Этот фабричный метод вернет новый экземпляр ViewModel или при необходимости сохранит его.

Room компонент

Android с самого начала поддерживает SQLite; Однако, чтобы заставить его работать, всегда приходилось писать много начального кода. Кроме того, SQLite не сохранял POJO (простые старые объекты Java) и не выполнял запросы во время компиляции. Room пришел чтобы решить эти проблемы! Это библиотека сопоставления SQLite, способная сохранять Java POJO, напрямую конвертировать запросы в объекты, проверять ошибки во время компиляции и получать данные LiveData из результатов запроса. Room представляет собой библиотеку реляционных объектов с некоторыми классными дополнениями для Android.

До сих пор вы могли бы сделать большую часть того, что может Room , используя другие ORM библиотеки Android. Однако ни одна из них официально не поддерживается и, самое главное, они не могут возвращать результаты в виде LifeData . Библиотека Room идеально подходит как слой хранения данных предлагаемой архитектуры Android.

Чтобы создать базу данных Room , вам понадобится @Entity , которая может быть любым Java POJO, интерфейс @Dao для создания запросов и операций ввода-вывода, а также абстрактный классом @Database , который должен расширять RoomDatabase .

Добавление компонентов архитектуры в ваш проект

На данный момент для использования новых компонентов архитектуры вам необходимо сначала добавить репозиторий Google в файл build.gradle . Для получения дополнительной информации см. Официальное руководство.

Заключение

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

Мы говорили о большинстве тем, связанных с предлагаемой архитектурой Android и ее компонентами; Однако эта первая часть не может быть описана в деталях о некоторых дополнительных функциях, таких как класс Repository и система Dagger 2 . Мы рассмотрим эти темы в следующих статьях.

Источник