Кроссплатформенная разработка для android

На чём писать мобильные кроссплатформенные приложения

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

В прошлый раз мы касались кроссплатформенной разработки мобильных приложений больше двух лет назад и с тех пор многое изменилось. Настала пора поговорить о методах и инструментах снова.

Давайте для начала пройдемся ещё раз по терминологии.

Родные

Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то и Swift для iOS или Java или Kotlin для Android, такое приложение будет называться нативным (от англ. native — родной, естественный).

Преимущества нативных приложений:

• скорость работы и отклика интерфейса. Приложение реагирует на нажатия мгновенно, практически отсутствуют задержки в анимации, скроллировании, получении и выводе данных;
• понятный и простой доступ к функциям и датчикам устройства. Для разработчика не представляет проблемы работа с геолокацией, , съёмкой фото и видео через камеру, звуком, акселерометром и другими датчиками;
• возможность углублённой работы с функциями смартфона. Как и в предыдущем пункте, такие вещи, как анимации, создание сложных интерфейсов и работа нейросетей прямо на устройствах реализуются, может быть, и не просто, но прогнозируемо;
• родной для платформы интерфейс. Нативные приложения обычно оперируют «платформенными» элементами интерфейса: меню, навигация, формы и все остальные элементы дизайна берутся от операционной системы и потому привычны и понятны пользователю.

Недостаток один — дороговизна разработки и поддержки, в том числе потому, что для каждой платформы надо писать свой код.

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

И не родные

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

Первый заключается в том, что на этапе подготовки приложения к публикации он превращается в нативный для определённой платформы с помощью транспилера. Фактически один кроссплатформенный язык программирования «переводится» на другой.

Второй — в том, что к получившемуся коду добавляется определённая обёртка, которая, работая уже на устройстве, на лету транслирует вызовы из неродного кода к родным функциям системы.

Предполагается, что большая часть такого кода может переносится между платформами — очевидно, что, например, логика совершения покупок, сохранения товара в корзину, просчёта маршрута для такси, написания сообщения в мессенджер не меняется в зависимости о того, Android у клиента или iOS. Нужно лишь доработать UI и UX для платформ, но сейчас, в определённых пределах, даже это можно объединить — например, активно используется как на Android, так и на iOS. Так что даже внесений исправления в интерфейс для того, чтобы приложение отвечало духу и букве нужной платформы — вопрос желания, необходимой скорости и качества разработки.

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

• неродной интерфейс или, как минимум, необходимость работы с интерфейсом каждой платформы отдельно. У каждой системы свои требования к дизайну элементов и иногда они взаимоисключающи. При разработке это необходимо учитывать;
• проблемы в реализации сложных функций или возможные проблемы работы даже с простыми процедурами в силу ошибок самих фреймворков разработки. Кроссплатформенная среда лишь транслирует запросы к системным вызовам и интерфейсам в понимаемый ею, системой, формат, и потому на этом этапе возможны как сложности с пониманием, так и возникновение ошибок внутри самого фреймворка;
• скорость работы. Так как кроссплатформенная среда является «надстройкой» над кодом (не всегда, но в определённых ситуациях), в ней возникают свои задержки и паузы в отработке действий пользователя и выводе на экран результатов. Это было особенно заметно несколько лет назад на смартфонах, более маломощных относительно сегодняшних, однако сейчас, с ростом производительности мобильных устройств, этим уже можно пренебречь.

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

Популярные платформы и инструменты кроссплатформенной мобильной разработки

Как мы написали выше, есть два подхода — превращение кода в нативный на этапе сборки или добавление определённой обёртки, транслирующей вызовы к системе и от неё.

Cordova и PWA — два инструмента, работающие как раз в идеологии обёртки.

Cordova и HTML5

Одно из самых популярных направлений в кроссплатформенном программировании, которое часто называют PhoneGap. Фактически создаётся мобильный сайт, который «оборачивается» небольшим платформенным кодом, транслирующим вызовы от системы к приложению и обратно.

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

Для такого подхода создано огромное количество фреймворков, но все они делают фактически одно и тоже. Различие между ними в том, что Cordova (PhoneGap) не задаёт ограничений и шаблонов на логику и UI для вашего , а фреймворки оперируют собственными готовыми , имитирующими мобильные платформы, и своей логикой разработки. В качестве примера такого подхода можно указать: Ionic Framework — обёртка; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI — интерфейсные фреймворки.

Хотите научиться самостоятельно делать кроссплатформенные приложения на основе веб-технологий? Обратите внимание на обучающие курсы «Профессия Frontend-разработчик» и «Веб-разработчик с нуля до PRO» от онлайн-университета Skillbox.

Модная технология от Google — это те же самые , но за счёт использования определённых технологий (в первую очередь это так называемые Service Worker — работающие в фоновом режиме скрипты, и Web App Manifest — описание в понятном для мобильной системы виде) они без обёртки из PhoneGap могут работать как нативные. Они могут устанавливаться на домашний экран в обход магазина приложений, работать в офлайне, работать с , с нативными функциями.

Проблема в том, что не все платформы даже сейчас поддерживают эти «определённые технологии». В первую очередь это касается Apple, которой, видимо, очень не нравится возможность распространять приложения в обход App Store.

Учтя все недостатки , многие компании создали инструменты, которые позволяют писать код на одном, не нативном, языке, а он потом транслируется в нативный. Так убивается два зайца одновременно: кодовая база получается одна, а приложения получаются максимально близки к нативному.

Xamarin

Платформа компании Microsoft. Используется стандартный для язык программирования С#, кроссплатформенная среда разработки — Visual Studio. На выходе — нативные приложения для iOS, Android и Windows. Правда, относительно большого размера.

React Native

Платформа от Facebook — приложения пишутся на JavaScript и с использованием стилей. Интерфейс получается родной, а код интерпретируется уже на платформе, что придаёт ему нужную гибкость.

Будучи относительно молодой платформой, React Native пока очевидно (хоть и не катастрофически) страдает от недостатка средств разработки и документации.

Flutter

Естественно, не мог обойти тему кроссплатформенной разработки Android и iOS-приложеий и такой гигант, как Google. Flutter, пока, правда, существующий только в , исповедует отличный от React Native и Xamarin подход. Он не превращает исходный код в нативный, который выполняется платформой, а на самом деле рисует окно на экране смартфона и отрисовывает все элементы сам. В качестве языка используется «фирменный» Dart, который Google создал как усовершенствованную версию JavaScript.

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

Платформа быстро развивается и Google вкладывает в это много сил и средств. Но по сравнению с Flutter даже React Native кажется вполне устоявшейся и впечатляющей экосистемой.

Хотите научиться самостоятельно создавать кроссплатформенные приложения на Flutter? Вам сюда.

Что выбрать

У вас уже наверняка пошла голова кругом, а понимания что выбрать, так и не появилось. Давайте представим простой список вопросов, который вам поможет:

• должно хоть работать на любом устройстве? Выбирайте HTML как основу;
• у вас достаточно средств, нет спешки и вы хотите самое качественное приложение? Вам прямой путь в нативную разработку;
• у вас есть «встроенный» или вы просто хотите быстро и просто попробовать мобильное приложение в деле? Тут можно рекомендовать Cordova/HTML или PWA;
• у вас есть собственная и поддерживающий ее C#-разработчик? Берите Xamarin;
• вы «хотите попробовать», но надо сделать всё красиво и модно? Смотрите в сторону React Native или Flutter.

Можно зайти и с другой стороны. Посмотрите на функциональность, которая вам потребуется в приложении, и исходите из этого:

• простое ? Возьмите React Native или HTML5 и вы получите две платформы за минимальную цену;
• у вас есть сайт с большой посещаемостью и вам нужно протестировать гипотезу присутствия в мобильном пространстве? HTML5;
• сложные приложения с доступом к нужным функциям устройств? Нативная разработка, Xamarin, React Native.

Кроссплатформенная разработка — не панацея

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

У вас остались сомнения и вопросы о кроссплатформенных приложениях? Почитайте о том, как мы создавали приложение ClassBoom для быстрого получения абонемента в одно из спортивных заведений города и попробуйте приложение ВсеПлатежи для оплаты всевозможных видов услуг — от ЖКХ до заказов в . А лучше запишитесь на бесплатную консультацию, заполнив форму с указанием примерного бюджета и кратким описанием идеи или свяжитесь с нашим менеджером Катей по телефону .

Источник

Варианты кроссплатформенной разработки мобильных приложений

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

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

Давайте посмотрим, какие варианты кроссплатформенной разработки существуют и что они предлагают нам как создателям. Бизнес постучит со своими «хотелками», а выбор того, на чем писать, часто приходится делать именно разработчику.

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

Проблема архитектуры в кроссплатформах

В мире кроссплатформы все фреймворки примерно одинаковы по своей структуре. В основе всего — целевая платформа (iOS, Android, etc.), для которой ведется разработка, и слой абстракции, который обещают сделать быстро, дешево и красиво, а между ними мост, соединяющий эти две сущности. Слой абстракции в большинстве своем представлен связкой из JS и CSS (частично или полностью).

У такой архитектуры есть типичные проблемы.

Частично они обусловлены тем, что слой абстракции, условно говоря, пытается усидеть на двух стульях — с переменным успехом. Отсюда и сложности: на каждой отдельно взятой платформе приложение отображается и ведет себя по-разному. Иногда это не проблема, но бывают случаи, когда уникальный дизайн и поведение на обеих платформах являются дополнительным business value.

В пример можно привести приложение Reflectly. Изначально оно было написано на React Native, впервые вышло на iOS, а позже была попытка выйти на платформу Android.

Запуск приложения в Android преподнес неприятный сюрприз. В итоге его полностью переписали на Flutter.

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

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

Работоспособность и поддержка плагинов. Кроссплатформа не так распространена, как классический фронтенд. Нередко плагин выпускается в Open Source, и практически сразу прекращается его поддержка, так как существующая версия решает проблемы разработчика, а за большее никто не будет платить. Еще хуже, когда прекращается не только поддержка, но и реагирование на pull requests…

Миф о том, что любого web-разработчика можно быстро переквалифицировать в мобильщика с помощью «магического фреймворка Х». Все выглядит похоже: на Web — CSS + JS, на кроссплатформе — то же самое. Должно работать. Но не учитывается факт, что к имеющимся знаниям требуется быстро прибавить понимание как минимум двух платформ (iOS и Android), с которыми разработчик раньше не сталкивался. Отдельным бонусом идет набивка руки в специфических тонкостях, связанных со взаимодействиями внутри всего этого зоопарка.

Из-за всех этих нюансов кроссплатформенную разработку троллят вот так:

Начнем знакомство с фреймворков, основанных на WebView.

Cordova

Одним из первых кроссплатформенных фреймворков стал Cordova (бывш. PhoneGap). Первый релиз состоялся в 2009 году. Изначально разрабатывался компанией Nitobi, купленной Adobe. В результате поглощения исходный код PhoneGap был передан Apache Foundation.

Из официальной архитектурной схемы видно, что основой рендеринга выступает обычный WebView — то есть обычный браузер. Несмотря на то что это самый давний фреймворк, предлагает он лишь джентльменский набор из плагинов и связки API для обеспечения их взаимодействия. Какого-то специфического набора инструментов у него нет. Есть перечень сервисов и библиотек, который предлагается на главной странице, например Onsen UI — UI-библиотека.

Developer experience довольно неоднозначный: фактически, как ты его себе организуешь, так и будет. Можно на jQuery все писать и обновлять страницу с F5, а можно собрать себе уютный и привычный набор библиотек и пользоваться уже существующими решениями для hot reload.

Дебаг происходит в консоли браузера. Дебаг на устройстве — через подключение из Safari к WebView, запущенном на iOS.

Также есть удобный механизм темплейтов, который позволяет генерить проект из готовых сторонних бойлерплейтов. Например, cordova-template-framework7-vue-webpack.

Ionic

На основе Cordova в 2013 году был выпущен Ionic. Со временем Cordova заменили Capacitor с сохранением совместимости API, чтобы осталась работоспособной вся существующая база компонентов.

Имеет свою базу UI-компонентов и позволяет реализовывать бизнес-логику на любом фреймворке из могучей тройки (до версии 4 была возможность использовать только Angular). Есть возможность оплатить энтерпрайз-поддержку. В остальном все сказанное о Cordova относится и к Ionic. Дебаг в консоли браузера, хот-релоад от фреймворка, работает внутри WebView.

Следующими рассмотрим фреймворки semi-native, которые предлагают писать на смеси CSS + JS (React Native, NativeScript, Appcelerator) или .NET (Xamarin), а на выходе получать приложение, практически не отличимое от нативного.

Appcelerator наименее известен (0 упоминаний в вакансиях на DOU), использует свой собственный фреймворк Alloy. Существует также версия с поддержкой Angular, но она все еще в бете, а движение в репозитории остановилось в 2108 году… Знать о нем можно, а изучать практического смысла нет 🙂

Xamarin

Фреймворк с длинной историей. Изначально развивался отдельно, позже был приобретен компанией «Майкрософт». Поскольку он «не на JS», то не очень популярен.

В отличие от JS-фреймворков код на C# компилируется, и это позволяет ему работать чуть быстрее. Также у него есть два варианта архитектуры.

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

Продолжение развития Xamarin, но уже с покрытием UI, не требующим написания по отдельности.

Доступны наборы инструментов для разработки на любой вкус. Есть бесплатная Visual Studio Community Edition и платная версия Visual Studio Professional по подписке за 45 $ в месяц.

Дебагер, хот-релоад (только для верстки), лейаут-эдитор — все имеется в наличии. Однако язык разработки и относительная дороговизна инструментов разработки делает Xamarin малораспространенным за пределами экосистемы Microsoft.

NativeScript

Фреймворк выпущен в 2014 году. На данный момент из коробки предлагается писать на Angular или Vue. За долгие годы развития накопил достаточно большой арсенал инструментов разработчика: готовый набор UI-компонентов, собственную песочницу, маркетплейс компонентов, приложение для быстрого запуска превью написанного кода на устройстве, приложение, где можно увидеть вживую работу компонентов. Для дебага можно использовать или консоль браузера, или предоставляемый разработчиками плагин для VS Code.

Имеет интересную архитектуру — API платформы через рефлексию пробрасываются на сторону JavaScript.

На практике работа с API-платформы выглядит так, как будто вы пишете, например, на Java, только через призму JS. В повседневной же работе используется набор встроенных layout-компонентов и CSS-подобный синтаксис для раскраски. При изменении стилей достаточно неплохо работает hot reload.

На выходе имеем бандл JS-кода, выполненный в JSCore (iOS) или V8 (Android) и работающий через мост с платформой.

React Native

Первый релиз состоялся в 2015 году. Практически единственный из кроссплатформенных фреймворков JS, который не дает нам выбора и предлагает только React как фреймворк для разработки. Его появление подтверждает, что React можно скормить любой движок для рендеринга виртуального дома дерева. Первая имплементация этого подхода была результатом хакатона и в итоге продолжила свое развитие в Open Source. На данный момент очень популярен не в последнюю очередь благодаря «Реакту» для Web.

Общая архитектура очень похожа на NativeScript, только мост на 100 метров выше по реке. Нативные плагины пишутся на стороне платформы, а через мост передаются лишь параметры. В промежутке между JS и платформой находится Yoga — кроссплатформенный движок, который реализует flex-box layout на целевой платформе.

Технически React Native очень похож на то, что frontend-разработчики привыкли видеть на Web.

Фреймворк активно развивается: релизы появляются каждые 3–6 месяцев. В версии 0.61.0 обновили механизм hot reload, который позволяет работать более производительно. Не так давно была выпущена версия 0.62.0, которая добавила интеграцию fbflipper из коробки. Надеюсь, эта инициатива получит достойное продолжение, так как до сих пор арсенал инструментов разработчика был похож на лоскутное одеяло. Изначально предлагается только консоль браузера, можно использовать также react-native-debugger или reactotron, которые дают дополнительные инструменты при разработке (инспекция Redux, MobX, Apollo Cache).

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

Последними рассмотрим фреймворки native-like. Отличает их то, что они совсем не используют встроенных виджетов. Вместо этого рисуют все своими силами. Одним из новичков в этой категории является Flutter. В процессе подготовки статьи я с удивлением обнаружил, что с 2011 года на Python развивается аналогичный фреймворк, реализующий такую же концепцию, — Kyvi. Увы, но этому фреймворку не хватает финансирования и комьюнити. Например, имплементация Material UI уже 3 года не развивается, а инициатива была перехвачена нашим соотечественником.

Flutter

Первый релиз состоялся в конце 2018 года. Платформа достаточно молодая, но она активно развивается: ежеквартальные релизы, активное развитие языка Dart, богатый инструментарий разработчика, изумительный hot reload, онлайн-редактор для анимации, специализированная CI/CD — все это было доступно с первого дня релиза версии 1.0.

Особенностью архитектуры Flutter является то, что он сам рисует каждый пиксель, контролирует жесты и анимацию. Он не использует ОЕМ-виджеты, как это делает React Native. Вместо этого команда Flutter создала два набора виджетов для основных мобильных платформ: Material для Android и Cupertino для iOS. Таким образом, они заново отрисовали все UI-компоненты с обеих мобильных платформ, полностью повторив их поведение. Непосредственно с мобильной платформой (геолокация, звук, Bluetooth) взаимодействие происходит через Platform Channels.

Благодаря такой архитектуре заявлена поддержка «всего что угодно», в теории. На практике хорошо поддерживаются iOS и Android. Активно развивается Web. Фактически успех на web-поприще определит дальнейшую популярность фреймворка во всем мире. На данный момент есть поддержка Web в бета-версии, и с каждым днем она становится все лучше. Одной из проблем является производительность. С флагом FLUTTER_WEB_USE_SKIA=true производительность существенно возрастает. Более подробный обзор Flutter доступен в моей предыдущей статье.

Относительная «молодость» платформы и широкий перечень поддерживаемых платформ, бывает, преподносит баги в неожиданных местах. Благодаря быстро растущему комьюнити на многие из них есть ишьюс на GitHub, в которых часто можно найти вариант обходного решения проблемы.

С этим фреймворком мне еще не довелось плотно познакомиться. На всякий случай я его установил и запустил. Не без проблем — из-за бага, который благополучно пофиксили в версии 5.14.2. В комментариях отпишитесь, если у вас есть опыт кроссплатформенной мобильной разработки на Qt.

Тренды

Для полноты картины приведу тренды на Stack Overflow:

• React Native — 45.
• Flutter — 19.
• Xamarin — 4.
• Cordova/Ionic — 1.
• NativeScript — 0.

Муки выбора

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

Например, если у вас десктоп-решение на .NET, ваш выбор, скорее всего, падет на Xamarin, что позволит эффективно заново использовать имеющиеся наработки и компетенции.

Если вам нужно простейшее решение, чтобы текущий web-продукт поддержать мобильной платформой, вам подойдут PWA или Ioinc (с дистрибуцией через магазины).

Если вы только за Angular либо за React, а все остальное — «фу-фу-фу», если нет времени или желания разбираться, а нужно приложение на вчера, вы, скорее всего, остановите выбор на NativeScript в первом случае или на React Native во втором.

Стартапам придется выбирать между React Native и Flutter из-за их популярности и поддержки большими компаниями. Первый — это зрелый фреймворк с устоявшимися практиками разработки, богатством библиотек и большим комьюнити. Второй — молодой, быстрый и перспективный с богатым набором встроенных UI-компонентов и крутым developer experience.

Начинающим разработчикам или желающим попробовать что-то новое стоит обратить внимание на Flutter.

Источник