На каком уровне архитектуры android находятся приложения applications
Платформа Android объединяет операционную систему, построенную на основе ядра ОС Linux, промежуточное программное обеспечение и встроенные мобильные приложения. Разработка и развитие мобильной платформы Android выполняется в рамках проекта AOSP (Android Open Source Project) под управлением OHA (Open Handset Alliance), руководит всем процессом поисковый гигант Google.
Android поддерживает фоновое выполнение задач; предоставляет богатую библиотеку элементов пользовательского интерфейса; поддерживает 2D и 3D графику, используя OpenGL стандарт; поддерживает доступ к файловой системе и встроенной базе данных SQLite.
С точки зрения архитектуры, система Android представляет собой полный программный стек, в котором можно выделить следующие уровни:
- Базовый уровень (Linux Kernel) - уровень абстракции между аппаратным уровнем и программным стеком;
- Набор библиотек и среда исполнения (Libraries & Android Runtime) обеспечивает важнейший базовый функционал для приложений, содержит виртуальную машину Dalvik и базовые библиотеки Java необходимые для запуска Android приложений;
- Уровень каркаса приложений (Application Framework) обеспечивает разработчикам доступ к API, предоставляемым компонентами системы уровня библиотек;
- Уровень приложений (Applications) - набор предустановленных базовых приложений.
Наглядное изображение архитектуры на рисунке 1.1.
Рассмотрим компоненты платформы более подробно.
В основании компонентной иерархии лежит ядро ОС Linux 2.6 (несколько урезанное), служит промежуточным уровнем между аппаратным и программным обеспечением, обеспечивает функционирование системы, предоставляет системные службы ядра: управление памятью, энергосистемой и процессами, обеспечение безопасности, работа с сетью и драйверами.
Уровнем выше располагается набор библиотек и среда исполнения. Библиотеки реализуют следующие функции:
- предоставляют реализованные алгоритмы для вышележащих уровней;
- обеспечивает поддержку файловых форматов;
- осуществляет кодирование и декодирование информации (например, мультимедийные кодеки);
- выполняет отрисовку графики и т.д.
Библиотеки реализованы на С/С++ и скомпилированы под конкретное аппаратное обеспечение устройства, вместе с которым они и поставляются производителем в предустановленном виде.
Рассмотрим некоторые библиотеки:
Среда исполнения включает в себя библиотеки ядра, обеспечивающие большую часть низкоуровневой функциональности, доступной библиотекам ядра языка Java, и виртуальную машину Dalvik, позволяющую запускать приложения. Каждое приложение запускается в своем экземпляре виртуальной машины, тем самым обеспечивается изоляция работающих приложений от ОС и друг от друга. Для исполнения на виртуальной машине Dalvik Java-классы компилируются в исполняемые файлы с расширением .dex с помощью инструмента dx, входящего в состав Android SDK. DEX (Dalvik EXecutable) - формат исполняемых файлов для виртуальной машины Dalvik, оптимизированный для использования минимального объема памяти. При использовании IDE Eclipse и плагина ADT (Android Development Tools) компиляция классов Java в формат .dex происходит автоматически.
Архитектура Android Runtime такова, что работа программ осуществляется строго в рамках окружения виртуальной машины, что позволяет защитить ядро ОС от возможного вреда со стороны других ее составляющих. Поэтому код с ошибками или вредоносное ПО не смогут испортить Android и устройство на его базе, когда сработают.
На еще более высоком уровне располагается каркас приложений (Application Framework), архитектура которого позволяет любому приложению использовать уже реализованные возможности других приложений, к которым разрешен доступ. В состав каркаса входят следующие компоненты:
- богатый и расширяемый набор представлений (Views), который может быть использован для создания визуальных компонентов приложений, например, списков, текстовых полей, таблиц, кнопок или даже встроенного web-браузера;
- контент-провайдеры (Content Providers), управляющие данными, которые одни приложения открывают для других, чтобы те могли их использовать для своей работы;
- менеджер ресурсов (Resource Manager), обеспечивающий доступ к ресурсам без функциональности (не несущим кода), например, к строковым данным, графике, файлам и другим;
- менеджер оповещений (Notification Manager), позволяющий приложениям отображать собственные уведомления для пользователя в строке состояния;
- менеджер действий (Activity Manager), управляющий жизненными циклами приложений, сохраняющий историю работы с действиями, предоставляющий систему навигации по действиям;
- менеджер местоположения (Location Manager), позволяющий приложениям периодически получать обновленные данные о текущем географическом положении устройства.
Application Framework предоставляет в распоряжение приложений в ОС Android вспомогательный функционал, благодаря чему реализуется принцип многократного использования компонентов приложений и ОС. Естественно, в рамках политики безопасности.
И, наконец, самый высокий, самый близкий к пользователю уровень приложений. Именно на этом уровне пользователь взаимодействует со своим устройством, управляемым ОС Android. Здесь представлен набор базовых приложений, который предустановлен на ОС Android. Например, браузер, почтовый клиент, программа для отправки SMS, карты, календарь, менеджер контактов и др. Список интегрированных приложений может меняться в зависимости от модели устройства и версии Android. К этому уровню также относятся все пользовательские приложения.
Разработчик обычно взаимодействует с двумя верхними уровнями архитектуры Android для создания новых приложений. Библиотеки, система исполнения и ядро Linux скрыты за каркасом приложений.
Для пополнения коллекции приложений своего мобильного устройства пользователь может воспользоваться приложением Google Play, которое позволяет покупать и устанавливать приложения с сервиса Google Play. Разработчики, в свою очередь, могут выкладывать свои приложения в этот сервис, Google Play отслеживает появление обновлений приложения, сообщает пользователям этого приложения об обновлении и предлагает установить его. Также Google Play предоставляет разработчикам доступ к услугам и библиотекам, например, доступ к использованию и отображению Google Maps.
Для установки приложения на устройствах с ОС Android создается файл с расширением *.apk (Android package), который содержит исполняемые файлы, а также вспомогательные компоненты, например, файлы с данными и файлы ресурсов. После установки на устройство каждое приложение "живет" в своем собственном изолированном экземпляре виртуальной машины Dalvik.
Классический рисунок представляющий архитектуру ОС Android:
Если кому-то сложно с английским, то на всякий случай то же самое по на русском:
Сразу приведу оригинальное видео с канала Android Developers на Youtube, где все авторитетно рассказывается и показывается, правда на враждебном нам буржуйском языке. Я использовал это видео, чтобы описать некоторые пункты архитектуры, описания которых не нашел в сети на русском языке.
Если представить компонентную модель Android в виде некоторой иерархии, то в самом низу, как самая фундаментальная и базовая составляющая, будет располагаться ядро операционной системы (Linux Kernel).
Часто компонентную модель ещё называют программным стеком. Действительно, это определение тут уместно, потому что речь идет о наборе программных продуктов, которые работают вместе для получения итогового результата. Действия в этой модели выполняются последовательно, и уровни иерархии также последовательно взаимодействуют между собой.
LINUX KERNEL (ЯДРО ЛИНУКС)
Как известно, Андроид основан на несколько урезанном ядре ОС Linux и поэтому на этом уровне мы можем видеть именно его (версии 2.6.x). Оно обеспечивает функционирование системы и отвечает за безопасность, управление памятью, энергосистемой и процессами, а также предоставляет сетевой стек и модель драйверов. Ядро также действует как уровень абстракции между аппаратным обеспечением и программным стеком.
APPLICATIONS (ПРИЛОЖЕНИЯ)
На вершине программного стека Android лежит уровень приложений (Applications). Сюда относится набор базовых приложений, который предустановлен на ОС Android. Например, в него входят браузер, почтовый клиент, программа для отправки SMS, карты, календарь, менеджер контактов и многие другие. Список интегрированных приложений может меняться в зависимости от модели устройства и версии Android. И помимо этого базового набора к уровню приложений относятся в принципе все приложения под платформу Android, в том числе и установленные пользователем.
Считается, что приложения под Android пишутся на языке Java, но нужно отметить, что существует возможность разрабатывать программы и на C/C++ (с помощью Native Development Kit), и на Basic (с помощью Simple) и с использованием других языков. Также можно создавать собственные программы с помощью конструкторов приложений, таких как App Inventor. Словом, возможностей тут много.
Думаю, что каждому начинающему разработчику тяжело понять как Android устроен и в принципе из чего он состоит. В этой статье я постараюсь наиболее детально и понятно расписать как система Android спроектирована.
Начнем со схемы, на которой визуально отображены все основные компоненты архитектуры, а ниже детально (насколько это возможно) рассмотрим каждый из них.
Linux Kernel
Данный уровень является базовым в архитектуре Android, так как вся система Android построена на ядре Linux с некоторыми архитектурными изменениями.
Основные задачи, выполняемые ядром.
Ядро содержит в себе драйверы, необходимые для взаимодействия с оборудованием. Например, возьмем Bluetooth. В наше время сложно найти устройство, которое бы не включало в себя эту функцию. Поэтому ядро должно включать драйвер для работы с ним. На схеме выше как раз таки перечислены все драйверы, входящие в ядро Linux, поэтому не будем перечислять их все по отдельности.
Power Management - это своего рода система управления питанием. Она предоставляет различные средства, с помощью которых приложение может реагировать на режимы питания устройства, а также поддерживать необходимые компоненты устройства активными. Например, при чтении книги нам было бы удобно, если бы экран оставался постоянно активным. Или когда мы включаем музыку и она продолжает проигрываться в фоне при отключенном экране.
Помимо вышеперечисленного, ядро Linux обеспечивает управление памятью и процессом.
Управление памятью.
При запуске различных приложений ядро гарантирует, что пространство памяти, которое они используют, не конфликтует и не перезаписывает друг друга. Также оно проверяет, что все приложения получают достаточный объем памяти для своей работы, и в то же время следит, чтобы ни одно приложение не занимало слишком много места.
Управление процессом.
Каждое приложение в Android работает в отдельном процессе. Ядро же отвечает за управление этими процессами, а именно за создание, приостановку, остановку, или завершение процессов, за одновременное выполнение нескольких процессов, обмен данными между процессами, запуск процессов в фоновом режиме. Помимо этого ядро распределяет работу между процессорами устройства, что максимизирует производительность устройств с несколькими ядрами.
Hardware Abstraction Layer (HAL)
HAL обеспечивает связь между драйверами и библиотеками. Состоит он из нескольких библиотечных модулей, каждый из которых реализует интерфейс для определенного аппаратного компонента (Bluetooth, Камера итд.). И когда к оборудованию устройства обращаются через API-интерфейс, загружается необходимый для его работы модуль.
Android Runtime (ART)
Основным языком Android был выбран Java, поскольку это один из самых популярных языков программирования. Для Java существует много наработок и специалистов, а написанные на нем программы переносимы между операционными системами.
Но для того, чтобы программа работала на Java необходима виртуальная машина ‒ Java Virtual Machine. В Android используется виртуальная машина Android Runtime (ART). Эта машина специально оптимизирована для работы на мобильных устройствах: с нехваткой памяти, с постоянной выгрузкой и загрузкой приложений и т.д. В версиях Android ниже 5.0 Lollipop, использовалась виртуальная машина Dalvik - старая реализация виртуальной машины для Android.
В ART, как и в Dalvik, используется свой формат байт-кода ‒ DEX (Dalvik executable). При сборке приложения исходные файлы сначала компилируются в файлы типа class обычным компилятором, а затем конвертируются специальной утилитой в DEX .
И Dalvik, и ART оптимизируют выполняемый код, используя механизм компиляции just-in-time (JIT) - компиляция происходит во время выполнения приложения, что позволяет оптимизировать код для выполнения на конкретном устройстве. При этом байт-код приложения можно переносить на другие устройства.
ART может компилировать байт-код заранее, а не во время выполнения, используя ahead-of-time (AOT). Система сама решает, когда и какие приложения необходимо скомпилировать. Например, когда устройство не загружено и подключено к зарядке. При этом ART учитывает информацию о приложении, собранную во время предыдущих запусков, что дает дополнительную оптимизацию.
Native C/C++ Libraries
Набор библиотек, написанных на языках C или C++ и используемых различными компонентами ОС.
- WebKit - представляет из себя движок веб-браузера и другие связанные с ним функции.
- Media Framework предоставляет медиа кодеки, позволяющие записывать и воспроизводить различные медиа-форматы.
- OpenGL - используется для отображения 2D и 3D графики.
- SQLite - движок базы данных, используемый в Android для хранения данных.
Java API Framework (Application Framework)
Набор API, написанный на языке Java и предоставляющий разработчикам доступ ко всем функциям ОС Android. Эти API-интерфейсы образуют строительные блоки, необходимые для создания приложений, упрощая повторное использование основных, модульных, системных компонентов и сервисов, таких как:
- Activity Manager - управляет жизненным циклом приложения и обеспечивает общий навигационный стек обратных вызовов.
- Window Manager - управляет окнами и является абстракцией библиотеки Surface Manager.
- Content Providers - позволяет приложению получать доступ к данным из других приложений или обмениваться собственными данными, т.е. предоставляет механизм для обмена данными между приложениями.
- View System - содержит строительные блоки для создания пользовательского интерфейса приложения (списки, тексты, кнопки итд.), а также управляет событиями элементов пользовательского интерфейса.
- Package Manager - управляет различными видами информации, связанными с пакетами приложений, которые в настоящее время установлены на устройстве.
- Telephony Manager - позволяет приложению использовать возможности телефонии.
- Resource Manager - обеспечивает доступ к таким ресурсам, как локализованные строки, растровые изображения, графика и макеты.
- Location Manager - возможность определения местоположения.
- Notification Manager - отображение уведомлений в строке состояния.
System Apps
Верхний уровень в архитектуре Android, который включает в себя ряд системных (предустановленных) приложений и тонну других приложений, которые можно скачать с Google Play.
Этот уровень использует все уровни ниже (если смотреть на схему) для правильного функционирования приложений.
Полезные ссылки
Официальная документация.
Hardware Abstraction Layer (HAL) на wiki.
Android Runtime на wiki.
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 . У всех этих частей есть свои обязанности, и они работают вместе, чтобы создать прочную архитектуру. Давайте рассмотрим упрощенную схему предлагаемой архитектуры, чтобы лучше понять ее.
Как вы можете видеть, у нас есть три основных элемента, каждый из которых имеет свою ответственность.
- Activity и фрагмент Fragment собой слой View , который не имеет дело с бизнес-логикой и сложными операциями. Он только настраивает представление, обрабатывает взаимодействие пользователя и, самое главное, наблюдает и демонстрирует элементы LiveData , взятые из ViewModel .
- ViewModel автоматически отслеживает состояние Lifecycle у представления, сохраняя согласованность во время изменений конфигурации и других событий жизненного цикла Android. Также требуется представление для извлечения данных из Repository , который предоставляется в качестве наблюдаемого LiveData . Важно понимать, что ViewModel никогда не ссылается на View напрямую и что обновления данных всегда выполняются объектом LiveData .
- Repository не является специальным компонентом Android. Это простой класс без какой-либо конкретной реализации, который отвечает за выборку данных из всех доступных источников, от базы данных до веб-служб. Он обрабатывает все эти данные, как правило, преобразуя их в наблюдаемые LiveData и делая их доступными для ViewModel .
- База данных 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<T>) .
Компонент 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 . Мы рассмотрим эти темы в следующих статьях.
Читайте также: