Важнейшая проблема кроссплатформенной разработки решалась в мобильных фреймворках разными способами. Первоначально проект Apache Cordova (ранее PhoneGap) решил эту проблему внедрением webview-рендеринга. Затем в проекте Ionic был создан для Apache Cordova близкий к нативному набор инструментальных виджетов HTML/CSS. Ionic мотивировал всех к выбору Angular в качестве фронтенд-фреймворка для разработки кросс-платформенных мобильных приложений. Однако оба фреймворка построены на основе двунаправленных нативных мостов между JavaScript и нативным каналом связи. Другими словами, они создали универсальный интерфейс JavaScript для нативных функций в веб форме (webview).

Многие разработчики создавали мобильные приложения на основе подобных фреймворков с webview. Но всем было понятно, что основой удобного мобильного приложения являются нативные элементы графического интерфейса. С появлением React Native и Flutter произошла революция. Имея действительно нативные элементы графического интерфейса, оба фреймворка позволяли использовать единую кодовую базу, такую как у Ionic. Рассмотрим эти два фреймворка несколько подробнее.

Flutter

В рамках платформы Flutter создан фреймворк с собственными виджетами для кроссплатформенной библиотеки Skia в формате 2D графики. Skia может работать как на платформе Android, так и на iOS. Поэтому все созданное с помощью виджетов фреймворка Flutter будет работать и на Android, и на iOS. Кроме того, здесь есть библиотеки Dart для нативных функций. Например, если нужно обеспечить вибрации телефона, можно использовать библиотеку вибрации Dart vibration. Эти библиотеки Dart обычно напрямую вызывают нативный код для выполнения требуемых функций. Например, библиотека вибраций использует класс android.os.Vibrator на платформе Android.

Достоинство Flutter заключается в том, что он позволяет создавать одинаковый визуальный интерфейс для приложений на любой платформе. Приложение будет выглядеть одинаково на платформах Android, iOS, Linux, Windows, macOS и Web. Очевидно, что Google создал Flutter для решения собственной проблемы кросс-платформенной разработки. Нужен был простой способ создания приложений с одинаковым визуальным интерфейсом для Android, iOS и Fuchsia.

React Native

Facebook для решения кроссплатформенной проблемы использовал собственную веб-библиотеку  —  React. Библиотека React использует для рендеринга программный интерфейс DOM в качестве серверной составляющей. React Native создан переключением серверного приложения с DOM в нативное мобильное. Созданные с помощью React Native компоненты будут отображаться на любой платформе как действительно нативные элементы графического интерфейса. Компоновка с использованием нативных элементов графического интерфейса системы может оказаться сложной задачей, так как в Android и iOS разные системные компоновки. Поэтому в React Native для обеих мобильных платформ представлен кроссплатформенный движок компоновки Yoga.

Синтаксис механизма компоновки Yoga очень похож на используемый в CSS flexbox. Концепции обработки нативных действий у React Native и Apache Cordova очень похожие. Для выполнения нативного кода из JavaScript Apache Cordova использует нативный мост через веб-представление. А в React Native используется нативный мост через механизм JavaScript, потому что здесь нет веб-просмотра. Очевидно, что Facebook создал React Native для упрощения в своих мобильных приложениях логики обработки динамичного графического интерфейса.

Скрытые проблемы Flutter

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

· Dart не столь широко распространенный язык, по сравнению с JavaScript, Java, Kotlin, Swift и Objective-C. Поэтому при выборе Flutter придется искать специалистов по Dart или самим изучать этот язык.

· Flutter использует Dart вместо Java и Objective C/Swift. Поэтому есть библиотеки Dart для нативных операций. Некоторые библиотеки являются официальными, а некоторые  —  сторонними. Внешние библиотеки могут иметь ограничения и ошибки. Поэтому не стоит удивляться, когда тестировщик ПО сообщит о проблеме в одной из библиотечных зависимостей.

· В библиотеке 2D-графики Flutter используется собственный набор инструментов для виджетов. Есть сообщения о большом количестве ошибок, связанных с анимацией на Android/iOS.

Скрытые проблемы React Native

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

· Здесь повторяется сценарий, связанный с Flutter. Существуют библиотеки JavaScript для обработки нативных операций.

· Для запуска нативного кода React Native использует концепцию моста, несколько похожую на Apache Cordova. Несомненно, нельзя ожидать от JavaScript прироста производительности по сравнению с нативным кодом. Кроме того, требования приложения React Native к ресурсам процессора и физической памяти могут быть выше среднего уровня.

· Процесс изучения React Native может оказаться немного сложным для тех, кто не знаком с React. Flutter тем временем предлагает простую концепцию компоновки на основе дерева объектов, которая намного проще нативного подхода.

Сравним фреймворки с нативным подходом

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

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

Заключение

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

· Каждая платформа сможет предложить универсальный интерфейс для своего нативного API.

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

Реализовать вышеуказанные варианты пока не удалось. Поэтому получается, что нативный подход лучше, чем кроссплатформенные фреймворки.

Читайте также:

Читайте нас в Telegram, VK и Яндекс.Дзен


Перевод статьи Shalitha Suranga: Still, Going Native Is Better Than React Native and Flutter

Предыдущая статьяКак конвертировать PDF-файлы в PNG с помощью Python
Следующая статьяПсихологические принципы для продуктового дизайнера