Основные Нововведения

1. Новая Архитектура React Native по умолчанию

2. React Native DevTools

3. Ускоренная работа Metro

4. Новые стилевые свойства: Box Shadow и Filter

5. Изменения, нарушающие обратную совместимость

Новая Архитектура React Native по Умолчанию

С выходом версии 0.76 Новая Архитектура React Native становится стандартом для всех новых проектов. Эта переработка внутренних механизмов платформы направлена на улучшение производительности и упрощение разработки высококачественных нативных приложений с использованием React. Команда разработчиков объявила, что Новая Архитектура готова к использованию в продакшене, что открывает новые возможности для разработчиков и обещает значительное развитие React Native в будущем.

React Native DevTools

Одним из ключевых обновлений стало введение React Native DevTools — нового инструмента для отладки приложений. Этот инструмент предлагает разработчикам знакомый интерфейс, основанный на Chrome DevTools, с надежными точками останова, просмотром значений переменных, пошаговой отладкой и мощной консолью JavaScript. Кроме того, интеграция с React DevTools улучшена, что позволяет быстрее и надежнее инспектировать компоненты и профилировать приложения.

Особо стоит отметить улучшенный пользовательский опыт: новое наложение «Paused in Debugger» ясно показывает, когда приложение приостановлено на точке останова, а предупреждения в LogBox теперь отображаются сводкой и скрываются при подключении DevTools. Также DevTools поддерживают мгновенный запуск без дополнительной настройки, что значительно упрощает процесс отладки.

Ускоренная работа Metro

В версии 0.76 была значительно улучшена производительность Metro, сервера, отвечающего за сборку и разрешение модулей. Разработчики отметили, что разрешение модулей стало примерно в 15 раз быстрее, а время сборки «теплых» сборок увеличилось примерно в 4 раза. Эти улучшения существенно сокращают время ожидания разработчиков и делают процесс разработки более плавным и эффективным.

Новые стилевые свойства: Box Shadow и Filter

Обновление также включает два новых стилевых свойства, доступных только в Новой Архитектуре:

boxShadow style:

• boxShadow: Позволяет добавлять тени к элементам с возможностью настройки позиции, цвета, размера и размытия тени. Поддерживает как строковый формат, аналогичный CSS, так и объектный формат для большей гибкости.

Ограничения:

• Цвет тени по умолчанию — чёрный.

• Поддержка обычных теней начиная с версии Android 9+ и поддержка inset-теней начиная с версии Android 10+.

filter style:

• filter: Применяет графические фильтры к элементам, такие как яркость, насыщенность, оттенок, размытие и тени. Также поддерживает как строковый, так и объектный форматы.

Ограничения:

• На iOS поддерживаются только яркость и непрозрачность.

• На Android фильтры размытия и теней поддерживаются только на Android 12+.

• Свойство filter подразумевает overflow: hidden, поэтому дочерние элементы будут обрезаться, если выходят за границы родителя.

Breaking Changes

С обновлением пришли и некоторые изменения, которые могут потребовать внимания разработчиков:

1. Удалена зависимость от @react-native-community/cli:

React Native стал фреймворк-агностичным, что позволяет команде быстрее развивать проекты независимо друг от друга. Разработчикам, использующим CLI в своём рабочем процессе, необходимо явно добавить зависимости на CLI в package.json проекта.

// …
"devDependencies": {
  // …
  "@react-native-community/cli": "15.0.0",
  "@react-native-community/cli-platform-android": "15.0.0",
  "@react-native-community/cli-platform-ios": "15.0.0",
},

2. Уменьшение размера Android-приложений на ~3.8 МБ:

За счёт слияния нативных библиотек в libreactnative.so размер приложений на Android уменьшился примерно на 3.8 МБ (около 20% от общего размера), а время запуска приложения сократилось на ~15 мс (~8%). Однако это изменение требует от разработчиков обновления метода onCreate в классе MainApplication для корректной загрузки новой библиотеки.

import com.facebook.react.soloader.OpenSourceMergedSoMapping
import com.facebook.soloader.SoLoader

class MainApplication : Application(), ReactApplication {

  override fun onCreate() {
    super.onCreate()
    SoLoader.init(this, OpenSourceMergedSoMapping)
  }
}

3. Обновление минимальных требований к SDK:

• iOS: с версии 13.4 до 15.1

• Android: с SDK 23 до SDK 24 (Android 7)

Прочие Изменения

• Анимации: Остановлено отправление обновлений состояния в React при зацикленных анимациях, что предотвращает ненужные перерисовки.

• DevTools: Удалены вкладки производительности и сети в инспекторе под Новой Архитектурой.

• Текстовый движок: Всегда используется AttributedStringBox вместо AttributedString в TextLayoutManager.

• Android: Изменена реализация фона представлений.

• iOS: Удалён макрос RCT_EXPORT_CXX_MODULE_EXPERIMENTAL для автосвязывания чистых C++ модулей.

Обновление до 0.76

Разработчикам рекомендуется воспользоваться React Native Upgrade Helper для просмотра изменений кода между версиями. Пользователи Expo смогут воспользоваться React Native 0.76 в составе Expo SDK 52. Для создания нового проекта через CLI можно использовать следующую команду:

npx @react-native-community/cli@latest init MyProject --version latest

Важно: Версия 0.76 теперь является последней стабильной версией React Native, а серия 0.73.x больше не поддерживается. Для получения дополнительной информации следует ознакомиться с политикой поддержки React Native.

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

error: Abort trap: 6 (in target 'iOSPhotoEditor' from project 'Pods')

В то время как локальные сборки на эмуляторы и устройства собирались корректно.

Проблема оказалась в файле CropView.swift который лежал в директории Pods, нужно было подкорректировать один блок if(), заменив в нем вызов функции UI_USER_INTERFACE_IDIOM() на UIDevice.current.userInterfaceIdiom.

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

На GitHub давно висит issue с этой ошибкой и фиксом на нее, делать новый pull request смысла нет. Создавать свой форк и заливать его на GitHub/CocoaPods показалось бессмысленно ради одной строчки кода. Пришел к выводу что нужно сделать локальный патч который бы применялся после каждой установки подов.

Итак, приступим. Полазив на просторах Google нашел утилиту которая выполняет всю рутину за вас, но у меня ее запустить так и не удалось, но на всякий случай оставлю ссылку (cocoapods-patch).
Также есть второй минус у этого инструмента, его нужно будет установить всем разработчикам в вашем проекте, мой способ ниже позволит избежать этого.

Для начала необходимо сгенерировать diff изменений в проблемном файле. Чтобы это сделать необходимо дублировать наш файл и сделать в нем необходимые правки. Новый файл я назвал CropViewPatched.swift.

Далее из папки iOS проекта в терминале я выполнил следущую команду:

git diff -u ./Pods/iOSPhotoEditor/Photo\ Editor/Photo\ Editor/CropView.swift ./Pods/iOSPhotoEditor/Photo\ Editor/Photo\ Editor/CropViewPatched.swift > iOSPhotoEditor.patch

Давайте разберемся что тут происходит:

• параметр -u генерирует diff патч;
• вторым аргументом идет путь к оригинальному файлу CropView.swift;
• третьим аргументом идет путь к измененному файлу CropViewPatched.swift;
• далее идет такая конструкция > iOSPhotoEditor.patch она позволяет сохранить полученный diff изменений в файл iOSPhotoEditor.patch в той директории откуда вы запустили данную команду;

Полученный файл (iOSPhotoEditor.patch) будет выглядеть примерно так:

Далее в папке iOS я создал папку patches чтобы в дальнейшем хранить там все патчи если это потребуется и поместил туда полученный iOSPhotoEditor.patch.

Остался финальный шаг, необходимо найти в вашем Podfile секцию post_install

post_install do |installer|
   ...
end

Если таковой нет то создайте ее в конце вашего файла. Обратите внимание на то что данная секция может быть только одна в вашем Podfile.

Теперь в конце этой секции необходимо вставить следующую инструкцию:

post_install do |installer|
  ...
  puts '🟢 Патчим iOSPhotoEditor'
  %x(patch './Pods/iOSPhotoEditor/Photo\ Editor/Photo\ Editor/CropView.swift' < './patches/iOSPhotoEditor.patch')
end

Давайте разберемся что тут происходит:

• puts –позволяет нам вывести лог при выполнении команды pod install
• с помощью %x(...) можно выполнить какую-либо shell команду вашем Podfile.
• patch – применяет полученный патч файл к проблемому файлу
• вторым аргументом для patch идет путь к проблемному файлу относительно вашего Podfile (обратите внимание на то что путь взят в одинарные кавычки и перед пробельным символом стоит \)
• третьим аргументом после < идет путь к вашему патч файлу относительно вашего Podfile

Вот и все, теперь после выполнения команды pod install к вашему проблемному файлу будет применятся ваш патч.

Желаю всем удачных патчей

Если вы следите за новостями из мира React Native, вы наверняка слышали о Fabric - новой архитектуре для React Native. Он использовался в течение довольно долгого времени внутри Facebook, и теперь основная команда решила заняться его более широким внедрением с открытым исходным кодом. С предстоящим выпуском React Native 0.68 перейти на новую архитектуру будет просто, необходимо всего лишь установить одну новую константу в вашем проекте перед сборкой приложения, что облегчит любому разработчику возможность попробовать новую архитектуру. Однако переход на Fabric будет невозможен для всех после выхода новой версии React Native, так как многие проекты React Native зависят от дополнительных библиотек, которые также должны быть адаптированы к новой архитектуре. Это особенно актуально для библиотек, которые предоставляют дополнительные нативные функции или предоставляют нативные компоненты, специфичные для конкретной платформы. Мы надеемся увидеть большой толчок к принятию Fabric среди самых популярных проектов сообщества React Native. Как Software Mansion — автора ряда популярных библиотек React Native, мы хотим объявить о своем намерении портировать проекты, которые мы поддерживаем, и возглавить усилия по внедрению Fabric на собственном примере, чтобы как можно скорее включить новую архитектуру для каждого приложения React Native.

Сегодня мы публикуем первую версию библиотеки react-native-screens, совместимую с Fabric. Это не только первая совместимая с Fabric версия этого очень популярного проекта (устанавливаемая на 70% чаще, чем react-native из NPM), но и первая нативная библиотека компонентов, совместимая с новой архитектурой React Native в целом. В этой статье мы обсудим, что нужно для переноса существующей библиотеки с собственными примерами кода на Fabric и покажем наш подход к разработке. Если вы заинтересованы в экспериментах с новой архитектурой, мы также покажем как вы можете использовать react-native-screens с вашим первым приложением на Fabric. Если вы поддерживаете свой собственный пакет для React Native, мы надеемся, что эта статья вдохновит вас на его миграцию в Fabric и даст вам хорошее представление об этом процессе — для этого мы делимся ссылками на diff изменения и PR из нашего GitHub, которые касаются определенных этапов миграции. Мы были бы рады, если бы вы взяли конфигурацию проекта и идеи, которые мы здесь представляем, чтобы подготовить другие библиотеки для Fabric.

Используйте react-native-screens с Fabric уже сегодня

Самый последний релиз-кандидат React Native (0.68) позволяет вам включить архитектуру Fabric в вашем проекте. Этот тип настройки призван помочь сделать процесс миграции на Fabric постепенным. Люди, которые хотят обновить версию React Native, могут безопасно сделать это, не задумываясь о Fabric. Как только приложение, включая его зависимости, будут готовы к новой архитектуре, вы сможете активировать новую архитектуры для своего проекта. Ядро React Native поддерживает как старую, так и новую архитектуру. Однако, как следствие, библиотеки должны с этим справляться. Если мы хотим сделать переход плавным, существующие пакеты должны обеспечивать аналогичный уровень совместимости. Именно так подготовлена ​​версия библиотеки react-native-screens@3.12. Вы можете использовать его с любой совместимой версией React Native через старую архитектуру, или вы можете активировать переключатель новой архитектуры в приложении React Native 0.68 и использовать его через Fabric.

Простой способ чтобы начать

Чтобы протестировать реализацию react-native-screens как с новой, так и со старой архитектурой, мы создали пример приложения в нашем основном репозитории GitHub, которое настроено на работу с Fabric. Самый простой способ протестировать его — клонировать репозиторий react-native-screens с GitHub и следовать инструкциям из папки FabricExample.

Создание вашего первого приложения Fabric с помощью react-native-screens

Как упоминалось ранее, включить Fabric очень просто, необходимо активировать одну константу перед сборкой вашего приложения. Вы можете попробовать это после обновления существующего приложения до 0,68, но ниже мы описываем процесс создания нового проекта react-native:

1. Создайте новое приложение с помощью React Native CLI: npx react-native init NewRN68App --version 0.68.0-rc.1
2. Установите react-native-screens: yarn add react-native-screens
3. Для активации новой архитектуры для iOS необходимо запустить командуpod install в папке ios следующим образом: RCT_NEW_ARCH_ENABLED=1 pod install
4. Для андроид необходимо установить новое значение newArchEnabled=true в файле android/gradle.properties
5. Теперь вы можете приступить к созданию приложения как обычно на Android и на iOS. Установленная версия react-native-screens автоматически определит, включен ли Fabric, и будет использовать соответствующую реализацию.

Обратите внимание, что реализация Fabric для react-native-screens пока не поддерживает все доступные параметры. Если вы хотите знать, почему это так, читайте дальше.

Обзор процесса миграции

На уровне архитектуры, Fabric представляет новый интерфейс кода JavaScript для взаимодействия с нативным ядром. Вместо использования моста вся связь между встроенными компонентами и компонентами JS осуществляется через JSI (C++ API для взаимодействия с виртуальной машиной JS). Информация с одной стороны на другую передается с помощью функций C++ вместо сериализации/десериализации для передачи по мосту. Из-за этого библиотеки, которые стремятся поддерживать новую архитектуру, должны адаптироваться к этому новому интерфейсу. Использовать его относительно просто, когда вы хотите создать совершенно новую библиотеку или набор собственных компонентов (мы обсудим некоторые детали позже), однако адаптация Fabric к существующей библиотеке создает некоторые дополнительные проблемы. В частности, мы хотим иметь возможность поддерживать как версию с Fabric, так и версию не относящиеся к Fabric, с как можно большим количеством общего кода между этими двумя реализациями. Это позволило бы нам улучшать библиотеку и исправлять ошибки, а также предлагать людям, которые могут перейти на Fabric, и тем, кто не может, одинаковый уровень поддержки.

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

Первое, что мы сделали, это написали спецификации компонентов в Flow - диалекте JS. Этот код является источником истины для приложения. Он предоставляет спецификацию, используемую как на нативной стороне, так и на стороне JS. Затем мы изменили часть нашего нативного кода для хорошей работы с Fabric. На этом этапе мы добавили различные реализации, для обработки пропсов и событий. На Android кодовая база является общей между старой и новой архитектурой. На iOS нам нужно было создавать новые файлы, тем самым делая две реализации независимыми. Чтобы сохранить совместимость библиотеки с обеими архитектурами, у нас есть ряд файлов/классов, специфичных для данной архитектуры. В некоторых случаях мы решили разветвить небольшие части кода проверками архитектуры, так как иногда для нас было бы более целесообразно оставить большую часть данного файла или класса и иметь только небольшие фрагменты, специфичные для архитектуры — мы делаем это как в JS, так и в нативной кодовой базе.

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

Если вы хотите глубже погрузиться в изменения, мы разделили их на несколько PR:

• Базовые изменения в JS и iOS
• Базовые изменения Android
• Улучшение процесса установки для Android
• Исправление pop-анимации (работа в процессе)
• Все изменения

Software Mansion & Shopify

Поскольку это первый большой релиз для нас в этом году, мы хотели бы воспользоваться этой возможностью, чтобы поблагодарить Shopify за помощь в наших усилиях, связанных с React Native. Третий год подряд мы сотрудничаем в улучшении экосистемы React Native путем создания и обслуживания основных библиотек с открытым исходным кодом. Одной из основных целей этого года является обеспечение более широкого внедрения новой архитектуры, и этот выпуск библиотеки react-native-screens является лишь первым из многих шагов в этом направлении, которые мы собираемся сделать благодаря поддержке Shopify.

Что дальше

Выпуск совместимой с Fabric версии react-native-screens — важная веха на пути сообщества к адаптации новой архитектуры React Native. Мы надеемся, что за нами последуют другие разработчики поддерживающие свои библиотеки, и рады поделиться нашим опытом. Если у вас есть библиотека или вы планируете перенести свой проект на Fabric, не стесняйтесь обращаться к нам! Команда Open Source в Software Mansion намерена работать над портированием всех библиотек в ближайшем будущем, которые мы поддерживаем в настоящее время, поэтому следите за обновлениями и не забудьте подписаться на нас в Twitter.

Перевод статьи Introducing Fabric to react-native-screens выполнен для телеграмм канала ReactNative - info

Автор оригинала: Jakub Tkacz

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

Что умеет данный инструмент:

— Собирать логи с устройсва;

— Собирать информацию об нативных и JS крашах;

— Собирать информацию о запросах в сеть;

— Экспортировать собранные данные в JSON;

Настройка довольно простая, сначала необходимо установить этот npm пакет:

yarn add mobile-app-debugger

Далее для Android необходимо в AndroidManifest.xml в тэге application добавить следующую строчку:

<application

android:usesCleartextTraffic="true"

…>

Для iOS достаточно просто выполнить pod install

После установки пакета в главном index.js файле вашего проета добавте следующие строки:

import { AppDebugger } from 'app-debugger';

AppDebugger.configure({

port: 3000,

isOverwriteConsole: true,

});

Мы только что настроили дебаггер, чтобы он работал с 3000 портом, к этому мы еще вернемся.

Дело осталось за малым, необходимо скачать приложение App Debugger для  нужной платформы:

—  Android

—  iOS

Зайти в дебагер, ввести порт который мы передавали в метод AppDebugger.configure, не закрывая дебагер перейти в ваше RN приложение, проделать необходимые манипуляции, снова вернуться в дебагер и наслаждаться результатом 🙂

Более детальная информация по пакету: https://www.npmjs.com/package/mobile-app-debugger

Ну а на этом все, всем спасибо 🍀

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

Как и для любого другого фреймворка или технологического стека, мы задаем себе один и тот же вопрос. Что лучше? — Flutter или React Native. Некоторые разработчики могут голосовать за Flutter, из-за его почти нативной производительности и богатого набора виджетов. Между тем, некоторым разработчикам нравится React Native из-за его дружелюбности к разработчику и поддержки компонентов для конкретной платформы.

Приложения Flutter демонстрируют значительное повышение производительности по сравнению с приложениями React Native благодаря молниеносной связи Dart-to-Native. React Native взаимодействует с собственным API через мост JavaScript. Концепция моста JavaScript не работает хорошо для всех требований в разработке.

В результате сообщество разработчиков начало критиковать React Native, так как он показал низкую производительность на бюджетных устройствах из-за быстро разряженных батарей так как использование ресурсов было выше среднего. Теперь React Native решает основные проблемы связанные с производительностью путем перепроектирования своих основных модулей. Давайте обсудим, как новая архитектура React Native конкурирует с Flutter.

Как Flutter решал проблемы производительности лучше, чем React Native

Flutter становится все более популярным с каждым днем по двум основным причинам: производительность и гибкость. Элементы управления пользовательским интерфейсом, специфичные для платформы, ограничены для современных сценариев использования и удобства использования. Например, реализация бокового меню в iOS трудна без сторонней библиотеки, так как боковое меню не является частью рекомендаций Apple UX. Flutter не использует собственные элементы пользовательского интерфейса, специфичные для платформы, но предлагает свой собственный набор инструментов пользовательского интерфейса. Так Flutter поставляется со встроенной библиотекой 2D-рендеринга (Skia).

React Native отображает нативные элементы пользовательского интерфейса, специфичные для платформы, на основе компонентов React. Код React Native работает внутри движка JavaScript, а контекст JavaScript взаимодействует с нативным кодом (нативным хост-приложением) через мост. Мост JavaScript использует асинхронный коммуникационный подход на основе JSON. Если вы не используете Hermes, среда выполнения React Native интерпретирует пакет JavaScript с помощью JavaScriptCore (JSC). В результате приложения работают медленно и снижают удобство использования, когда вы так часто используете нативные API и добавляете больше JavaScript кода.

Flutter не использует JavaScript-мост и JIT-компикцию для приложений. Связь Flutter engine Dart-to-Native использует более быстрые двоичные буферы памяти.

Области, где React Native работает лучше, чем Flutter

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

(прим. ред.) По своей сути приложение на Flutter является канвасом

Разработка приложений становится проще, когда есть кроссплатформенная система компоновки. Вот почему Electron стал выбором номер один для создания кроссплатформенных десктопных приложений. Он использует HTML в качестве кроссплатформенной системы компоновки. Аналогичным образом, React Native также предоставляет кроссплатформенную систему компоновки на основе Flexbox для рендеринга элементов UI, специфичных для платформы. С другой стороны, Flutter не имеет удобной для фронтенд-разработчика системы компоновки, и он предлагает новый макет на основе дерева виджетов, который иногда сбивает с толку современных разработчиков, которые пришли из мира веб-разработки.

Кроме того, Hermes подобный поддержке браузерного API JavaScript, и среда разработки на основе React повышают производительность разработчиков React Native по сравнению с Flutter.

Как новая архитектура React Native решает проблемы с производительностью

Основным недостатком React Native было отсутствие производительности на мобильных устройствах среднего и низкого класса. Ранее приложения на основе React-Native имели медленное время запуска, потому что среда выполнения JavaScriptCore интерпретировала пакет JavaScript при запуске приложения. Позже команда React Native создала Hermes и ускорила время запуска приложения, представив компиляцию AOT (с опережением времени) для пакета JavaScript. Концепция AOP Hermes помогла приложениям React Native снизить потребление батареи за счет сокращения использования ресурсов. React Native скоро будет использовать Hermes в качестве движка JavaScript по умолчанию для всех новых проектов из-за этих улучшений производительности.

Но мост JavaScript не работает хорошо во всех случаях разработки, так как он использует асинхронную связь на основе JSON путем сериализации JavaScript/нативных объектов. React Native обновила свою текущую архитектуру для решения этих проблем с производительностью. Теперь новый компонент под названием JSI (JavaScript Interface) заменяет текущий модуль моста. JSI позволяет контексту JavaScript вызывать нативные методы непосредственно без моста, удерживая нативные ссылки в контексте JavaScript. Кроме того, он позволяет нативному контексту React Native напрямую манипулировать объектами JavaScript.

Коммуникация событий пользовательского интерфейса новой архитектуры (также известная как Fabric) использует JSI. Новая архитектура также предлагает новую концепцию ленивой загрузки нативных модулей через TurboModules. TurboModules еще больше ускорит время запуска приложения.

Как видите, новая архитектура решает почти все проблемы производительности, с которыми в настоящее время сталкиваются приложения React Native. Реализация новой архитектуры React Native еще не выпущена, но она с открытым исходным кодом. Meta уже протестировала архитектуру со своими приложениями сделанными на React Native.

Вывод: что лучше?

Нет ничего под названием «Лучший кроссплатформенный фреймворк» — каждый фреймворк хорош в конкретных сценариях использования. Однако ранее многие разработчики согласились с тем, что Flutter является самым мощным кроссплатформенным фреймворком, когда-либо созданным из-за его производительности и гибкости. Я объяснил, почему Flutter лучше, чем React Native, в этой статье.

Новая архитектура будет приравниваться как к показателям React Native, так и к показателям Flutter. Наконец, мы можем рассмотреть React Native против Flutter как просто JavaScript/React против Dart/MaterialUI. Возможно, речь идет только об опыте разработчиков. Теперь мы можем игнорировать коэффициент сравнения производительности и сосредоточиться исключительно на том, что мы разрабатываем, чтобы выбрать лучшую структуру.

Другими словами, если вам нужен готовый UI, используйте Flutter. Если вам нужен собственный UI, используйте React Native. В противном случае, если вам нравится Dart, используйте Flutter, иначе используйте React Native.

Спасибо, что прочитали.

Перевод статьи "You Don’t Have to Compare Flutter and React Native Anymore", ссылка на оригинальный пост

Перевод выполнен для телеграм канала ReactNative - info

Минимальная зарплата для Junior: 100$ / месяц (Индия);

Максимальная зарплата для Junior: 1700$ / месяц (Польша)

Средняя зарплата для Junior: 900$ / месяц

Минимальная зарплата для Middle: 650$ / месяц (Россия)

Максимальная зарплата для Middle: 3900$ / месяц (Россия)

Средняя зарплата для Middle: 2300$ / месяц

Минимальная зарплата для Senior: 2000$ / месяц (Russia)

Максимальная зарплата для Senior: 12000$ / месяц (USA)

Средняя зарплата для Senior: 5350$ / месяц

Более подробные результаты можно найти в Гугл таблице (клик)

Собрать релизную сборку на реальный девайс

iOS:
react-native run-ios --device --scheme release

Android:
react-native run-android device --variant=release

Отладка андроид приложения по WiFi через ADB

adb tcpip 5555  
adb reverse tcp:8081 tcp:8081

Узнать MD5 SHA1 SHA256 подписи для apk

В директории android выполнить, где key0 алиас ключа:

keytool -list -v -keystore C:\absolute_path_to\keystore.jks -alias key0

Скрипт для автоматической очистки и сборки android проекта

cd ./android & gradlew.bat clean & cd .. & react-native run-android

Генерация JS бандла

iOS:

react-native bundle --dev false --entry-file index.js --bundle-output ios/main.jsbundle --platform ios

Android: 

react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle

Как узнать кто занял порт дебагера или metro bundler (MacOS/Linux)

sudo lsof -i :8081 // покажет список процессов
kill -9 <PID> // убивает ненужный процесс по PID