кроссплатформенные фреймворки для мобильных приложений
Обзор кросс-платформенных фреймворков мобильной разработки
По работе мне неоднократно приходилось сталкиваться с выбором подходящей технологии для мобильной разработки. Ниже я попробовал собрать и классифицировать основные фреймворки по используемым подходам, достоинствам и недостаткам.
Если какая-то моя информация некорректна, или устарела — комментарии приветствуются.
Общие минусы кросс-платформенной разработки
Ограниченная поддержка платформы
Любой кросс-платформенный фреймворк — это слой абстракции над нативной платформой и позволяет обращаться только к тем её возможностям, которые прямо поддерживаются фреймворком.
В большинстве случаев есть возможность расширить поддержку возможностей платформы путём написания нативных плагинов к фреймворку, но в некоторых случаях это может существенно усложнить разработку. Свежий пример из нашумевшей статьи AirBnb — React Native, который в данный момент не умеет “из коробки” работать с 64-битными Android-библиотеками.
Также нужно обратить внимание, что нативные плагины и основной код кросс-платформенного приложения, как правило, исполняются в разных процессах и взаимодействие между ними может вызывать проблемы с производительностью. Для работы с датчиками, или SQLite это, обычно, не проблема, но если вы используете, скажем, библиотеку OpenCV в качестве нативного плагина и начинаете кидать видео между ней и основным приложением, замедление может быть существенным.
Ограниченное предложение на рынке труда
Во-первых, само наличие разработчиков зависит от распространённости фреймворка. Найти людей под React Native может быть даже легче, чем нативных разработчиков, а, например, с Flutter намного сложнее.
Насколько нужно учитывать этот фактор — зависит от задач. Большинство стартапов могут не обращать на него внимания, поскольку изучение новой технологии является скорее бонусом для действующих и потенциальных сотрудников. С другой стороны, крупный бизнес вынужден учитывать рынок труда.
Риски поддержки
Считается, что вероятность того, что поддержка кросс-платформенного фремворка закончится — намного выше, чем вероятность того же события в отношении мобильной ОС.
На самом деле вопрос довольно сложный. ОС могут закрываться так же, как фреймворки (пример Windows Phone совсем свеж). Кроме того, внутри нативной разработки могут отдельные технологии также могут закрываться и иногда код на кросс-платформенных фреймворках обладает большей живучестью.
Пример этого есть в области игр и мультимедиа — Apple собирается отправить на покой технологию OpenGL в своих ОС и всем, кто писал нативные 3D-приложения придётся их полностью переписывать для выпуска новых версий. В то же время для тех, кто пользовался кросс-платформенными игровыми движками (например Unity), обновление не потребует никаких дополнительных усилий.
Основные направления
Гибридная разработка, HTML+JavaScript
Технически, приложения гибридного типа представляют собой HTML-страницу, отображаемую во встроенном браузере. В целом для этого подхода фреймворк не обязателен, но Cordova обеспечивает набор плагинов для доступа к возможностям платформы, из-за чего как правило используют её.
Основные плюсы
Минимальная стоимость разработки
Гибридный подход позволяет переиспользовать не только навыки разработчиков, но и код, написанный для веб-сайтов.
Возможность интеграции веб-элементов
Количество библиотек для HTML/JS заметно превосходит количество таковых для нативных приложений. Из интересного, сюда относятся, например, Google Analytics, или богатый выбор рекламных сетей.
Основные минусы
Невысокая производительность
Сам по себе современный JavaScript использует JIT-компиляцию, хорошо оптимизирован и работает быстро, но построение интерфейса на основе DOM-дерева — не очень эффективный процесс. Использование современных JS-фреймворков даёт дополнительный уровень нагрузки. Для слабых телефонов и/или при активном использовании интерактивных элементов, это может быть проблемой.
“Ненативное ощущение”
Это довольно неформальный, но очень важный пункт. Сайт в браузере реагирует на жесты и отображается немного не так, как мобильное приложение. Наиболее заметный элемент этого ощущения, задержку 300ms при нажатиях, Cordova решает, но многие другие детали остаются.
Проблема браузерной совместимости
На старых версиях Android (до версии 5), WebView был частью платформы и не обновлялся автоматически. Соответственно, использовать современные возможности браузеров в гибридных приложениях на этих устройствах не получится.
Как следствие, гибридные приложения либо ограничивают минимальную версию Android (оставляя за бортом около 13% устройств на данный момент), либо включают WebView в код приложения (проект CrossWalk), увеличивая размер приложения на несколько десятков мегабайт.
Предназначение
Быстрое создание одноразовых приложений. При наличии существенного бюджета на разработку, гибридным подходом, как правило, брезгуют.
Основные фреймворки
Основой всех основных гибридных фреймворков является Cordova, предоставляющая доступ к нативным плагинам. PhoneGap предоставляет инструментарий для сборки поверх Cordova, в то время как Ionic представляет собой фреймворк и набор компонентов для построения в ней пользовательских интерфейсов.
Нативный UI, общий код
Важно отметить, что при таком подходе, пользовательский интерфейс и бизнес-логика выполняются в разных процессах, взаимодействующих через мост (“bridge”). С этим связан ряд минусов подхода.
У этого подхода есть несколько вариантов реализации.
Классификация по работе исполняемого кода
Компилируемый код
Xamarin использует язык C#, компилируя его в нативный код платформы. В целом, такой подход обеспечивает достаточно небольшой размер приложения и достаточно высокую скорость работы.
Интерпретируемый язык с JIT-компиляцией
Большинство фреймворков этого подхода используют JavaScript для обработки бизнес-логики.
Классификация по способу описания интерфейса
Нативные инструменты
Xamarin не только использует нативные компоненты интерфейса, но и описывает их в формате, принятом для каждой платформы.
Универсальные элементы интерфейса
Xamarin Forms и Appcelerator используют собственный набор виджетов, который преобразуется в подходящие компоненты интерфейса каждой платформы.
Разный интерфейс для разных платформ, но общий подход
React Native использует обёртки вокруг нативных компонентов интерфейса. Соответственно, интерфейс описывается для каждой платформы отдельно, но способ описания един.
Основные плюсы
Полностью нативный интерфейс
Во-первых, внешний вид и “ощущение” от приложения полностью совпадают с нативными приложениями.
Во-вторых, это позволяет использовать в приложениях библиотеки нативных интерфейсов. Использовать нативную рекламу (Native Ads), ориентированную на мобильные приложения, в других подходах не получится. Правда и для этого подхода набор соответствующих библиотек очень ограничен. Я знаю только о поддержке Facebook Native Ads в React Native.
Возможность переиспользования квалификации разработчиков
Основные минусы
Ограничение возможностей интерфейса, или дополнительные затраты на раздельную разработку
Формат этого минуса зависит от классификации фреймворка по способу описания интерфейса:
Xamarin позволяет использовать почти все возможности платформ, но приходится тратить много времени на интерфейсы для каждой платформы. В итоге трудозатраты становятся ненамного меньше, чем при нативной разработке.
Xamarin Forms и Appcelerator позволяют описывать интерфейсы только один раз, но работают с сильно ограниченным подмножеством нативной функциональности (не больше, чем минимальное пересечение множеств возможностей каждой платформы, если быть формальным).
React Native находится посредине, совмещая оба недостатка, но в менее выраженной форме.
Производительность взаимодействия с интерфейсом
Здесь вступает в игру фактор исполнения интерфейсов и бизнес-логики в разных процессах. Когда нужно обмениваться через мост большими объёмами информации с высокой скоростью (сложная анимация с высокой частотой), в данном подходе могут возникать сложности.
Утечки памяти
Утечки памяти могут возникать в любом приложении, но с большинством стандартных ситуаций отлично справляются сборщики мусора.
Проблема кросс-платформенных приложений с нативным интерфейсом опять в том, что они выполняются в двух процессах, имеющих раздельные сборщики мусора. Если объект бизнес-логики ссылается на объект интерфейса, этот объект интерфейса не является мусором, т.к. на него есть ссылка из моста. Если объект интерфейса ссылается обратно на объект бизнес-логики, они не будут считаться мусором даже если больше никаких ссылок на них не будет.
Шансы встретить проблему и её масштаб напрямую зависят от приложения. Если в нём активно создаются и удаляются объекты, связанные с интерфейсом (как в бесконечном скроллинге) вероятность утечки вырастает. Если эти объекты большие (например изображения), вырастает влияние утечки.
Собственно, эта проблема присутствует и при работе с нативными плагинами, которые тоже выполняются в отдельном процессе. Но там, в большинстве случаев, либо нет такого интенсивного манипулирования большими объектами, либо взаимодействие идёт в строго процедурном подходе, без перекрёстных ссылок.
Предназначение
Приложения с полностью нативным интерфейсом, особенно при наличии специалистов в смежных технологиях.
Основные фреймворки
React Native
Имеет поддержку Facebook и использует подход самого популярного JS-фреймворка React, за счёт чего очень популярен. Недавняя статья об отказе AirBnb от React Native наделала много шума, но если осознавать риски, может быть очень эффективным решением.
Xamarin
Помимо основного подхода имеет библиотеку Xamarin.Forms, которая позволяет эффективно и кроссплатформенно проектировать простые интерфейсы. Активно поддерживается Microsoft. При работе с ASP.NET на сервере позволяет дополнительно съэкономить определённый объём работы за счёт использования общих классов бизнес-логики на сервере и в мобильном приложении.
NativeScript
Сделан по образцу React Native для разработчиков, владеющих другими JS-фреймворками (Angular и Vue.js). Менее популярен, но имеет ряд более современных решений в архитектуре.
Собственный UI, общий код
Этим подходом пользуются почти все игровые движки, но они находятся за рамками данной статьи.
Принцип данного подхода — приложение использует собственный код и собственную отрисовку пользовательского интерфейса.
Основные плюсы
Высокая производительность интерфейсов
По сути, приложение, самостоятельно рисующее свой интерфейс, выполняет те же операции, что ОС в нативном интерфейсе. В теории оно может быть даже быстрее, т.к. нет переключения между процессом и ядром, но на практике другие факторы влияют на скорость отрисовки конкретного интерфейса, играют намного большую роль.
“Дизайнерские интерфейсы”
Нативные приложения пользуются готовыми компонентами интерфейса и имеют некоторые ограничения в том, что с ними можно сделать. В свою очередь, приложения, сами рисующие свой интерфейс, не имеют таких ограничений и могут свободно смешивать готовые элементы с индивидуальной отрисовкой.
Основные минусы
Данные минусы актуальны только для приложений, имитирующих стандартный интерфейс ОС. Как уже говорилось, для дизайнерских интерфейсов и игр данный подход является оптимальным.
Размер приложения
Приложения с таким подходом вынуждены нести с собой код для отрисовки всех элементов интерфейса, включая условно стандартные. Это сказывается как на размере приложения при установке, так и на оперативной памяти при работе.
Если первую проблему можно минимизировать эффективным Tree Shaking (как это делают последние версии Flutter), то по оперативной памяти эти приложения стабильно проигрывают нативным. Впрочем, эта проблема характерна и для других кросс-платформенных фреймворков.
Ненативный интерфейс
По умолчанию, приложение выглядит одинаково на всех платформах, что может создавать дискомфорт для пользователей. Для решения этих проблем используются темы, но создать ощущение полностью нативного приложения они не могут.
Но есть и более крупный минус — с таким подходом сложнее всего использовать сторонние элементы интерфейса, созданные для нативных приложений (включая упомянутые ранее Native Ads).
Предназначение
Приложения общего пользования, особенно с дизайнерским интерфейсом.
Основные фреймворки
Flutter
Flutter продвигается компанией Google как основной фреймворк кросс-платформенной разработки и основа интерфейса их будущей ОС Fuscia. Пока фреймворк очень молод (в стадии Release Preview) и не очень распространён, но быстро набирает популярность. Использует язык Dart (с компиляцией в нативный код).
Имеет все плюсы и минусы молодости — продуманную архитектуру с учётом ошибок предшественников, но достаточно ограниченную экосистему.
QT Mobile
Пользуется популярностью у разработчиков десктопного QT. При разработке может использоваться JavaScript. Без поддержки крупных компаний не пользуется особой популярностью.
Ещё один не очень популярный фреймворк, который интересен, в первую очередь тем, что это единственный фреймворк в списке, который использует язык Python. Для разработчиков, знакомых только с этим языком (а таких много в некоторых областях информационных технологий), это может иметь решающее значение.
Лучшие фреймворки для кроссплатформенной разработки
Разработчики во всем мире выбирают платформы для кроссплатформенной разработки приложений из-за тех преимуществ, которые она предлагает. Сегодня существует огромное множество фреймворков, которые позволяют разработчикам использовать один и тот же повторяющийся код для создания приложений, предназначенных для различных платформ. Если вы хотите выбрать лучший фреймворк для кроссплатформенной разработки приложений для вашего проекта, вы находитесь там, где надо. В этой статье мы рассмотрим ведущие фреймворки, которые есть на данный момент и которые позволят вам достичь ваших целей разработки.
Прежде чем мы рассмотрим основные варианты, давайте подробно остановимся на том, что такое кроссплатформенная разработка и какие у нее преимущества.
Что такое кроссплатформенный фреймворк?
Фреймворки, это специальные программы, состоящие из набора инструментов и библиотек, которые помогают разработчикам создавать приложения намного быстрее и эффективнее. Однако многие из этих фреймворков предназначены для разработки приложений для конкретных платформ, таких как Android или iOS.
Кроссплатформенные фреймворки привносят дополнительную ценность в разработку приложений, предоставляя инструменты для создания приложений сразу для нескольких платформ. С помощью таких фреймворков разработчик может создать единый код для запуска Web-приложений, операционных систем iOS и Android. Таким образом, многие разработчики выбирают именно кроссплатформенные фреймворки, потому что они открывают новые возможности в разработке приложений.
Преимущества кроссплатформенных фреймворков
Ниже приведены некоторые преимущества кроссплатформенных фреймворков
Лучшие Кроссплатформенные Фреймворки
Список лидирующих кроссплатформенных фреймворков на момент написания статьи перечислены ниже.
React Native
React Native это, наверное, самая популярная среда разработки кроссплатформенных приложений на JavaScript. Разработчики могут использовать ее для создания кода и запуска WEB-приложений, приложений для операционных систем IOS и Android.
С момента своего выхода в качестве фреймворка с открытым исходным кодом в 2015 году React Native получил широкое распространение среди разработчиков и стал одной из ведущих платформ для разработки кросс-платформенных приложений.
Преимущества React Native
Flutter
Google, владелец поисковой системы, создал Flutter и выпустил его в качестве фреймворка с открытым исходным кодом для разработки мобильных приложений. Он предлагает инструменты и функции для создания приложений для операционных систем iOS и Android.
На момент написания статьи разработчики могли использовать только язык программирования Dart на платформе Flutter. Flutter состоит из наборов инструментов элементов пользовательского интерфейса, SDK и фреймворков.
Cordova
Adobe приобрела Cordova, платформу разработки приложений у компании Nitobi, в 2011 году. Платформа позволяет разработчикам создавать гибридные приложения для операционных систем iOS и Android с использованием CSS, HTML и JavaScript. Приложения Cordova не являются полностью WEBили нативными, но они используют API для доступа к нативным функциям. Таким образом, приложения Cordova сочетают гибридные элементы с нативными функциями.
Ionic
На протяжении последних лет, Ionic претерпела значительные изменения от AngularJS для фронтенда до Apache Cordova. Теперь он состоит из WEB-компонентов, предоставляющих варианты выбора фреймворка для разработки VU.js, Angular, или React. Недавно было выпущено обновление, которое позволяет разработчикам использовать функции ionic без добавления пользовательского интерфейса.
Xamarin
В то время как большинство кроссплатформенных фреймворков используют JavaScript, CSSи HTML, фреймворк Xamarin использует C# для создания кроссплатформенных приложений. Благодаря среде разработки Xamarin, все одинаково работает на операционных системах Windows, iOS и Android. Код C# Xamarin может получить доступ к нативным функциям iOS и Android. Именно поэтому приложения Xamarin смотрятся и ощущаются как нативные мобильные приложения.
Заключение
Разработчики получают огромную пользу из использования кроссплатформенных фреймворков. Большое множество вариантов, которые есть на рынке, затрудняют выбор правильной структуры. Поэтому в этой статье мы рассмотрели лучшие кроссплатформенные фреймворки на текущий момент. Это поможет новичкам и опытным разработчикам выбрать лучший кроссплатформенный фреймворк для своего проекта.
Часто Задаваемые Вопросы
Что такое Фреймворк?
Фреймворки состоят из инструментов, которые позволяют создавать качественные приложения намного быстрее и эффективнее. Большинство фреймворков поддерживают разработку для одной платформы, в то время как кроссплатформенные фреймворки поддерживают создание приложений сразу для нескольких платформ.
Зачем использовать кроссплатформенный фреймворк?
– Позволяет создавать гибридные приложения
– Упрощает управление кодом
– Ускоряет разработку приложений
– Экономит средства
Какие самые лучшие кроссплатформенные фреймворки?
— React Native
— Ionic
— Cordova
— Xamarin
— Flutter
Выбор лучшего фреймворка для создания мобильного приложения
Для создания мобильных приложений есть множество фреймворков. Но выбрать нужно лишь один.
Совсем недавно каждый разработчик занимался разработкой мобильных приложений, используя Software Development Kit (SDK), предоставляемый конкретной мобильной платформой. Например, SDK Android имеет для разработки приложений все необходимые API Java. В свою очередь, SDK iOS предлагает API Swift/Objective C. Таким образом, две популярные мобильные платформы имеют совершенно разные SDK. Сложившаяся ситуация создала проблему для коммерческого развития процессов разработки мобильных приложений. Компании должны были поддерживать базы исходного кода для каждой мобильной платформы. Как правило, им приходилось иметь две группы разработчиков.
Решением эт о й проблемы стали фреймворки для кроссплатформенной разработки мобильных приложений. Все они пытаются ввести уровень абстракции над специфичными для каждой платформы API. Некоторые фреймворки использовали для абстракции webview (веб-просмотр). Другие включали собственные графические библиотеки. Сегодня есть несколько вариантов для тех, кто планирует создать кроссплатформенное мобильное приложение. Выбору фреймворка нужно уделить особое внимание, потому что от него будет зависеть успех вашего проекта.
Внимательно изучив все популярные фреймворки я выделил их примечательные особенности.
Ionic
Ionic изначально был создан на основе проекта Cordova и позволяет создавать гибридные кроссплатформенные приложения с использованием веб-технологий. Внутренняя архитектура Ionic несколько напоминает проект Electron. Вся структура графического интерфейса приложения отображается внутри веб-страницы. Ionic предлагает набор плагинов для обработки встроенных операций, таких как фотографирование и запись файла.
Ionic отлично подходит для небольших мобильных приложений с быстрой загрузкой. Если у компании уже есть фронтенд-разработчики, тогда для создания мобильного приложения на Ionic не нужны дополнительные специалисты. Ionic подходит для создания мобильных приложений с небольшим бюджетом и постоянными запросами. Однако он плохо работает в крупномасштабных приложениях, потому что базируется на веб-просмотре.
React Native
React Native позволяет разработчикам создавать кроссплатформенные приложения с встроенными элементами графического интерфейса мобильной операционной системы. Он обрабатывает встроенные функции, очень похожие на Ionic, но не использует веб-просмотр. Все встроенные операции выполняются через движок JavaScript, который взаимодействует с собственными плагинами. Самое важное то, что мы можем разработать интерфейс в стиле React с помощью React Native FlexBox.
React Native отлично подходит для концептуального приложения с множественным динамическим контентом. Например, это может быть приложение с лентой новостей, где пользователи могут ставить лайки и оставлять комментарии. Он отлично подходит для мобильных приложений среднего размера с бюджетом на разработку выше среднего. React Native может стать разумным выбором для приложений со сложным пользовательским интерфейсом. Но этот фреймворк окажется не лучшим выбором для приложения, которое выполняет много нативных функций, потому что такие операции обрабатываются через мост JavaScript.
Flutter
Flutter стал альтернативой от Google на проект React Native. Он включает графическую библиотеку для отрисовки встроенных элементов графического интерфейса. Flutter поставляется с собственным набором инструментов для интерфейсных элементов. Следовательно, все созданное с помощью этого инструментария будет выглядеть одинаково в любой операционной системе. Но Flutter также виджеты в стиле Android/iOS. Существуют API библиотеки Dart для нативных операций.
Flutter является хорошим выбором для тех, кто хочет иметь одинаковый визуальный интерфейс в разных операционных системах. Стоимость разработки такого мобильного приложения может оказаться более высокой из-за того, что у Flutter еще не совсем устоявшаяся инфраструктура. В процессе работы над проектами по разработке приложений на Flutter может появиться необходимость в оплате услуг еще и разработчиков Dart. Flutter — хороший выбор для больших мобильных приложений. Он также отлично подходит для мобильных приложений у которых достаточно много встроенных функций, потому что встроенные операции Flutter никогда не взаимодействуют через мост JavaScript. Например, Flutter взаимодействует с API Android с помощью класса Java ByteBuffer.
Xamarin
Xamarin является хорошим инструментом для компаний, где работают со средой на основе C#. Но следует отметить, определенную ограниченность Xamarin.Forms. Поэтому Xamarin будет разумным выбором в том случае, если у компании есть большой проект на основе C# и желание создать мобильное приложение с минимальными затратами. А если бизнес полностью основан на будущем мобильном приложении, тогда лучше отказаться от Xamarin.
Убираем фреймворки
Ни один фреймворк не является оптимальным выбором. Обычно устранение посредников благоприятно сказывается на житейских проблемах. Точно так же, используя лишь SDK операционной системы, у вас будет больше свободы в действиях. Если есть новый нативный API, а вы используете фреймворк, то придется ждать до тех пор, пока кто-нибудь не создаст общедоступный плагин. А без фреймворка вы сможете непосредственно применять самый последний SDK с недавно выпущенной функцией. Кроме того, плагины могут содержать скрытые ошибки и снижать производительность, поэтому после выявления подобных проблем, обычно приходится ждать, пока специалисты по сопровождению устранят выявленную ошибку.
Если позволяет бюджет проекта, а концептуальное приложение имеет множество встроенных функций, лучше всего подойдет нативный системный SDK. Для простого мобильного приложения возможной альтернативой этому подходу без фреймворка может стать Xamarin. Следовательно, можно будет использовать один язык программирования для доступа к API и Android, и iOS. Кроме того, при использовании общего независимого от платформы кода можно улучшить управляемость исходной программы.
Заключение
Как отмечено выше, при выборе фреймворка необходимо учитывать ряд факторов. Общими факторами для принятия решения являются масштаб проекта, количество встроенных функций, сложность пользовательского интерфейса, выделенный бюджет и время реализации проекта. Кроме того, следует подумать о поддержке сетевого сообщества. Например, у Flutter и Dart поддержка сообщества лучше, чем у Xamarin. Фактически, преимущества работы без фреймворков в настоящее время недостаточно оценены. Неправильный выбор фреймворка зачастую является для разработчика причиной проблем с производительностью приложения, поэтому уделяйте серьезное внимание выбору фреймворка.