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

Перед началом статьи хочу сказать, что еще больше полезной и нужной информации вы найдете в моём 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. Фактически, преимущества работы без фреймворков в настоящее время недостаточно оценены. Неправильный выбор фреймворка зачастую является для разработчика причиной проблем с производительностью приложения, поэтому уделяйте серьезное внимание выбору фреймворка.

0
11 комментариев
Написать комментарий...
Олег Пчелкин

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

Ответить
Развернуть ветку
Atomic Attack

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

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

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

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

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

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

Ответить
Развернуть ветку
Ware Wow

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

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

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

Ответить
Развернуть ветку
Atomic Attack

Я имел в виду не только веб.
Даже не столько веб.

Ответить
Развернуть ветку
Ware Wow

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

Конструкторы (но там не везде абонентка норм, за год может набежать как за разработку), Либо...

Ответить
Развернуть ветку
Atomic Attack

Смотря что подразумевать под «простым приложением».
Кому то и фейсбук кажется простым сайтом/приложением.

Можно заказать у меня или у коллег.

Ответить
Развернуть ветку
Ware Wow

Ну фейсбук тоже простой, если в глубь не лезть.
Пользовательский интерфейс можно собрать за 200 баксов и завернуть в webview или PWA имхо.

Ответить
Развернуть ветку
Atomic Attack

Я поздравляю вас.
Для вас facebook «простой» за 200 баксов.

Я вам дам совет: просто не лезьте в это дело, вас или обманут или вы сами «лоханётесь».

Вам нужно ещё лет 10 изучать вопрос, но я думаю вы не станете. Поэтому просто забудьте, что где то там кто то приложения разрабатывает, вам это не нужно.

Ответить
Развернуть ветку
Ware Wow

Я же сказал, без бэкенда, без рекламной сети, без рекомендалки. Базовый стартовый юзерский (друзья, комменты, лайки, шеры, директ, посты) FB 200 баксов.

Более того, я бесплатно соберу на Wordpress с плагинами. Скорее всего есть даже готовые сборки, темы, значит можно уложиться в 50 баксов.

И для MVP как раз всего этого более чем достаточно.

Я не думаю, что вам стоит так переживать, вам заказчиков за оверпрайс пока должно хватать.

Ответить
Развернуть ветку
Atomic Attack

Собери, потом будешь базарить.
Пока что, вы просто сотрясаете воздух своими домыслами.
Бред сумасшедшего.

Ответить
Развернуть ветку
Secret Name

Бред

Ответить
Развернуть ветку
8 комментариев
Раскрывать всегда