Продолжаем анализ архитектуры мобильных кроссплатформенных инструментов.
Сегодня на повестке дня фреймворки Xamarin и Qt. Напомним, что в первая часть Мы рассмотрели общие архитектурные шаблоны кроссплатформенных фреймворков, а также архитектуры PhoneGap и ReactNative. 
Эта статья представляет собой сокращенную версию руководства, доступного по ссылке в конце.Предоставляю слово Вячеславу Черникову.
Qt
Qt — одна из старейших кроссплатформенных платформ, широко используемая для разработки встроенных и настольных приложений.Архитектура Qt позволяет портировать его на те операционные системы, которые имеют API для C++.
Такая возможность есть и у iOS, и у Android (NDK), и у Windows, хотя все они имеют свои особенности.
Одним из основных преимуществ Qt является собственная эффективная система рендеринга пользовательского интерфейса, основанная либо на растровом движке (например, CoreGraphics в iOS), либо на основе Open GL (ES).
Это то, что делает фреймворк портативным.
То есть Qt использует собственные механизмы рендеринга пользовательского интерфейса — приложение будет выглядеть нативным настолько, насколько вы его стилизуете сами.
Как видите, iOS использует стандартные модули CoreGraphics и UIKit для рендеринга пользовательского интерфейса.
В Android ситуация немного сложнее, поскольку для рендеринга пользовательского интерфейса Qt использует механизмы NDK, а для доступа к Java API и управления приложением используется уже знакомый мост JNI. Кроме того, iOS и Android могут использовать Open GL ES для рендеринга QML или работы с 3D. В Windows есть прямой доступ к C++ API и все бы работало нормально, если бы не необходимость использовать преобразование вызовов Open GL ES в вызовы DirectX (отрисовка растровых изображений неудовлетворительна с точки зрения производительности, а Open GL ES недоступно в Windows UWP).
В этом помогает библиотека ANGLE.
Интерфейс приложений на базе Qt не является нативным, а лишь делается похожим на него с помощью стилизации.В целом Qt можно было бы рекомендовать как вещь в себе — только готовые модули самого фреймворка плюс платформонезависимые библиотеки на C++.
Но в реальных проектах использовать будет очень сложно - неродной UI, никаких сторонних компонентов (только готовые библиотеки), сложности возникают при сборке и отладке приложения, а также при доступе к нативному функционалу.
.
Одним из преимуществ является высокая производительность кода C++.
Итак, Qt можно рекомендовать для разработки приложений для iOS, Android и Windows UWP только в том случае, если у вас уже есть большой опыт работы с Qt и понимание сложных системных механизмов.
Стоит учитывать, что интерфейс в любом случае может быть только похож на родной.
Ксамарин
Xamarin теперь доступен с открытым исходным кодом и создан на основе проекта Mono — реализации платформы .NET с открытым исходным кодом для систем Unix. Первоначально Mono поддерживалось Novell и позволяло запускать приложения .
NET в Linux и других открытых операционных системах.
Для взаимодействия с собственными (C) интерфейсами операционных систем Mono использует механизм П/вызов .
На основе Mono были созданы фреймворки MonoTouch и MonoDroid, которые затем были переименованы в Xamarin.iOS и Xamarin.Android и теперь вместе называются «классическим Xamarin» (Xamarin Classic).
Классический Xamarin предоставляет полный доступ к собственным API-интерфейсам.
Это означает, что вы можете создавать собственные приложения для iOS/Android с помощью C#, не написав ни единой строки Objective C и Java. Нативные библиотеки подключаются через механизм привязки нативных библиотек.
Взаимодействие с ОС происходит через мост и механизм-обертку, но нет необходимости сериализовать данные, поскольку осуществляется автоматический маршалинг и есть возможность напрямую передавать ссылки между Mono Managed и Native средами.
Вы также можете использовать большое количество .
NET-библиотек из NuGet. 
Платформа .
NET/Mono использует JIT, аналогично Java, где приложение упаковывается в промежуточный байт-код, а затем компилируется во время выполнения.
Но из-за ограничений iOS невозможно использовать JIT, поэтому байт-код приложений Xamarin.iOS компилируется в собственный двоичный файл и статически связывается вместе с библиотеками.
Эта компиляция называется AOT (Ahead Of Time) и требуется в Xamarin.iOS. В Xamarin.Android помимо AOT доступен также режим JIT, когда виртуальная среда Mono работает параллельно с Dalvik/ART. Как видите, общая база кода между платформами ограничена бизнес-логикой и механизмами обработки данных.
К сожалению, функциональность пользовательского интерфейса и платформы приходится реализовывать отдельно для каждой платформы.
В результате вы сможете перешарить не более 30%-40% всей кодовой базы мобильных приложений.
Для достижения более высоких результатов вам необходимо использовать Xamarin.Forms, о котором мы поговорим в главе 3.5. Ключевое преимущество классического Xamarin — использование языка C# для всего кода и, как следствие, разработчиков, уже знакомых с .
NET. Также требуется хорошее знание и понимание механизмов iOS/Android, их моделей классов, архитектур, жизненных циклов объектов, а также умение читать примеры на Objective C и Java.
Производительность кода C# сравнима с производительностью нативного кода в iOS/Android, но при взаимодействии с ОС используется мост, который при неэффективном использовании может замедлить работу приложения.Классический Xamarin — достаточно зрелое решение, предоставляющее программистам C# максимально близкие возможности разработки с использованием знакомых инструментов, таких как Visual Studio. Итак, если стоит задача реализовать полностью нативное приложение и при этом есть опытные C#-разработчики, то Xamarin может стать хорошим выбором для широкого круга задач, как больших (более 40 экранов), так и небольших (до 10 экранов).
Xamarin.Forms
Если ваша цель — максимизировать общую кодовую базу, то классический Xamarin явно уступает всем остальным фреймворкам (PhoneGap, ReactNative, Qt и их аналогам).В самой Xamarin это поняли, поэтому выпустили решение, позволяющее использовать единое описание пользовательского интерфейса и простые механизмы доступа к функциям платформы — Xamarin.Forms. Библиотека Xamarin.Forms работает поверх классического Xamarin, описанного ранее, и фактически предоставляет механизмы виртуализации пользовательского интерфейса и дополнительную инфраструктуру.
Чтобы лучше понять, как работает XF, давайте посмотрим на простую кнопку.
Одним из базовых механизмов являются рендереры, благодаря которым при отображении кнопки Xamarin.Forms на экран фактически добавляется собственный элемент управления, а свойства кнопки XF динамически передаются в свойства собственной кнопки на каждом Платформа.
ReactNative использует аналогичные механизмы.
Общая часть Xamarin.Forms обычно реализуется как библиотека (Portable/PCL или .
NET Standard) и имеет доступ к базе данных компонентов в NuGet. Платформенная часть реализована на базе Xamarin Classic и имеет полный доступ к нативному API, а также возможность подключения сторонних библиотек.
При этом общий процент кода между платформами обычно достигает 85%.
Xamarin.Forms также можно использовать во встроенном режиме для создания отдельных экранов и представлений в приложениях на классических Xamarin.iOS и Xamarin.Android. Итак, Xamarin.Forms можно рекомендовать для быстрого прототипирования на C#, но Xamarin.Forms также можно использовать для корпоративных и бизнес-приложений любого масштаба (80 и более экранов).
Внешний вид, производительность и поведение приложений будут полностью нативными, но не стоит забывать об эффективном взаимодействии с операционной системой через мост.
Заключение
В нашей статье мы рассмотрели особенности популярных мобильных фреймворков с архитектурной точки зрения.Кроссплатформенные приложения сами по себе очень быстрые и сравнимы с нативными, но необходимость использования моста немного снижает скорость при взаимодействии с нативными API.
Общий вывод : все популярные кроссплатформенные фреймворки используют мост, что снижает скорость взаимодействия с нативной частью.При выборе фреймворка следует учитывать не только язык программирования, но и необходимый уровень знаний целевых операционных систем (iOS, Android, Windows), а также опираться на опыт вашей команды разработчиков.Узкие места (специфичные для каждой платформы) должны быть оптимизированы при создании пользовательского интерфейса.
Окончательный выбор фреймворка будет зависеть от компетенций, имеющихся в команде, и требований к конечному результату.
Например, при использовании PhoneGap можно обойтись поверхностными знаниями ОС, если вам не нужно вручную реализовывать функционал платформы.
А для Xamarin Classic вам придется стать экспертом в iOS и/или Android. В итоге соберем все рекомендации по выбору фреймворков в одном месте:
- PhoneGap — если вам нужно быстро сделать простое приложение или прототип и у команды есть опыт разработки одностраничных веб-приложений (HTML, JavaScript, CSS).
В большинстве случаев можно обойтись готовыми плагинами для нативной функциональности.
Из минусов - неродной интерфейс с частыми подергиваниями и залипаниями и затрудненный доступ к родной части.
Процент общего кода — до 95%.
- ReactNative - Отлично подходит для опытных разработчиков и команд JavaScript, но потребует достаточно хороших знаний iOS Objective C API и Android Java API. Приложения выглядят и работают нативно, но стоит учитывать и молодость фреймворка.
Процент общего кода — до 90%.
- Хамарин Классик — если у вас есть опытные C#-разработчики, то им потребуется глубоко освоить iOS и Android. Приложения будут полностью нативными, хотя и написанными на C#.
Размер общей кодовой базы редко превышает 40%.
- Xamarin.Forms - подходит для опытных разработчиков C#, особенно со знанием XAML. Приложения с простым интерфейсом (стандартные элементы управления или готовые компоненты) не требуют глубоких знаний iOS/Android/Windows. Процент общего кода — до 90%.
- Qt — этот фреймворк можно рекомендовать только в том случае, если у вас уже есть существующее приложение (например, встроенное) и вам необходимо запустить его на iOS/Android. Высокие требования к квалификации разработчика, затрудненный доступ к нативному функционалу и ненативный UI — заметные недостатки фреймворка.
Процент общего кода может достигать 95%.
P.s. Выражаю благодарность Роману Здебскому и Ахмеду Шериеву за ценные дополнения, а также Елизавете Швец и Марии Горелкиной за помощь в публикации.
Полное руководство можно найти по адресу GitBook .31 октября Вячеслав также выступит на нашем вебинаре Mobile DevOps для разработчиков Xamarin, ускоряющий тестирование и доставку .
Участие, как всегда, бесплатное.
Напоминаем, что во второй части обзора мы более подробно остановимся на Xamarin и Qt, а также общих рекомендациях по выбору фреймворка.
Оставайтесь на связи и задавайте свои вопросы в комментариях!
об авторе
Вячеслав Черников – руководитель отдела развития компании Бинвелл , Microsoft MVP и сертифицированный разработчик Xamarin. Ранее был чемпионом Nokia и сертифицированным специалистом по Qt, в настоящее время специалист по платформам Xamarin и Azure. Он пришел в мобильную сферу в 2005 году и занимается разработкой мобильных приложений с 2008 года: начинал с Symbian, Maemo, Meego, Windows Mobile, затем перешел на iOS, Android и Windows Phone. Вы также можете прочитать статьи Вячеслава в блог на Medium .
Другие статьи автора вы можете найти в нашей рубрике #xamarincolumn .
Оставайтесь на связи и задавайте свои вопросы в комментариях! Теги: #разработка для iOS #разработка для Android #microsoft #разработка мобильных приложений #кроссплатформенная разработка #Qt #xamarin #phonegap #ReactNative ##xamarincolumn
-
Сравнение Сайтов Потокового Видео
19 Oct, 24 -
Абсолютный Нуль
19 Oct, 24
