Лекция № 3

Тема: Кроссплатформенность. Архитектуры кроссплатформенных фрэймворков.

Количество часов: 2
Цель: Разобрать понятие кроссплатформенности. Ознакомиться с кроссплатформенными
фрэймворками и их архитектурой.
План:
1. Введение.
2. Кроссплатформенная технология.
2.1 Преимущества и недостатки кроссплатформенной среды.
2.2 Области применения кроссплатформенной среды.
3. Архитектура кроссплатформенных фрэймворков
3.1. PhoneGap
3.2. ReactNative
3.3. Flutter
3.4. Xamarin
3.5. Xamarin.Forms
Текст лекции
1. Введение.

Создание качественных сервисов выгодно для всех участников рынка. Пользователи

получают инструменты для решения повседневных задач. Разработчики получают
прибыль за счет:
1. Продажи рекламных блоков.
2. Платных дополнительных функций (в бесплатной программе).
3. Платного распространения программ.
4. Создание контента на заказ.
Сумма заработка зависит от востребованности контента. Чтобы программа стала
популярной, она должна быть удобной и полезной. Важен красивый дизайн, выбирая,
какие разновидности мобильных приложений загрузить, пользователи обращают
внимание на логотип.
Когда в роли заказчика выступает бизнесмен, он получает выгоду от запуска сервиса:
расширение целевой аудитории, обратную связь от клиентов, увеличение прямых продаж,
рост узнаваемости бренда.
2.Кроссплатформенная технология
 Каждая среда разработки содержит целый комплекс утилит для написания кода,
проектирования интерфейса, отладки, профилирования (мониторинга) и сборки
приложений. И среда, и соответствующий набор утилит созданы специально под каждую
мобильную операционную систему, и являются максимально удобными и мощными
средствами разработки мобильных приложений.
Кроссплатформенная технология разработки мобильного приложения подразумевает
использование специальных фреймворков для создания приложения на основе семейства
языков JavaScript. Вся структура и логика приложения создается с помощью таких
инструментов (React Native, Flutter, Ionic, Xamarin, PhoneGap и др.) на JavaScript, а затем
оборачивается в нативный запускающий элемент, т.е. интегрируется в базовый проект для
XCode или Android Studio. Это позволяет создавать сборки проекта с одной и той же
логикой под несколько операционных систем сразу.
Простая аналогия просматривается в случае с персональными компьютерами: MS
Word, Skype, почтовые агенты, календари – это нативно разработанные приложения под
настольную операционную систему. Всё, что происходит в браузере (сайты, онлайн-
редакторы текста и графики, социальные сети, чаты, форумы) – кроссплатформенные
технологии.

2.1 Преимущества и недостатки кроссплатформенной среды.

Кроссплатформенная среда разработки имеет следующие положительные моменты:

Требуется меньше ресурсов для реализации приложения сразу под несколько платформ. В
этом, собственно, и суть кроссплатформенной технологии разработки мобильных
приложений на платформе андроид и iOS – на обеих платформах работает один и тот же
код. Программистов, занимающихся проектом, нужно ровно в два раза меньше. Дизайнер
делает только один набор графики. Все это снижает количество рабочих часов и бюджет
проекта.
Меньшее время на разработку. За счет отсутствия уникальных элементов
интерфейса и более простых технологий разработки кроссплатформенных приложений,
время на создание простых продуктов, как правило, меньше.
Упрощенный цикл обновления продукта. Если в проект нужно что-то добавить или
исправить какую-то ошибку, это делается сразу для всех платформ, на которые
распространяется проект.
Возможность использования мобильной версии сайта. В большинстве случаев
языки для кроссплатформенной технологии разработки мобильных приложений входят в
семейство языков JavaScript. Поэтому если у вас уже есть мобильная версия сайта,
значительная часть кода и материалов может быть использована в приложении без
изменений.
Использование единой логики приложения. Логика, заложенная в работу
приложения, будет работать гарантированно одинаково для всех платформ. Довольно
часто это может являться и минусом из-за разной архитектуры операционных систем.
Яркий пример – кнопка “Назад” в навигации между экранами. В Android
предусмотрена аппаратная кнопка Back для этих целей. У iOS – движение пальцем от
левой части экрана или же наличие кнопки в левой части навигационной панели. Если
кнопку не делать вовсе, пользователи iOS не смогут вернуться назад. Если сделать, но не
на том месте и выглядящую нестандартно, пользователям iOS будет непривычно и
неудобно; а если сделать как в iOS, будет непривычно пользователям Android.
Однако написанная и отлаженная один раз логика содержит потенциально меньшее
количество ошибок и расхождений в своей работе. Поэтому вам не придется проделывать
двойную и тройную работу по поиску проблем на каждой платформе.

2.2 Области применения кроссплатформенных технологий.

Современные игры пишутся в подавляющем большинстве на кроссплатформенных

технологиях. Это сильно ускоряет разработку без ущерба для качества, т.к. в этом случае
используются специальные графические фреймворки (самый популярный – Unity 3D).
Если какой-то проект нужно сделать быстро для проведения каких-либо тестов,
при этом ситуация требует работы проекта именно на нескольких платформах
одновременно, кроссплатформенная реализация может быть оптимальным решением.

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

3.1. PhoneGap

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

простыми с  точки зрения реализации  – создается небольшое нативное приложение,
которое фактически просто отображает встроенный веб-браузер и single-page HTML. Нет
никаких нативных контролов и  прямого доступа к API – все интерфейсные элементы
внутри веб-страницы просто стилизуются под родные. Для доступа к системной
функциональности подключаются специальные плагины, которые добавляют JS-методы
внутрь веб-браузера и связывают их с нативной реализацией на каждой платформе.
 Как видим, PhoneGap позволяет разделять практически весь код между
платформами, однако все еще требуется реализация нативной части на Objective C и Java
(и C# для Windows). Вся жизнь приложения проходит внутри WebView, поэтому веб-
разработчики почувствуют себя как рыба в воде. До тех пор пока не возникнет
потребность в платформенной функциональности – здесь уже будет необходимо хорошее
понимание iOS и Android. Также PhoneGap (он же Apache Cordova) используется
в популярном фреймворке Ionic, который предоставляет большое количество готовых
плагинов для системной функциональности.

3.2. ReactNative

Одним из интересных решений в области кроссплатформенной разработки

мобильных приложений является ReactNative, созданный в  Facebook. Этот фреймворк
дает возможность использовать JavaScript для описания нативного интерфейса и логики
работы приложений. Сам по себе JS-движок обеспечивает производительность,
сопоставимую с нативной. Однако не стоит забывать, что и в архитектуре ReactNative
присутствует мост, снижающий скорость работы с платформенной функциональностью
и UI
 При создании приложений на ReactNative разработчику будет необходимо также
реализовывать нативную часть на Objective C, Java или C#, которая инициализирует JS-
движок и  свой JS-код. Далее JS-приложение берет управление в свои руки и при помощи
ReactNative начинает создавать нативные объекты и управлять ими из JavaScript. Стоит
добавить, что архитектура ReactNative позволяет осуществлять обновление JS-кода без
перезапуска приложения (hot reloading). Это допускает обновление кроссплатформенной
части без необходимости перепубликации приложений в  AppStore и  Google Play. Также
можно использовать библиотеки из Npm и большое количество сторонних плагинов.
Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код
JavaScript на лету интерпретируется, а не компилируется. В  целом это не сильно
сказывается на производительности в реальных приложениях, но помнить об этом стоит.
При создании приложений на ReactNative требуется опыт JavaScript, а также
хорошие знания iOS и Android. Интеграцию нативной и кроссплатформенной частей легко
сделать по официальной документации. Пользовательский интерфейс является полностью
нативным, но имеет ограничения и особенности при стилизации из JS-кода, к которым
придется привыкнуть. Для передачи данных через мост их необходимо
сериализовать/десериализовать в Json. Плюс мост используется для управления
нативными объектами, что также может вести к падению производительности при
неэффективном использовании (например, часто менять свойства нативных UI-объектов
из JS-кода при анимациях в ручном режиме). Также следует учитывать юность
фреймворка  – имеются узкие места или ошибки, о которых узнаешь только во время
разработки. И практически всегда требуется реализация нативной части на Objective C
и Java.
3.3. Flutter

Данный фреймворк был впервые представлен корпорацией Google только в  2015

году, однако быстро получил популярность со стороны разработчиков за свою простоту и 
высокую производительность. С точки зрения архитектуры Flutter похож на Qt – ядро
этого фреймворка реализовано на C++, и пользовательский интерфейс создается
с помощью собственного движка, не являясь нативным. Однако (в отличие от Qt) во
Flutter реализованы простые механизмы интеграции с  функциональностью операционной
системы, не требуя большого количества оберток. Так как нужные элементы
пользовательского интерфейса рисуются на экране самим Flutter, то на нативном уровне
приложение состоит из одного экрана, показывающего отрисованную движком Flutter
картинку, и, как результат, имеет очень высокую производительность (до 120 кадров в 
секунду). Также сам Flutter берет на себя взаимодействие с пользователем и отлавливает
жесты, касания и другие события. Важно отметить, что приложение для Flutter
необходимо разрабатывать на языке Dart, который очень похож на другие современные C-
подобные языки, однако получил популярность только среди Flutter-разработчиков. Для
отрисовки пользовательского интерфейса в iOS/Android Flutter использует
высокопроизводительный графический движок Skia, работающий поверх OpenGL или
других низкоуровневых механизмов, задействующих возможности графических
процессоров. С одной стороны, это позволяет получить очень отзывчивый
пользовательский интерфейс, с другой – интерфейс может казаться ненативным
и потребовать заметной доработки для реальных приложений. Flutter в качестве моста для
интеграции с операционной системой использует так называемые каналы платформы
(Platform Channels), которые позволяют передавать и обрабатывать сообщения между
Dartкодом и нативной частью. Фактически это общая шина данных, через которую
отправляются сообщения. При этом стоит помнить, что, как и  любой мост, каналы
платформы также преобразуют данные, что может привести к  потерям
производительности при неумелом использовании.

Одним из плюсов Flutter является его легкая портируемость на новые платформы  –

уже сейчас заявлена поддержка iOS, Android, Windows, macOS, Linux и Web-приложений.
По аналогии с ReactNative во Flutter реализованы механизмы автоматического обновления
(hot reload) пользовательского интерфейса на этапе разработки – вы вносите изменения
в код и сразу видите конечных результат без необходимости запуска приложения на
эмуляторе/смартфоне. Также приложения на Flutter компилируются в машинный код
(AOTкомпиляция), что также положительно сказывается на производительности.
В целом Flutter является простым и  удобным инструментом для создания
мобильных приложений. Одновременно минусом и  плюсом можно назвать
использование языка Dart: современен, удобен и прост, но требует обучения и популярен
только для Flutter. Ну и плюс юность фреймворка – простые приложения делаются
быстро, но шаг влево-вправо – и можно наткнуться на баг или отсутствие готового
компонента.
3.4. Xamarin

Xamarin сейчас доступен в open source и появился в качестве развития проекта

Mono (http://www.mono-project.com), открытой реализации инфраструктуры .NET для
Unix-систем. Изначально Mono поддерживался компанией Novell и  позволял
запускать .NET-приложения в Linux и других открытых ОС. Для взаимодействия
с родными (для C) интерфейсами операционных систем в Mono используется механизм
P/Invoke (http://www.mono-project.com/docs/advanced/pinvoke/). На основе Mono были
созданы фреймворки MonoTouch и MonoDroid, которые затем переименовали
в Xamarin.iOS и Xamarin.Android и теперь вместе называют «классическим Xamarin»
(Xamarin Classic).

Классический Xamarin предоставляет полный доступ к нативным API, то есть

можно создавать нативные приложения iOS/Android с помощью C# без единой строчки на
Objective C и Java. Нативные библиотеки подключаются через механизм байндинга
(Native Library Binding).Взаимодействие с ОС происходит через мост и механизм оберток
(wrappers), однако нет необходимости сериализовать данные, так как осуществляется
автоматический маршалинг и есть возможность прямой передачи ссылок между средами
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 и компилирует код во время исполнения. Как
видим, общая база кода между платформами ограничивается бизнес-логикой
и механизмами работы с данными. К сожалению, UI и платформенную функциональность
приходится реализовывать отдельно для каждой платформы. В результате шарить можно
не более 30–40 % от общей базы кода мобильных приложений. Для достижения большего
результата необходимо использовать Xamarin.Forms.
Ключевым преимуществом классического Xamarin является использование языка
C# для всей базы кода, включая UI-тесты, и, как следствие, разработчиков, которые уже
хорошо знакомы с .NET. Также обязательным является хорошее знание и понимание
механизмов iOS/Android, их классовых моделей, архитектур, жизненных циклов объектов
и умение читать примеры на Objective C и Java. Приложение на
Xamarin.iOS/Xamarin.Android обычно состоит из shared (общей) части, которая
упаковывается в  .NET-библиотеку, и платформенной части, которая имеет полный доступ
к API, включая нативный пользовательский интерфейс. В платформенной части
содержится описание экранов, ресурсы, стили, шрифты – практически 100%-ная
структура нативного проекта на Objective C или Java, только на C#.
Классический Xamarin является достаточно зрелым решением и обеспечивает
максимально близкий к нативному опыт разработки для C#-программистов
и использованием привычных инструментов вроде Visual Studio.

3.5. Xamarin.Forms

Если у вас стоит цель максимизировать общую базу кода, то классический Xamarin
здесь явно проигрывает всем остальным фреймворкам (PhoneGap, ReactNative, Flutter, Qt
и их аналогам). Это понимали и  в  самом Xamarin, поэтому выпустили решение,
позволяющее использовать единое описание UI и простые механизмы доступа
к платформенным фичам, – Xamarin.Forms. Библиотека Xamarin.Forms работает поверх
описанного ранее классического Xamarin и фактически предоставляет механизмы
виртуализации пользовательского интерфейса и  дополнительную инфраструктуру.
Xamarin.Forms (XF) решает своего рода задачу «последней мили», предоставляя единый
API для работы с пользовательским интерфейсом в  разных операционных системах (iOS,
Android, Windows UWP/ WPF, Linux Gtk#, Mac OS X, Tizen). При этом сам интерфейс
остается полностью родным.
Для того чтобы лучше понять, как работает XF, давайте рассмотрим простую
кнопку. Одним из базовых механизмов являются рендереры (renderers), благодаря
которым при отображении кнопки Xamarin. Forms фактически на экран добавляется
нативный контрол, а свойства XF-кнопки динамически пробрасываются в свойства
нативной кнопки на каждой платформе. В ReactNative используются похожие механизмы.

Общая (shared) часть на Xamarin.Forms обычно реализуется в виде библиотеки

(Portable/PCL или .NET Standard) и  имеет доступ к  базе компонентов в NuGet.
Платформенная часть реализуется на базе Xamarin Classic и имеет полный доступ к API,
а также возможность подключения сторонних библиотек. При этом общий процент кода
между платформами обычно доходит до 85. Также Xamarin.Forms можно использовать
в режиме Embedded для создания отдельных экранов и View внутри приложений на
классическом Xamarin.iOS и Xamarin.Android.
Если вам будем достаточно уже доступных в Xamarin.Forms компонентов
и плагинов, то не потребуется глубоких знаний в iOS/Android/ Windows. В сообществе
и NuGet также доступно большое количество готовых плагинов и примеров.
Несмотря на то что классический Xamarin является зрелым и стабильным
решением, Xamarin.Forms еще достаточно молодая и активно развивающаяся над ним
надстройка, поэтому могут проявляться проблемы и узкие места, с которыми стоит быть
внимательным.
Контрольные вопросы и задания:
1. Что такое кроссплатформенная технология разработки мобильного приложения ?
2. В чем преимущества кроссплатформенных технологий ?
3. В каких случаях применяется кроссплатформенная разработка?
4. Перечислить основные кроссплатформенные фреймворки.

Список литературы и ссылки на Интернет-ресурсы, содержащие информацию по

теме:
1. Вязовик Н.А. Программирование на Java [Электронный ресурс]: учебное
пособие для СПО/ Вязовик Н.А.— Электрон. текстовые данные.— Саратов:
Профобразование, 2017.— 604 c.— Режим доступа: http://www.iprbookshop.ru/86206.html.
— ЭБС «IPRbooks»
2. Парамонов, И. В. Разработка мобильных приложений для платформы
Android[Электронный ресурс]: учебное пособие. / И. В. Парамонов; Яросл. гос. ун-т им. П.
Г.Демидова.—Ярославль:ЯрГУ,2013Режим доступа:
http://www.lib.uniyar.ac.ru/edocs/iuni/20130403.pdf , свободный

3. Start Android - учебник по android для начинающих и продвинутых

Электронный ресурс. Электронный адрес https://startandroid.ru/ru/

4.UmbrellaIT – разработка мобильных и веб-приложений. Электронный ресурс.

Электронный адрес https://umbrellait.com/ru/