В этой статье мы рассмотрим архитектуру Android-приложений.
Честно говоря, чиновник статья Я считаю, что Google в этой теме не очень полезен.
Подробно отвечая на вопрос «как», он совершенно не объясняет «что» и «почему».
Итак, вот моя версия, и я надеюсь, что она внесет некоторую ясность.
Да, кстати, я полностью призываю читать статьи Google, так как они содержат полезную информацию, которую я не собираюсь повторять.
Архитектура ОС Android – немного истории
Как это часто бывает в ИТ, многие вещи невозможно объяснить вне истории конкретного программного обеспечения.Вот почему мы должны вернуться к истокам ОС Android. Разработку ОС Android начала в 2003 году молодая компания Android Inc. В 2005 году эту компанию купила Google. Я считаю, что основные особенности архитектуры Android определились именно в этот период. Это не только заслуга Android Inc; Архитектурные концепции и финансовые ресурсы Google оказали решающее влияние на архитектуру Android. Ниже я приведу несколько примеров.
Если помните, 2003-2005 годы ознаменовались повышенным вниманием к AJAX-приложениям.
Я думаю, это оказало фундаментальное влияние на архитектуру Android: во многих аспектах она ближе к архитектуре типичного AJAX-приложения, чем к настольному GUI-приложению, написанному на Java, C#, C++, VB и т. д. Я не знаю, почему это произошло.
Я предполагаю, что кто-то в Google придумал это в то время, когда Rich Internet Applications (RIA) в духе Google Docs или Gmail считались решением всех проблем.
На мой взгляд, эту идею нельзя назвать ни хорошей, ни плохой.
Просто помните, что приложения для Android сильно отличаются от настольных приложений.
Влияние архитектурной философии Eclipse проявляется в выборе реализации графического пользовательского интерфейса, который больше похож на SWT, чем на Swing.
Стандарты проектирования кода Android содержат «венгерскую нотацию», рожденную в стенах MS. Можно предположить, что тот, кто писал эти стандарты, ранее разрабатывал их для Windows.
Архитектурные уровни Android
Операционная система Android состоит из трех очень разных и сильно разделенных слоев:- Он основан на модифицированной и урезанной версии Linux, как я уже упоминал в одной из своих предыдущих статей.
статьи .
- Над уровнем Linux находится уровень инфраструктуры приложений, содержащий Виртуальная машина Далвик , веб-браузер, база данных SQLite , некоторые инфраструктурные «костыли» и Java API.
- И наконец, уровень Android-приложений, написанных в Google. Вообще говоря, они являются расширением уровня инфраструктуры, поскольку разработчик может использовать эти приложения или их части в качестве строительных блоков для своих собственных разработок.
уровень Linux
Представьте, что вы архитектор в молодой компании.Вам необходимо разработать ОС для нового типа устройств.
Чем ты планируешь заняться? Грубо говоря, у вас есть два варианта: реализовать собственные идеи, начиная с нуля, или использовать уже существующую ОС и адаптировать ее под свои устройства.
Реализация с нуля всегда звучит захватывающе для программистов.
В эти минуты мы все верим, что на этот раз мы все сделаем лучше, чем другие, и даже лучше, чем мы сами делали раньше.
Однако это не всегда практично.
Например, использование ядра Linux значительно снизило стоимость разработки (возможно, в некоторых случаях и без того чрезмерно высокую).
Давайте посмотрим правде в глаза: если кто-то решит создать что-то, напоминающее ядро Linux в его нынешнем состоянии, ему понадобится несколько миллионов долларов.
Если вы управляете Android Inc, то у вас по определению не может быть столько денег.
Если вы управляете Google, у вас будут такие деньги, но вы, вероятно, дважды подумаете, прежде чем тратить их на создание собственной ОС.
Вам также понадобится несколько лет, чтобы достичь текущего состояния Linux; Несколько лет задержки могут оказаться слишком поздними для выхода на рынок.
В аналогичной ситуации Apple решила построить Mac OS на базе Free BSD. Android Inc решила использовать Linux в качестве основы для Android. Исходники Free BSD и Linux находятся в свободном доступе и обеспечивают хорошую основу для любой разработки, будь то Apple или Google. Но в то время запустить стандартный Linux на мобильном устройстве было невозможно (сейчас это уже не так).
Устройства имели слишком мало оперативной и энергонезависимой памяти.
Эти процессоры были значительно медленнее по сравнению с компьютерными процессорами, которые обычно работают под управлением Linux. В результате разработчики Android решили минимизировать системные требования Linux. Если рассматривать Linux на высоком уровне, то это совокупность ядра (без которого не обойтись) и множества других, необязательных частей.
Вы даже можете запустить одно ядро без чего-либо еще.
Так что Google в любом случае вынуждена использовать ядро Linux как часть ОС Android. Кроме того, были рассмотрены дополнительные детали и выбраны самые необходимые.
Например, были добавлены сетевой брандмауэр IPTables и оболочка Ash. Любопытно, что был добавлен именно Эш, а не Баш, несмотря на то, что последний на порядок мощнее; Вероятно, это решение было основано на том, что Эш менее ресурсоемок.
Разработчики Android модифицировали ядро Linux, добавив поддержку оборудования, используемого в мобильных устройствах и, чаще всего, недоступного на компьютерах.
Выбор Linux в качестве основы оказал огромное влияние на все аспекты ОС Android. Сборка Android — это, по сути, разновидность процесса сборки Linux. Код Android управляется git (инструментом, предназначенным для управления кодом Linux).
И так далее.
Хоть все это и может быть интересно, но вы, скорее всего, никогда не затронете все эти конкретные моменты, пока ваша цель — просто разработка приложений для Android. Единственным исключением будет просмотр файловой системы с помощью команд ash. Главное, что нужно знать при разработке приложений для Android, — это уровень инфраструктуры приложения.
Вы можете спросить, что делать, если вам нужно разработать нативное приложение для Android? Google настоятельно не рекомендует этого делать.
Технически это, конечно, возможно, но в дальнейшем вы не сможете распространять это приложение обычным способом.
Поэтому подумайте дважды, прежде чем приступать к разработке нативной ОС Android, если, конечно, вы не работаете над Android Open Source Project (AOSP), то есть над самой ОС Android.
Уровень инфраструктуры приложений
Несмотря на некоторую схожесть ОС Apple iOS и Android, между архитектурными решениями на уровне инфраструктуры обеих ОС существуют существенные различия.Apple решила использовать Objective-C в качестве языка программирования и среды выполнения приложения iOS. Objective-C кажется более или менее естественным выбором для ОС на базе Free BSD. Вы можете думать о Objective-C как об обычном C++ со специальным препроцессором, который добавляет некоторые специфические лингвистические конструкции.
Почему мы не можем использовать стандартный C++, на котором написана Free BSD? Мне кажется, причина в том, что Apple пытается все сделать в своем «яблочном» стиле.
Основная идея заключается в том, что приложения iOS написаны более или менее на том же языке, что и ОС, стоящая за ними.
Приложения для Android в этом смысле сильно отличаются.
Они написаны на языке Java, который совершенно отличается от C++ (хотя синтаксис унаследован от C++).
Почему это так? Почему, например, Android-приложения не написаны на C++? Никаких пояснений от Google я не нашел, поэтому могу только поделиться своими мыслями.
Я думаю, что основная причина — необходимость запуска одного и того же приложения на разном оборудовании.
Эта проблема возникает только для ОС Android; У ребят из Apple такой проблемы нет. iOS работает только на собственном оборудовании, и Apple полностью контролирует весь процесс.
В случае с Android всё наоборот: Google не контролирует производителей оборудования.
Например, ОС Android работает на процессорах x86, ARM и Atom (в комментариях предполагается, что x86 включает в себя Atom, а Android работает на процессорах x86, ARM, PPC и MIPS — примечание переводчика ).
На двоичном уровне эти архитектуры несовместимы.
Если бы архитекторы ОС Android выбрали тот же путь, что и архитекторы Apple, разработчикам приложений Android пришлось бы распространять несколько версий одного и того же приложения одновременно.
Это было бы серьёзной проблемой, которая могла бы привести к краху всего проекта Android. Чтобы одно и то же приложение могло работать на разном оборудовании, Google использовал архитектуру на основе контейнеров.
В такой архитектуре двоичный код выполняется программным контейнером и изолирован от деталей конкретного оборудования.
Примеры знакомы всем — Java и C#.
В обоих языках двоичный код не зависит от оборудования и выполняется виртуальной машиной.
Конечно, есть другой способ добиться аппаратной независимости на двоичном уровне.
Один из вариантов — использовать аппаратный эмулятор, также известный как КЕМУ .
Он позволяет эмулировать, например, устройство с процессором ARM на платформе x86 и так далее.
Google могла бы использовать C++ в качестве языка для разработки приложений внутри эмуляторов.
Действительно, Google использует этот подход в своих эмуляторах Android, построенных на базе QEMU. Хорошо, что не пошли по этому пути, ведь тогда кому-то придется запускать ОС на эмуляторе, а это требует гораздо больше ресурсов, и как следствие скорость снизится.
Для достижения наилучшей производительности эмуляцию оставили только там, где ее нельзя было избежать, в нашем случае — в Android-приложениях.
Как бы то ни было, в Google пришли к решению использовать Java в качестве основного языка разработки приложений и среды их исполнения.
Я думаю, что это было важнейшее архитектурное решение, которое отличало Android от остальных мобильных ОС на базе Linux, существующих сегодня.
Насколько мне известно, ни один из них не имеет совместимости двоичного кода на уровне приложения.
Возьмем, к примеру МиГо .
Он использует C++ и Qt-фреймворк ; Несмотря на то, что Qt является кроссплатформенным, необходимость делать разные сборки для разных платформ не отпадает. Выбрав Java, следующим шагом было решить, какую виртуальную машину (JVM) использовать.
Из-за ограниченности ресурсов использовать стандартную JVM было сложно.
Единственным возможным выбором было использование Ява М? JVM разработан для мобильных устройств.
Однако счастье Google не было бы полным без разработки собственной виртуальной машины, и Далвик В.
М.
.
Dalvik VM отличается от других виртуальных машин Java следующим образом:
- Он использует специальный формат DEX для хранения двоичного кода, в отличие от форматов JAR и Pack200, которые являются стандартными для других виртуальных машин Java. Google заявил, что двоичные файлы DEX меньше, чем JAR. Я думаю, они могли бы с тем же успехом использовать Pack200, но решили пойти своим путем.
- Dalvik VM оптимизирован для одновременного запуска нескольких процессов.
- Dalvik VM использует архитектуру на основе регистров по сравнению со стековой архитектурой других JVM, что приводит к увеличению скорости выполнения и уменьшению размера двоичных файлов.
- Он использует собственный набор инструкций (не стандартный байт-код JVM).
- Возможен запуск (при необходимости) нескольких независимых Android-приложений в одном процессе.
- Выполнение приложения может «естественным образом» охватывать несколько процессов Dalvik VM (мы обсудим, что это означает позже).
Добавлено для поддержки:
- Специальный механизм сериализации объектов, основанный на классах Parcel и Parcelable. Функционально он преследует те же цели, что и Java Serializable, но получаемые данные меньше и потенциально более устойчивы к управлению версиями классов.
- Особый способ выполнения вызовов между процессами (IPC), основанный на языке определения интерфейса Android (AIDL).
- Специальный механизм сериализации объектов, основанный на классах Parcel и Parcelable. Функционально он преследует те же цели, что и Java Serializable, но получаемые данные меньше и потенциально более устойчивы к управлению версиями классов.
- До Android 2.2 Dalvik VM не поддерживал JIT-компиляцию, что серьезно снижало производительность.
Начиная с версии 2.2 скорость выполнения часто используемых приложений заметно увеличился .
Они также добавили несколько пакетов с открытым исходным кодом, которые не являются частью стандартного JDK: Надувной замок криптографический API, HTTPклиент с поддержкой разделения HTTP/HTTPS на стороне клиента.
Google также добавил веб-браузер на уровень инфраструктуры приложений.
Это не полноценный Google Хром для мобильных устройств, но очень близок к нему, так как основан на том же движке ВебКит и использует движок JavaScript V8 из Хрома.
Ведь это чрезвычайно современный и высокотехнологичный браузер.
Его можно интегрировать в любые приложения Android. Это все на сегодня.
В следующей статье мы сосредоточимся на архитектуре приложений Android. Обновление от переводчика.
В оригинале использована неправильная терминология.
Спасибо всем, кто указал на эти ошибки.
Следующие статьи:
- Архитектура Android-приложений.
Часть II. Архитектурные стили и узоры
- Архитектура Android-приложений.
Часть III. Основные части заявления
- Архитектура Android-приложений.
Часть IV – уровень интеграции
-
Vsphere 5 — Администратор Заметок
19 Oct, 24 -
Компактное Хранилище Емкостью 2 Тб.
19 Oct, 24
