СРАВНИТЕЛЬНЫЙ АНАЛИЗ АРХИТЕКТУР КРОССПЛАТФОРМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.4

СРАВНИТЕЛЬНЫЙ АНАЛИЗ АРХИТЕКТУР КРОССПЛАТФОРМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В.Н. Черников, С.Л. Подвальный, В.Ф. Барабанов, В.В. Сафронов Воронежский государственный технический университет, г. Воронеж, Россия

Аннотация: дано описание архитектур, наиболее распространённых в производственной практике наборов инструментов и библиотек для кроссплатформенной разработки. Приведен обзор механизмов операционных систем, которые используют выбранные инструменты. Проведено сравнение кроссплатформенных инструментов с точки зрения архитектуры. Рассмотрены механизмы интеграции кроссплатформенной и платформозависимых частей программного продукта, а также указаны «узкие места» данных механизмов. Приведены рекомендации, которые позволяют определиться с выбором кроссплатформенного инструмента в различных командах инженеров. Рассмотрен такой класс программного обеспечения, как мобильные приложения. Смартфоны и планшеты набирают все большую популярность, вытесняя бумажные носители и стационарные компьютеры, предоставляя бизнес-подразделениям возможность использовать новые каналы и способы обмена информацией с клиентами и сотрудниками. В работе проведен сравнительный анализ наиболее популярных инструментов: PhoneGap, ReactNative, Xamarin и Qt. В качестве целевых платформ рассмотрены операционные системы iOS, Android и Windows UWP. Проведён детальный анализ архитектур кроссплатформенного программного обеспечения в части обоснования использования инструментов кроссплатфор-менной разработки; архитектуры и интерфейсов для интеграции операционных систем (iOS, Android, Windows UWP); архитектуры кроссплатформенных приложений (PhoneGap, ReactNative, Qt, Xamarin). Сформированы общие рекомендации по выбору инструмента разработки кроссплатформенных приложений

Ключевые слова: кроссплатформенная разработка, мобильные приложения, архитектуры компьютерных систем

Введение

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

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

В отличие от рынка стационарных компьютеров, где доминирует Windows, на рынке мобильной разработки есть 2 ведущие платформы: Apple iOS и Google Android. С целью оптимизации расходов, увеличения скорости разработки и утилизации существующих компетенций все шире начинают использоваться инструменты кроссплатформенной мобильной разработки.

В данной работе проведен сравнительный анализ наиболее популярных инструментов:

© Черников В.Н., Подвальный С.Л., Барабанов В.Ф., Сафронов В.В., 2018

PhoneGap, ReactNative, Xamarin и Qt. В качестве целевых платформ мы будем рассматривать операционные системы iOS, Android и Windows UWP.

1. Обоснование использования инструментов кроссплатформенной разработки

Исторически на рынке компьютеров всегда была конкуренция, и каждый производитель предоставлял оптимальный набор так называемых «нативных» (родных) инструментов для разработки приложений под свои операционные системы и устройства. "Нативные" средства разработки обеспечивают максимальную производительность и доступ к возможностям операционной системы.

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

Вторым важным моментом является наличие необходимых компетенций (знаний и опы-

та) внутри команды - если их нет, то потребуется время на обучение.

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

- максимизировать общую базу кода на едином языке программирования, чтобы продукт было проще разрабатывать и поддерживать;

- использовать существующие компетенции и специалистов для реализации приложений на новых платформах.

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

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

2. Архитектура и интерфейсы для интеграции операционных систем

Главный принцип, лежащий в основе кроссплатформенных приложений, - разделение кода на 2 части:

- кроссплатформенную, живущую в виртуальном окружении и имеющую ограниченный доступ к возможностям целевой платформы через специальный мост;

- нативную, которая обеспечивает инициализацию приложения, управление жизненным циклом ключевых объектов и имеющую полный доступ к системным API.

Общая архитектура кроссплатформенных приложений показана на рис. 1.

Для связи между "нативной" и "крос-сплатформенной" частями, необходимо использовать специальный мост (bridge), который

и определяет возможности и ограничения крос-сплатформенных инструментов.

Все кроссплатформенные приложения обязаны иметь нативную часть, поэтому давайте рассмотрим, какие системные API предоставляются самими iOS, Android и Windows.

Рис. 1. Общая архитектура кроссплатформенного приложения

2.1. Архитектура iOS

Нативные интерфейсы низкого уровня в iOS реализованы по аналогии с Unix (для С). Для iOS-разработчика выбор языков ограничивается Objective C и Swift, ведь именно для них реализованы нативные инструменты и API. Общая архитектура iOS представлена на рис. 2.

Дополнительно на схеме мы отметили компоненты, которые имеют значение для кроссплатформенных фреймворков:

- WebKit используется в гибридных приложениях на базе PhoneGap или аналогов для запуска приложений и фактически выступает средой выполнения веб-приложений [1];

- JavaScript Core используется в ReactNative и аналогах для быстрого выполнения JS-кода и обмена данными между Native и

JS [2];

- OpenGL ES используется в играх и приложениях на Qt/QML или аналогах для отри-совки интерфейса [3];

- UIKit отвечает за нативный пользовательский интерфейс приложения, что актуально для ReactNative и Xamarin.

Native Арр Objective С, C/C++ Native Арр Swift

.............. 1 ..............

* Swift API

Г

Userapp

OS

Objective С and С API

Cocoa Touch

Media

Core Services

UIKit, Address Book Ul, EventKit Ul, GameKit, ¡Ad, MapKit, Message Ul, Notification Center, PushKit, Twitter

UIKit graphics, Core Graphics, Core Animation, Core Image, OpenGL ES and GLKit, Metal, TextKIt and Core Text, Image I/O, Photos Library

Accounts, Address Book, Ad Support, CFNetwork, Core Data (+SQLite), CloudKit, Core Foundation, Core Location, Core Media, Core Motion, Core Telephony, EventKit, Foundation, HealthKit, HomeKit, JavaScript Core, Mobile Core Services, Multipeer Connectivity, NewsstandKit, PassKit, Quick Look, Social, StoreKit, System Configuration, WebKit

Core OS

Accelerate, Core Bluetooth, External Accessory, Generic Security Services, Local Authentication, Network Extension, Security, System

iOS

Рис. 2. Архитектура iOS

Kernel

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

Android также является Unix-системой и большей частью основан на Linux. В Android, поверх ядра Linux создана своя инфраструктура, включающая виртуальную машину Java (Java Virtual Machine, JVM) для запуска приложений. JVM выступает посредником между пользовательским кодом и набором системных API, доступных для Java-приложений. Поддержка языка Kotlin является надстройкой над той инфраструктурой, которая доступна Java. На рис. 3 показана архитектура Android.

Android Рис. 3. Архитектура Android

В Android разработчику доступно сразу целых 2 подсистемы: Native Development Kit (Android NDK) и Android SDK.

С помощью NDK можно получить доступ к низкоуровневым механизмам Android. Разработка ведется на С/С++.

При использовании Android SDK разработчик оказывается внутри Java-машины Dalvik (или Android Runtime, ART) и имеем только те возможности, которые предоставляет Java API.

Связующим звеном между библиотеками низкого уровня (на C/C++) и инфраструктурой Java выступает специальный JNI bridge (Java Native Interface), который и позволяет двум мирам взаимодействовать друг с другом. JNI выступает единым и универсальным связующим звеном, однако, как и любой мост, ведет к падению производительности приложения.

Помимо JNI bridge, в архитектуре Android также стоит выделить наличие подсистем WebKit (для PhoneGap), OpenGL ES (для Qt и игр) и View System (для ReactNative и Xamarin), аналогичные модулям в iOS.

2.3. Архитектура Windows UWP

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

Windows UWP

Рис. 4. Архитектура Windows

Помимо API для C++/C#, Windows UWP также предоставляет механизмы работы с JavaScript на базе модуля Chakra. Microsoft также поддерживает версию ReactNative на Windows UWP.

В системе доступен компонент WebView, необходимый PhoneGap. Реализации OpenGL ES нет, вместо нее доступен DirectX [4, 5].

3. Архитектуры кроссплатформенных приложений

Все операционные системы имеют те или иные технические возможности по запуску кроссплатформенных приложений. Самое простое с технической точки зрения - использование WebView, которое есть у всех ОС (актуально для PhoneGap). Вторым вариантом является использование механизмов низкого уровня (например, OpenGL ES и языка C/C++), это позволит разделять между проектами большинство логики (в играх или Qt), но будет ограниченно работать (или не работать) на Windows UWP. Если же необходим полный доступ к возможностям целевых операционных систем (ОС), то здесь начинают задействоваться системные API верхнего уровня - такой подход реализуется только в Xamarin и ReactNative.

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

3.1. Архитектура PhoneGap

Решения на базе PhoneGap используют WebView и являются простыми с точки зрения

реализации: создается небольшое «нативное» приложение, которое отображает встроенный веб-браузер и открывает в нем HTML-файл из ресурсов приложения. Из кода HTML нет прямого доступа к системным API, поэтому необходимо к WebView и HTML-коду подключать библиотеки, которые добавляют интерфейсы доступа к системной функциональности через объекты и классы JavaScript. На рис. 5 показана архитектура PhoneGap.

PhoneGap

webkit. WebView

ft ft 3 J^lLJL Л

Plugins Native libs

API, libs, Ul controls, services

API, libs, Ul controls, services

API, libs, Ul controls, services

Windows UWP

Рис. 5. Архитектура приложения на PhoneGap

Как видим, PhoneGap позволяет разделять практически весь код между платформами, однако все еще требуется реализация нативной части на Objective C и Java (и C# для Windows). Весь жизненный цикл приложения проходит внутри WebView.

Пользовательский интерфейс организован по принципу одностраничного HTML - в реальных приложениях со сложным интерфейсом будут подергивания и подтормаживания (особенности мобильных WebView, которые еще и могут отличаться у разных производителей). Для передачи данных через мост их необходимо сериализовать/десериализовать в Json. В целом мост используется редко, так как вся жизнь приложения проходит внутри WebView.

3.2. Архитектуры ReactNative

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

Рис. 6. Архитектура приложения на ReactNative

При создании приложений на ReactNative разработчику будет необходимо также реализо-вывать нативную часть на Objective C, Java или C#, которая инициализирует модуль исполнения кода на JavaScipt и передает в него нужные файлы из ресурсов приложения. Далее пользовательский код на JavaScript переключает на себя управление жизненным циклом и созданием пользовательского интерфейса [6, 7].

Для передачи данных и вызовов между кодом на JavaScript и нативной частями приложение также использует мост. Важно отметить, что для передачи сложных структур данных и классов между нативной частью и кодом на JavaScript их необходимо сериализо-вать/десериализовать в формате JSON.

3.3. Qt

Архитектура Qt позволяет портировать его в те операционные системы, которые имеют API для C++. И iOS, и Android (NDK), и Windows такой возможностью обладают, хотя и все со своими особенностями.

Один из главных плюсов Qt - собственная эффективная система отрисовки пользовательского интерфейса либо на базе растрового движка (например, CoreGraphics в iOS), либо на базе Open GL (ES). Именно это и делает фреймворк портируемым на новые операционные системы и среды исполнения. На рис. 7 показана архитектура Qt.

На iOS используются стандартные модули CoreGraphics и UIKit для отрисовки пользовательского интерфейса. В Android используются механизмы NDK для отрисовки UI, а для доступа к Java API и управления приложением используется уже знакомый нам мост JNI. Также в iOS и Android может использоваться Open GL ES для отрисовки QML или работы с 3D.

В Windows имеется прямой доступ к C++ API, но нет реализации Open GL (ES), поэтому необходимо использовать конвертацию вызовов Open GL ES в вызовы DirectX.

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

3.4. Xamarin

Xamarin является открытой реализацией инфраструктуры .NET для Unix-систем. Для взаимодействия с родными (для C) интерфейсами операционных систем в Mono используется механизм P/Invoke. На основе Mono были созданы фреймворки MonoTouch и MonoDroid, которые затем переименовали в Xamarin.iOS и Xamarin.Android, и теперь вместе называют "классическим Xamarin" (Xamarin Classic).

Классический Xamarin предоставляет полный доступ к системным API, то есть можно создавать нативные приложения iOS/Android. Нативные библиотеки подключаются через механизм байндинга (Native Library Binding). Взаимодействие с ОС происходит через мост и механизм оберток (wrappers), однако нет необходимости сериализовать данные, так как осуществляется автоматический маршалинг и есть возможность прямой передачи ссылок между средами Mono Managed и Native. На рис. 8 показана архитектура Xamarin.

Рис. 7. Архитектура приложения на Qt

Рис. 8. Архитектура приложения на Xamarin

Производительность кода на C# сопоставима с производительностью нативного кода в iOS/Android, но при взаимодействии с ОС используется мост, который может замедлять приложение при неэффективном использовании.

Приложение на Xamarin.iOS / Xamarin.Android обычно состоит из shared (общей) части, которая упаковывается в .NET-библиотеку (dll) и платформенной части, которая имеет полный доступ к API, включая на-тивный пользовательский интерфейс. В платформенной части содержатся описание экранов, ресурсы, стили, шрифты - практически 100% структура нативного проекта на Objective C или Java, или на C#.

Заключение

В работе были рассмотрены особенности кроссплатформенных фреймворков с точки зрения архитектуры. Сами по себе кроссплат-форменные приложения сопоставимы с натив-ными, однако необходимость использования моста снижает скорость при взаимодействии с системными API.

При выборе фреймворка стоит учитывать не только язык программирования, но и необходимый уровень знаний целевых операционных систем (iOS, Android, Windows), а также опираться на опыт команды разработчиков. Например, при использовании PhoneGap можно обойтись без глубоких знаний особенностей различных ОС. А для Xamarin Classic придется стать экспертом в iOS и/или Android.

Общие рекомендации по выбору инструмента разработки кроссплатформенных приложений:

- PhoneGap - если необходимо быстро сделать простое приложение или прототип и в команде есть опыт разработки одностраничных веб-приложений (HTML, JavaScript, CSS). В большинстве случаев можно найти готовые сторонние компоненты для нативной функциональности. Из минусов - неродной пользовательский интерфейс с частыми «подергивания-

ми и залипаниями», а также непростой доступ к нативной части. Процент разделяемого кода -до 95%;

- ReactNative - подойдет для опытных JavaScript-разработчков и команд, но потребует достаточно хорошего знания iOS Objective C API и Android Java API. Приложения выглядят и работают нативно. Процент разделяемого кода - до 90%;

- Xamarin Classic - для опытных C#-разработчиков, которым потребуется глубоко освоить iOS и Android. Приложения будут полностью нативными, но написаны на C#. Объем общей базы кода в редких случаях превышает 40%;

- Qt - этот фреймворк можно рекомендовать только в случае, если уже есть существующее приложение (например, для встраиваемых систем) и его необходимо запустить на iOS/Android. Высокие требования к квалификации разработчиков, непростой доступ к натив-ной функциональности и неродной UI являются заметными минусами фреймворка. Процент разделяемого кода может доходить до 95%.

Литература

1. Tavakkoli Alireza. Game Development and Simulation with Unreal Technology. Boca Raton: CRC Press. 2016. 427 p.

2. Shekar Siddharth. Cocos2d Cross-Platform Game Development Cookbook. Packt Publishing Ltd. 2014. 266 p.

3. Скит Джон. C# для профессионалов: тонкости программирования; пер. с англ. Ю. Н. Артеменко. Изд. 3-е. М.: Вильямс, 2014. 608 с.

4. Hocking Joseph. Unity in Action. Multiplatform game development in C# with Unity 5. Manning, 2015. 352 p.

5. Торн Алан. Искусство создания сценариев в unity; пер. с англ. Р. Н. Рагимова. М.: ДМК-Пресс, 2016. 360 с.

6. Интеграционные решения при построении корпоративных информационных систем / В.В. Сафронов и др. // Известия Самарского научного центра РАН. 2016. Т. 18. № 4(3). С. 646-654.

7. Модульное построение распределённой информационной системы машиностроительного предприятия /

B.В. Сафронов и др. // Вестник Воронежского государственного технического университета. 2015. Т. 11. № 4.

C. 44-50.

Поступила 25.06.2018; принята к публикации 15.09.2018 Информация об авторах

Черников Вячеслав Николаевич - соискатель, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: slava.chernikoff@live.com

Подвальный Семен Леонидович - д-р техн. наук, профессор, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: spodvalny@yandex.ru

Барабанов Владимир Федорович - д-р техн. наук, профессор, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: bvf@list.ru

Сафронов Виталий Владимирович - канд. техн. наук, зав. лабораторией, Воронежский государственный технический университет (394026, Россия, г. Воронеж, Московский проспект, 14), e-mail: safronov.vitaliy@mail.ru

COMPARATIVE ANALYSIS OF ARCHITECTURES OF CROSS-PLATFORM SOFTWARE V.N. Chernikov, S.L. Podvalny, V.F. Barabanov, V.V. Safronov Voronezh State Technical University, Voronezh, Russia

Abstract: the article describes the architecture, that is the most common in the practice of toolkits and libraries for cross-platform development. An overview of the mechanisms of operating systems that use selected tools is given. Comparison of cross-platform tools in terms of architecture is done. The mechanisms of integration of cross-platform and platform-independent parts of the software product are considered, and the "bottlenecks" of these mechanisms are indicated. The recommendations are given, which allow to determine the choice of cross-platform tools in different teams of engineers. This class of software is considered as mobile applications. Smartphones and pads are gaining popularity, displacing treeware and stationary computers, giving business units the opportunity to use new channels and ways to exchange information with customers and employees. The article compares the most popular tools: PhoneGap, ReactNative, Xamarin and Qt. The target platforms are iOS, Android and Windows UWP operating systems. A detailed analysis of cross-platform software architectures in part: a substantiation of the use of cross-platform development tools; architecture and interfaces for the integration of operating systems (iOS, Android, Windows UWP); architecture of cross-platform applications (PhoneGap, ReactNative, Qt, Xamarin). General recommendations on the choice of the tool for developing cross-platform applications have been formed

Key words: cross-platform development, mobile applications, architecture of computer systems

References

1. Tavakkoli Alireza "Game Development and Simulation with Unreal Technology", CRC Press, Boca Raton, 2016, 427 p.

2. Shakar S. "Cocos2d cross-platform game development cookbook", Packt Publishing Ltd, 2014, 266 p.

3. Skeet J. "C# for professionals: the subtleties of programming", trans. from English by Artemenko Yu.N., Moscow, Williams, 2014, 608 p.

4. Hocking J. "Unity in action. Multiplatform game development inC# with Unity 5", Manning, 2015, 352 p.

5. Thorne A. "The Art of scripting in Unity", trans. from English by Ragimov R.N., Moscow, DMK-Press, 360 p.

6. Safronov V.V. et al. "Integration solutions in the construction of corporate information systems", Proceedings of the Samara scientific center of RAS (Izvestiya Samarskogo nauchnogo tsentra RAN), 2016, vol. 18, no. 4 (3), pp. 646-654.

7. Safronov V.V. et al. "Modular building systems engineering distributed information companies", The Bulletin of Voronezh State Technical University (Vestnik Voronezhskogo gosudarstvennogo tekhnicheskogo universiteta), 2015, vol. 11, no. 4, pp. 44-50.

Submitted 25.06.2018; revised 15.09.2018

Information about the authors

Vyacheslav N. Chernikov, Seeker, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), email: slava.chernikoff@live.com

Semyen L. Podvalny, Dr. Sc. (Technical), Professor, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: spodvalny@yandex.ru

Vladimir F. Barabanov, Dr. Sc. (Technical), Professor, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: bvf@list.ru

Vitaliy V. Safronov, Cand. Sc. (Technical), Laboratory Manager, Voronezh State Technical University (14 Moskovskiy prospekt, Voronezh 394026, Russia), e-mail: safronov.vitaliy@mail.ru