Архитектура Android-приложений. Часть I — истоки

http://vladnevzorov.com/2011/04/18/android-application-architecture-part-i-background/
  • Перевод
В этой статье мы рассмотрим архитектуру Android-приложений.

Откровенно говоря, официальную статью Google по этой теме я считаю не очень полезной. Детально отвечая на вопрос «как», она совсем не объясняет «что» и «почему». Итак, вот моя версия, и, я надеюсь, она внесёт некоторую ясность. Да, кстати, я полностью одобряю чтение статей Google, поскольку они содержат полезную информацию, повторять которую я не собираюсь.

Архитектура ОС Android — немного истории


Как это часто бывает в IT, многие вещи не могут быть объяснены в отрыве от истории возникновения конкретного программного обеспечения. Вот почему мы должны обратиться к истокам ОС 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 заметно в выборе принципа реализации GUI, который больше похоже на SWT, нежели на Swing.

В стандартах оформления кода Android присутствует «венгерская нотация», рождённая в стенах MS. Можно предположить, что тот, кто писал эти стандарты, ранее занимался разработкой под Windows.

Архитектурные уровни Android

Операционная система Android имеет три весьма различных и сильно отделённых друг от друга уровня:

  1. В основе лежит модифицированная и урезанная версия Linux, как я и упоминал в одной из моих предыдущих статей.
  2. Над уровнем Linux находится уровень инфраструктуры приложения, содержащий виртуальную машину Dalvik, веб-браузер, базу данных SQLite, некие инфраструктурные «костыли» и Java API.
  3. И, наконец, уровень написанных в Google Android-приложений. Вообще говоря, они являются расширением уровня инфраструктуры, поскольку разработчик может использовать эти приложения или их части как строительные блоки для собственных разработок.

Рассмотрим эти слои один за другим и более подробно.

Уровень 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. Любопытно, что добавили именно Ash, а не Bash, не смотря на то, что последний на порядок мощнее; вероятно, это решение было основано на том, что 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 использовала контейнер-ориентированную архитектуру (container-based architecture). В такой архитектуре двоичный код выполняется программным контейнером и изолируется от деталей конкретного аппаратного обеспечения. Примеры всем знакомы — Java и C#. В обоих языках двоичный код не зависит от специфики аппаратного обеспечения и выполняется виртуальной машиной.

Конечно, есть и другой способ достигнуть независимости от аппаратного обеспечения на уровне двоичного кода. Как один из вариантов, можно использовать эмулятор аппаратного обеспечения, так же известный как QEMU. Он позволяет эмулировать, например, устройство с процессором ARM на платформе x86 и так далее. Google могла бы использовать C++ как язык для разработки приложений внутри эмуляторов. Действительно, Google использует такой подход в своих эмуляторах Android, которые построены на основе QEMU.

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

Как бы то ни было, компания Google пришла к решению использовать Java как основной язык разработки приложений и среды их выполнения.

Я думаю, это было критически важное архитектурное решение, которое поставило Android в стороне от остальных мобильных ОС на основе Linux, представленных в настоящее время. Насколько мне известно, ни у одной из них нет совместимости двоичного кода на уровне приложений. Возьмём для примера MeeGo. Она использует C++ и фреймворк Qt; не смотря на то, что Qt кроссплатформенный, необходимость делать разные сборки для разных платформ не исчезает.

Выбрав Java, нужно было решить, какую виртуальную машину (JVM) использовать. Ввиду ограниченности ресурсов использование стандартной JVM было затруднено. Единственным возможным выбором было использование Java ME JVM, разработанной для мобильных устройств. Однако счастье Google было бы неполным без разработки собственной виртуальной машины, и появилась Dalvik VM.

Dalvik VM отличается от других виртуальных Java-машин следующим:

  • Она использует специальный формат DEX для хранения двоичных кодов, в противовес форматам JAR и Pack200, которые являются стандартом для других виртуальных Java-машинах. Компания Google заявила, что бинарники DEX меньше, чем JAR. Я думаю, с тем же успехом они могли бы использовать Pack200, но они решили пойти своим путём.
  • Dalvik VM оптимизирована для выполнения нескольких процессов одновременно.
  • Dalvik VM использует архитектуру, основанную на регистрах против стековой архитектуры в других JVM, что приводит к увеличению скорости выполнения и уменьшению размеров бинарников.
  • Она использует собственный набор инструкций (а не стандартный байткод JVM)
  • Возможен запуск (если необходимо) нескольких независимых Android-приложений в одном процессе
  • Выполнение приложения может охватывать несколько процессов Dalvik VM «естественным образом» (позже мы обсудим, что это значит). Для поддержи этого добавлено:
    • Специальный механизм сериализации объектов, основанный на классах Parcel и Parcelable. Функционально преследуются те же цели, что и Java Serializable, но в результате данные имеют меньший объём и потенциально более терпимы к версионным изменениям классов.
    • Особый способ для выполнения вызовов между процессами (inter process calls, IPC), основный на Android Interface Definition Language (AIDL).
  • До Android 2.2 Dalvik VM не поддерживала JIT-компиляцию, что было серьёзным ударом по производительности. Начиная с версии 2.2, скорость выполнения часто используемых приложений заметно возросла.

Ребята из Google также пересмотрели стандартные пакеты Java JDK API. Они удалили некоторые из них (например всё, что касалось Swing) и добавили некоторое количество собственных — их имя начинается с «android».

Также они добавили несколько пакетов с открытым кодом, не являющихся частью стандартного JDK: Bouncy Castle crypto API, HTTPClient с поддержкой разделения HTTP/HTTPS на стороне клиента.

Также Google добавила веб-браузер в уровень инфраструктуры приложения. Это не полноценный Google Chrome для мобильных устройств, но очень близок к нему, поскольку основан на том же движке WebKit и использует движок JavaScript V8 из Chrome. В конце концов, это крайне современный и высокотехнологичный браузер. Он может быть интегрирован в любые Android-приложения.

На сегодня это всё. В следующей статье мы сосредоточим внимание на архитектуре Android-приложений.

Апдейт от переводчика. В оригинале использовалась не совсем верная терминология. Спасибо всем тем, кто указал на эти ошибки.

Следующие статьи:
Поделиться публикацией

Комментарии 53

    +2
    Поясните, а почему вы употребляете JVM в адрес DalvikVM? Там в последнем свой байткод, своя архитектура машины, свой формат исполняемых файлов, свой RMI (remote method invocation) и AIDL (не Java IIOP)?
      +3
      Но от этого Dalvik не перестаёт быть JVM. JVM от Oracle носит название HotSpot. Но оба они Java Virtual Machine по сути.
        +2
        Не понимаю, почему они Dalvik = Java Virtual Machine. Что должно измениться в Dalvik, чтобы он перестал быть JavaVM? Если я буду из Scala компилировать в .dex и выполнять на Dalvik, Dalvik останется JVM? Если да, то вопрос — а что там от Java?
          –1
          От Java там ЯП.
          Чтобы Dalvik перестал быть JVM его нужно заставить исполнять другой ЯП, например если Google заставит Dalvik исполнять Dart, то он из JVM станет D(art) VM.
            +8
            Там — это в Dalvik? Если я правильно понимаю, Dalvik не исполняет Java, он исполняет dex-коды, в котором никаких намёков на то, что это Java, нет — dalvik-код совершенно отличается от java-кода, потому что он регистровый
              –2
              Код — да, другой. Но ЯП который преобразовывается в этот код всё равно Java. Я это имел в виду. Хотя, не исключаю, что могу заблуждаться.
                0
                VM в данном случае интерпретирует не ЯП напрямую а некий байткод, по этому такое название некорректно. Кстати как раз на примере JVM и CLI — хорошо видно, что несколько совершенно разных ЯП компилируется в один и тот-же байткод (Java/Jyton/JRuby/Scala и т.д. в случае JVM и тонна всяких языков для CLI).
            +3
            Ребята, если вдаваться в статистику, то и JVM тоже не JavaVM, поскольку про Java она не знает, а работает с байткодом.
              +1
              … вдаваться в софистику… Сори, спать пора.
          +2
          Это не моя статья, это перевод vladnevzorov.com/2011/04/18/android-application-architecture-part-i-background/ Думаю, JVM — это класс программ, а не конкретная реализация. Вот Shark выше привёл пример Oracle HotSpot
            0
            Всё дело в том что JVM должна исполнять Java Byte code чтобы называться JVM. Грубо говоря я должен иметь возможности взять готовый class файл и выполнить на этой JVM без изменений. В этом вся суть JVM. Если этого нет, то это всё что угодно но не JVM. Не путайте pls Java Programming Language и Java Virtual Machine. Это разные вещи.
          0
          «В подобной ситуации компания Apple решила построить Mac OS на основе Free BSD. Android Inc приняла решение использовать Linux как основу для Android.»

          Как так? Mac отдельная ветка Unix с микроядром Mach, как раз Apple-то свою систему с нуля выстраивал…
          +9
          Apple решила использовать Objective C++ как язык программирования и среду выполнения приложения iOS. Objective C++ выглядит более или менее естественным выбором для ОС, в основе которой лежит Free BSD. Можно рассматривать Objective C++ как обычный C++ с кастомным препроцессором, который добавляет некоторые специфические лингвистические конструкции. Почему же нельзя использовать стандартный C++, на котором написана Free BSD? Мне кажется причина в том, что Apple старается всё делать в своём, «эппловском» стиле.

          Я понимаю, что это перевод, но после такого абзаца есть повод сильно задуматься над компетентностью автора и читать статью дальше
            +5
            И да, Dalvik JVM наверное как-то связана с Objective C++
              –2
              … и, честно говоря, компетентностью переводчика. Чего уж греха таить
              +13
              хотелось внести пару поправок:
              1. Не Objective C++, а Objective-C, известный также как Objective C, ObjC или Obj-C. автор оригинальной статьи глубоко заблуждается по этому поводу.
              2. Не QT, а Qt, ибо QT расшифровывается как QuickTime.
              3. >>Почему это так? Почему, например, Android-приложения не написаны на C++? Со стороны Google я не нашёл никаких объяснений, поэтому могу поделиться лишь собственными соображениями.

              наверное никто не слышал про gcc. однако проблема в стоимости разработки самих мобильных приложений.

              4. >>Тем не менее, это не всегда практично. Например, использование ядра Linux заменило уменьшило стоимость разработки (возможно где-то и без того чрезмерно большую). Согласитесь, если кто-то решит создать нечто, напоминающее ядро Linux в его сегодняшнем состоянии, ему потребуется несколько миллионов долларов.

              очнитесь! какие миллионы??? речь минимум о миллиарде и сотен тысяч человеко-часов!

              все это конечно же адресовано автору оригинального поста.
                0
                > речь минимум о миллиарде и сотен тысяч человеко-часов!
                То есть на один час работы человека у вас приходится несколько тысяч долларов? Неплохо.
                  0
                  ну, наверное, человекочасы это несколько утрированно, смысл в том, что кому— то, а именно, автору статьи кажется, что создание ядра ос можно сравнить с созданием 3D— шутера, например.
                    0
                    «потребуется несколько миллионов долларов» — речь же не о конкретной оценке трудоёмкости. просто имеется ввиду высокая стоимость и сложность такой работы
                      0
                      Конечно десятков миллионов человеко-часов, сотня тысяч — это небольшая фирма из 50 человек на неполный год работы.
                    +1
                    Соглашусь
                    с 3 пунктом. Кросс-компиляции и разные архитектуры не проблема для gcc, Ubuntu и Windows идут этим путем.
                    Главное же конечно было «замануха» для программистов, хотя я очень жалею, что они не выбрали LLVM, который архитектурно переносим и весь (!) Android API на этом не построили.

                    А так мы имеем серьезно тормозящие приложения, на некоторых алгоритмах NDK до сих пор работает в 2-10 раз быстрее, а для графики это очень существенно.
                      +1
                      Ну так подход в котором критические к производительности части пишутся на нативном языке, а потом склеиваются на простом скриптовом давно себя зарекомендовал как очень успешный.
                      0
                      >> Согласитесь, если кто-то решит создать нечто, напоминающее ядро Linux в его сегодняшнем состоянии, ему потребуется несколько миллионов долларов.

                      > очнитесь! какие миллионы? речь минимум о миллиарде и сотен тысяч человеко-часов!

                      Вы удивитесь:
                      ru.wikipedia.org/wiki/Linux_(ядро)#Оценка стоимости разработки с нуля
                        0
                        Совокупная стоимость разработки в Евросоюзе оценена в более чем 1 млрд евро (около 1,4 млрд долл. США) и чему здесь удивляться?
                        0
                        Не Objective C++, а Objective-C

                        Objective C++ тоже бывает. Вот, к примеру, тут упоминается: habrahabr.ru/post/137469/
                          0
                          Objective-C++ — это возможность самого компилятора GCC компилировать C++ код вместе с Obj-C, причем со своими ограничениями.
                          например, возможность вставки ассемблера в C, еще не делает последний Asm-C )
                        +3
                        DalvikVM никогда не была JVM. Это регистровая DEX-машина, использующая собственный байткод, полученный из откомпилированного java-байткода. Кстати, Oracle усмотрела в технологии Android нарушение интеллектуальной собственности и подала на Google в суд. Google пришлось оправдываться и объяснять, что Dalvik это не JVM и не имеет прямого отношения к Java™.

                        Возможно, Oracle заинтересуется мобильным сегментом рынка. И тогда JavaME станет конкурирующей платформой. Пока же удел JavaME, как и всегда — простые развлекательные приложения от операторов, вендоров услуг, и корпоративные клиенты на базе сотовых терминалов.
                          0
                          Не знаю, насколько это правда, но я слышал, что Java в качестве языка была выбрана, чтобы упростить процесс перехода на новую платформу тем разработчикам, которые писали под обычные телефоны, под Java ME.
                            0
                            не думаю, уж больно много отличий между j2me и андроидом. скорее это просто следствие выбора архитектуры
                            0
                            >> Dalvik JVM использует архитектуру, основанную на регистрах против стековой архитектуры в других JVM, что приводит к увеличению скорости выполнения и уменьшению размеров бинарников.

                            Это каких других?

                            HotStop от санок — стековый
                            JRockit от bea — стековый
                            Apache Harmony — регистровый, разработка загнулась так как апачи ни хотели покупать kit на проверку совместимости, а бесплатный не позволял им лицензироваться и называться jvm для работы в киосках и на мобилках, большинство наработок ушли в DalvikVM

                            По поводу стековости java для начала советую посмотреть во что jit превращает ваш код, поверьте параметры очень хорошо и часто передаются и в обычной java через регистры. А выражения «так как у нас регистровая vm, то она быстрее работает» во фразах разработчиков за последние несколько лет превратились «так как у нас регистровая vm, то для нее проще было написать более быстрый интерпретатор чем в стандартной java, а после проще написать jit». К тому же: javame на арм процессах умела jit еще когда андроид только начинался и обычных числодробильных тестах всегда уделывала dalvikvm.
                              0
                              А ведь и правда, совсем закрылся Хармони, я после конфликта с Ораклом ждал, что они все таки смогут.

                              Apache Harmony is retired at the Apache Software Foundation since Nov 16, 2011.
                              The information on these pages may be out of date, or may refer to resources that have moved or have been made read-only.
                              For more information please refer to the Apache Attic
                              harmony.apache.org/
                              0
                              Virtual Machine Showdown: Stack Versus Registers (PDF, 200кб) — здесь можно почитать более-менее обоснованное сравнение регистровой и стековой архитектур.
                                +2
                                >Apple решила использовать Objective C++ как язык программирования и среду выполнения приложения iOS. Objective C++ выглядит более или менее естественным выбором для ОС, в основе которой лежит Free BSD.

                                Parse error, segmentation fault.

                                Дальше уже просто читать не стал… Вопиющее незнание матчасти.
                                  0
                                  >Я думаю, это было критически важное архитектурное решение, которое поставило Android в стороне от остальных мобильных ОС на основе Linux, представленных в настоящее время. Насколько мне известно, ни у одной из них нет совместимости двоичного кода на уровне приложений. Возьмём для примера MeeGo. Она использует C++ и фреймворк QT; не смотря на то, что QT кроссплатформенный, необходимость делать разные сборки для разных платформ не исчезает.

                                  Вот за это решение и не хочется иметь ничего общего с ведром… Получилась некая вещь в себе, в которой можно писать только на джаве. Да и в случае Qt не такая уж проблема собрать под все известные платформы. OBS в помощь, а скорость исполнения таки выше, чем у жабы и батарейку меньше кушает.
                                    0
                                    >>> Получилась некая вещь в себе, в которой можно писать только на джаве.
                                    Не совсем так. Есть же PyGame subset for Android ( habrahabr.ru/post/119831/ ) и другие варианты писать приложения для Андроида, избегая Джавы.
                                      0
                                      а чой эта про ndk все забыли?
                                      +2
                                      Для меня наоборот огромным плюсом в разработке под Android является Java. Отличный сильный язык
                                        0
                                        а еще монодроид и вероятно еще куча вариантов
                                          0
                                          Они все через задницу работают. Нормально интегрируются только ЯП для которых есть поддержка в Davlick'е
                                        +1
                                        работает на процессорах с архитектурой x86, ARM и Atom

                                        С архитектурой Atom, значит. Занятно.
                                          +1
                                          Очень небрежный перевод.

                                          "...in many aspects it is closer to a typical AJAX application architecture than to any sort of desktop GUI application architecture based on Java or C# or C++ or VB etc."

                                          "… Во многих аспектах это (приложения Андроид) ближе к архитектуре типичного AJAX приложения, чем к любому настольному GUI приложению основанному на Java, С#, С++, VB и тому подобное. "

                                          Ваш перевод имеет совсем другой смысл. Ниже по тексту вы сами же пишите:

                                          «Просто помните, что Android-приложения очень сильно отличаются от десктопных.»

                                          FreeBSD писался и пишется на чистом C.

                                          Единственная OS писавшаяся на C++ это BeOS. И то только интерфейсная часть. Вся низкоуровневая логика там была написана на asm'е.

                                            0
                                            абсолютно правильное замечание по переводу. исправил и кармы вам плюсанул
                                            0
                                            спасибо за статью, только:
                                            Особый способ для выполнения вызовов внутри процессов (inter process calls, IPC)

                                            IPC всегда была межпроцессорной связью.

                                            А так — с удовольствием погрузился в экскурс.
                                              0
                                              вы абсолютно правы, исправил
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                спасибо, добавил примечание
                                                0
                                                Несмотря на некоторое сходство Apple iOS и Android ОС, существуют значительные отличия между архитектурными решениями на инфраструктурном уровне обоих ОС

                                                обеих.
                                                Спасибо за статью.
                                                  0
                                                  Блииинннн как я мог проглядеть эту статью… Спасибо АВТОРРРРРР

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое