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

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

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

Оригинал данной статьи на английском:Shalitha Suranga: Choosing the Best Framework for Your Next Mobile App

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

Совсем недавно каждый разработчик занимался разработкой мобильных приложений, используя 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 включает среду выполнения Mono в собственные приложения, созданные с ее помощью. Таким образом, есть возможность использования совместно с Xamarin библиотек .NET. Имеются сопряжения C# для SDK нативной операционной системы. Кроме того, предусмотрены некоторые общие платформенно-ориентированные нативные API. Надстройка Xamarin.Forms предлагает независимый от платформы подход к созданию собственных интерфейсов.

Xamarin является хорошим инструментом для компаний, где работают со средой на основе C#. Но следует отметить, определенную ограниченность Xamarin.Forms. Поэтому Xamarin будет разумным выбором в том случае, если у компании есть большой проект на основе C# и желание создать мобильное приложение с минимальными затратами. А если бизнес полностью основан на будущем мобильном приложении, тогда лучше отказаться от Xamarin.

Убираем фреймворки

Ни один фреймворк не является оптимальным выбором. Обычно устранение посредников благоприятно сказывается на житейских проблемах. Точно так же, используя лишь SDK операционной системы, у вас будет больше свободы в действиях. Если есть новый нативный API, а вы используете фреймворк, то придется ждать до тех пор, пока кто-нибудь не создаст общедоступный плагин. А без фреймворка вы сможете непосредственно применять самый последний SDK с недавно выпущенной функцией. Кроме того, плагины могут содержать скрытые ошибки и снижать производительность, поэтому после выявления подобных проблем, обычно приходится ждать, пока специалисты по сопровождению устранят выявленную ошибку.

Если позволяет бюджет проекта, а концептуальное приложение имеет множество встроенных функций, лучше всего подойдет нативный системный SDK. Для простого мобильного приложения возможной альтернативой этому подходу без фреймворка может стать Xamarin. Следовательно, можно будет использовать один язык программирования для доступа к API и Android, и iOS. Кроме того, при использовании общего независимого от платформы кода можно улучшить управляемость исходной программы.

Заключение

Как отмечено выше, при выборе фреймворка необходимо учитывать ряд факторов. Общими факторами для принятия решения являются масштаб проекта, количество встроенных функций, сложность пользовательского интерфейса, выделенный бюджет и время реализации проекта. Кроме того, следует подумать о поддержке сетевого сообщества. Например, у Flutter и Dart поддержка сообщества лучше, чем у Xamarin. Фактически, преимущества работы без фреймворков в настоящее время недостаточно оценены. Неправильный выбор фреймворка зачастую является для разработчика причиной проблем с производительностью приложения, поэтому уделяйте серьезное внимание выбору фреймворка.

11
11 комментариев

Не очень понятна ценность статьи. Фреймворки есть по первой ссылке Гугла, нет ни сравнений ни плюсов/минусов, вывод вообще непонятен, почему для простого приложения подойдёт именно xamarin непонятно. Какая то вода волна получилась, извините(

5
Ответить

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

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

Также увеличивается нагрузка на ЦП, время загрузки приложения, отзывчивость интерфейса. Закономерно на разных устройствах часто проявляются разные артефакты отрисовки.

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

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

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

3
Ответить

А какой подход верный для максимально дешевого и быстрого результата? Мне кажется, что проще делать целиком webview. На любом фреймворке, либо вообще просто собрать PWA.

То есть на самом дешевом языке, на php том же создаем веб-сайт и делаем на фреймворке или PWA webview. Верно?

И почему тогда не все так делают? Или уже начинают потихоньку переходить на webview?

Ответить

Бред

1
Ответить