Архитектура android что это

Архитектура Android

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

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

Для разработки приложений под платформу Android потребуется набор инструментов и библиотек API — Android SDK, последнюю версию которого вы можете найти здесь.

На представленном ниже рисунке показана архитектура ОС Android.

Уровень приложений (Applications)

В состав Android входит комплект базовых приложений: клиенты электронной почты и SMS, календарь, различные карты, браузер, программа для управления контактами и много другое. Все приложения, запускаемые на платформе Android написаны на языке Java.

Уровень каркаса приложений (Application Framework)

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

Основой всех приложений является набор систем и служб:
1. Система представлений (View System) – это богатый набор представлений с расширяемой функциональностью, который служит для построения внешнего вида приложений, включающий такие компоненты, как списки, таблицы, поля ввода, кнопки и т.п.
2. Контент-провайдеры (Content Providers) – это службы, которые позволяют приложениям получать доступ к данным других приложений, а также предоставлять доступ к своим данным.
3. Менеджер ресурсов (Resource Manager) предназначен для доступа к строковым, графическим и другим типам ресурсов.
4. Менеджер извещений (Notification Manager) позволяет любому приложению отображать пользовательские уведомления в строке статуса.
5. Менеджер действий (Activity Manager) управляет жизненным циклом приложений и предоставляет систему навигации по истории работы с действиями.

Уровень библиотек (Libraries)

Платформа Android включает набор C/C++ библиотек, используемых различными компонентами ОС. Для разработчиков доступ к функциям этих библиотек реализован через использование Application Framework. Ниже представлены некоторые из них:
1. System C library — BSD-реализация стандартной системной библиотеки C (libc) для встраиваемых устройств, основанных на Linux.
2. Media Libraries – библиотеки, основанные на PacketVideo‘s OpenCORE, предназначенные для поддержки проигрывания и записи популярных аудио- и видео- форматов (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG и т.п.).
3. Surface Manager – менеджер поверхностей управляет доступом к подсистеме отображения 2D- и 3D- графических слоев.
4. LibWebCore – современный движок web-браузера, который предоставляет всю мощь встроенного Android-браузера.
5. SGL – движок для работы с 2D-графикой.
6. 3D libraries – движок для работы с 3D-графикой, основанный на OpenGL ES 1.0 API.
7. FreeType – библиотека, предназначенная для работы со шрифтами.
8. SQLite – мощный легковесный движок для работы с реляционными БД.

Уровень среды исполнения (Android Runtime)

В состав Android входит набор библиотек ядра, которые предоставляют большую часть функциональности библиотек ядра языка Java.

Платформа использует оптимизированную, регистр-ориентированную виртуальную машину Dalvik, в отличии от нее стандартная виртуальная машина Java – стек-ориентированная. Каждое приложение запускается в своем собственном процессе, со своим собственным экземпляром виртуальной машины. Dalvik использует формат Dalvik Executable (*.dex), оптимизированный для минимального использования памяти приложением. Это обеспечивается такими базовыми функциями ядра Linux, как организация поточной обработки и низкоуровневое управление памятью. Байт-код Java, на котором написаны ваши приложения, компилируются в dex-формат при помощи утилиты dx, входящей в состав SDK.

Уровень ядра Linux (Linux Kernel)

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

Источник

Разбираемся с новыми архитектурными компонентами в Android

Гостевая статья от участника Google I\O 2017 и одного из лидеров GDG Kazan — Артура Василова (@Arturka).

19 мая завершилась конференция Google I/O. По поему мнению, несмотря на то, что новых продуктов в этом году было представлено не так много, с технической точки зрения конференция получилась интересной.

Самым большим и интересным техническим обновлением лично для меня стали новые Architecture Components (не Android O, в котором мало чего интересного, и уж точно не Kotlin). Google сделал то, что должен был сделать уже очень давно — разработать стандарты архитектуры и предоставить их разработчикам. Что же, лучше поздно, чем никогда, и давайте разбираться с тем, насколько полезной может быть архитектура от Google.

Первое впечатление

Лично меня название докладов не заинтересовало настолько, что я даже не посещал их, так как не верил, что Google в этой области может сделать что-то интересное, а не просто повторить Mosby/Moxy/ . Такой же скепсис сохранился и после быстрого просмотра разработанных библиотек. Однако через некоторое время пришлось поменять свое мнение, так как:

• Google действительно сделали хорошую библиотеку с удобным API;
• Google не стал закрываться, а учел все современные наработки в области архитектуры Android-приложений, взяв лучшее из всего;
• У новичков наконец-то есть хорошая документация, которая поможет им начать разрабатывать приложения уже с неплохой архитектурой, без необходимости детально вникать в смысл MVP/MVVM и т.д.

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

Хорошая архитектура

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

• Позволяет декомпозировать логику (получение данных/обработка/взаимодействие с пользователем и т.д.);
• Масштабируемость. Слово, которое должно быть в любой статье про архитектуру. В Android с этим все достаточно просто, так как любое приложение можно разбить на экраны, между которыми будут весьма прозрачные связи, а архитектуру отдельного экрана сделать масштабируемой не представляется сложным;
• Позволяет писать тесты для бизнес-логики приложения.

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

1. Обработка пересоздания Activity. Вероятно, самая многострадальная тема при построении архитектуры приложения, которая не нуждается в комментариях;
2. Выполнение HTTP запросов (как на получение данных, так и на отправку);
3. Поддержка потоков данных, например, при работе с сокетами/сенсорами;
4. Кэширование данных;
5. Обработка ошибок.

Разумеется, пункты 2-5 должны выполняться с учетом первого пункта.

Достаточно долго Android-разработчики самостоятельно решали все эти проблемы, но постепенно накопившийся опыт привел к появлению Clean Architecture. Подходы Clean Architecture очень хороши, за исключением того, что часто в приложении неуместно разбиение логики на UI и бизнес (так как один из слоев может почти не содержать кода), поэтому многие разработчики используют архитектуру, которую можно представить следующей схемой (немного переставив блоки из Clean Architecture):

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

Архитектура от Google

Сразу посмотрим на схему от Google:

Возможно, мне показалось, но по-моему, предыдущую схему просто повернули вертикально. И этим я не хочу сказать, что Google присвоил себе что-то старое, напротив, это показывает то, что Google присматривается к мнению разработчиков и учитывает все их достижения, что не может не радовать.

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

Одной из больших проблем в Android является необходимость постоянно подписываться/отписываться от каких-то объектов при вызове методов жизненного цикла. И поскольку методы жизненного цикла есть только в Activity/Fragment все такие объекты (например, GoogleApiClient, LocationManager, SensorManager и другие) должны быть расположены только в Activity/Fragment, что приводит к большому количеству строк кода в этих файлах.

Для решения этой и других проблем Google предложил использовать класс LiveData — класс, который тесно связан с жизненным циклом и который реализует паттерн Observer. По большому счету это очень простой класс, инкапсулирующий в себе работу с одним объектом, который может изменяться и за изменением которого можно следить. И это опять-таки достаточно стандартный подход.

Рассмотрим, как мы можем использовать LiveData, например, для того, чтобы следить за изменением местоположения пользователя. Создадим следующий класс:

И теперь мы можем написать следующий код в Activity:

Все нужные методы жизненного цикла у LiveData будут вызываться за счет первого параметра в методе observe — LifecycleOwner. Это позволяет нам знать, когда нужно подписываться и отписываться от различных объектов (например, с помощью методов onActive и onInactive).

LifecycleActivity — это класс из библиотеки, который реализует интерфейс LifecycleOwner. К сожалению, он почему-то унаследован от FragmentActivity, а не от AppCompatActivity, и, если вы хотите все же наследоваться от AppCompatActivity, придется написать некоторый код самому:

Кроме методов onActive и onInactive в LiveData вы можете получать коллбэки на любой метод жизненного цикла.

Точно такую же модель можно использовать и для реализации серверных запросов. То есть мы никаким образом не меняем способ получения данных (все также через Repository), но делегируем данные в LiveData, которая по сути является биндингом для View.

И теперь встает главный вопрос — как бороться с проблемой жизненного цикла? Разумеется, Google об этом подумал и дал разработчикам компонент, который переживает пересоздание Activity — ViewModel.

Пару слов про ViewModel:

1. Все экземпляры ViewModel хранятся в retain Fragment (HolderFragment). Это весьма стандартное решение, которым также пользовались многие разработчики.
2. Класс ViewModel должен хранить все экземпляры LiveData, чтобы они переживали пересоздание Activity.
3. Связь ViewModel с View осуществляется через LiveData, то есть ViewModel не управляет View явным образом, и это можно считать некоторой вариацией паттерна MVVM.

Разберем, как мы можем реализовать серверный запрос для какого-либо экрана. Создадим ViewModel, которая будет управлять логикой экрана:

Тогда View сможет использовать эту ViewModel следующим образом:

Поскольку ViewModel переживает пересоздание Activity, LiveData будет создана только один раз и серверный запрос будет выполнен только один раз, то есть эти проблемы решены. Остается вопрос создания ViewModel.

Для доступа к ViewModel используется класс ViewModelProviders:

Однако здесь есть небольшая проблема. Когда мы используем не конструктор по умолчанию (а в примере выше мы передавали в конструктор объект Repository), нам придется писать свою фабрику для создания ViewModel:

И теперь мы можем создать ViewModel следующим образом:

В данном примере мы вручную передаем в Factory все нужные объекты для создания ViewModel, однако единственным нормальным подходом для создания ViewModel при росте числа параметров является Dagger. Здесь Google фактически вынуждает использовать его. Хорошо это или плохо, решать вам.

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

Показ прогресса и обработка ошибок

Когда я только начал разбираться с новыми архитектурными компонентами, у меня сразу возник вопрос относительно того, как с помощью LiveData обрабатывать ошибки или получать изменение прогресса. Ведь все, что у нас есть — это экземпляр одного класса, который мы должны передавать в Activity/Fragment. Аналогичный вопрос возникает и с отображением прогресса. Такая проблема немного похожа на проблему с лоадерами, однако здесь есть два варианта, как ее решить.

Во-первых, мы можем создать некоторый класс, объект которого будет инкапсулировать в себе статус запроса, сообщение об ошибке и сами данные, и передавать этот объект в Activity/Fragment. Этот способ рекомендуется в документации. Такой класс может выглядеть, например, следующим образом (пока что разберем только обработку ошибок):

Тогда при каждом изменении мы передаем во View объект этого класса:

И View обрабатывает его соответствующим образом:

И во-вторых есть способ, который на мой взгляд является более лаконичным. В конце концов, статус запроса и ошибки — это тоже некоторые изменяющиеся данные. Тогда почему бы не поместить их в LiveData и не подписываться на их изменения? Для этих целей мы можем написать следующий код (а в этой ситуации уже рассмотрим обработку статуса загрузки):

И теперь View будет подписываться не на одну LiveData, а на несколько. Это может быть очень удобно, если мы пишем общий обработчик отображения прогресса или ошибок):

В итоге можно сказать, что обработка ошибок с помощью LiveData почти так же хороша, как и с помощью привычной RxJava.

Тестирование

Как уже было сказано выше, хорошая архитектура должна позволять тестировать приложение. Поскольку принципиальных изменений архитектура от Google не несет, то тестирование можно рассматривать только на уровне ViewModel (так как мы знаем, как тестировать Repository/UI).

Тестирование ViewModel всегда чуть сложнее, чем тестирование Presenter-а из паттерна MVP, так как в MVP явная связь между View и Presenter позволяет легко проверять, что были вызваны нужные методы у View. В случае MVVM нам приходится проверять работу биндингов или же LiveData.

Создадим тестовый класс, в котором в методе setUp создадим ViewModel:

Чтобы протестировать корректность ViewModel, мы должны убедиться, что она выполняет запрос к Repository и передает полученные данные в LiveData:

Здесь опустим лишние детали, но при необходимости можно использовать возможности Mockito, чтобы удостовериться, что в LiveData пришли именно те данные, которые нужно.

Однако такой тест не сработает, так как метод setValue в классе LiveData проверяет, что он вызывается в главном потоке приложения (разумеется, с помощью Looper):

Как мы прекрасно знаем, тесты на JUnit этого не любят и падают. Но разработчики Google предусмотрели и это. Для этого нужно подключить дополнительную библиотеку для тестов и добавить правило к тесту:

Аналогичным образом мы можем протестировать показ прогресса во время загрузки данных:

Таким образом, мы можем без особых проблем писать тесты на все нужные компоненты.

Кэширование данных

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

Все прекрасно знают про существующий огромный зоопарк библиотек для баз данных в Android. Это Realm, greenDao, ObjectBox, DBFlow, SQLBrite и много других. Поэтому многие разработчики не знают, что выбрать для своего проекта, и здесь Room является идеальным вариантом, как минимум потому, что она от Google.

Room является достаточно простой библиотекой, которая работает поверх SQLite, использует аннотации для генерации boilerplate кода и имеет достаточно привычный и удобный API. Однако я не считаю, что смогу рассказать про Room что-то более интересное, чем было в сессии на Google I/O и чем есть в документации. Поэтому здесь мы закончим рассмотрение архитектурных новинок.

Источник