React Native: архитектура и платформенные особенности

React Native прошел путь от решения с фундаментальными архитектурными ограничениями до платформы с современным, производительным ядром. В этой статье мы разберем, как работала старая архитектура на основе Bridge, как ее заменили JSI, Fabric и Hermes, в каких случаях React Native - оптимальный выбор для проекта и какие платформенные особенности встретятся в работе.

Старая архитектура с Bridge

В основе этой архитектуры лежат асинхронный Bridge. Нативный код и JavaScript работали в отдельных потоках. Общение между ними происходило через Bridge, который передавал сообщения в формате JSON.

React Native: архитектура и платформенные особенности

Какие минусы есть у этого подхода:

  1. Сериализация/десериализация каждого сообщения, создающее накладные расходы.
  2. Асинхронная очередь сообщений, которая может вызывать задержки в отклике UI. Например, при быстром скролле очередь забивается сообщениями, которые еще и отменить нельзя, потому что отмена тоже будет стоять в очереди.
  3. Дублирование layout-деревьев - у каждого потока было свое дерево компонентов, потому что создание происходило на одной стороне, а расчет и отрисовка - на другой. Еще их приходилось синхронизовать, опять же асинхронно.
  4. Все нативные модули загружались при старте приложения, даже если не использовались, что ухудшало startup time.

Новая архитектура с JSI, Fabric, Hermes

Новая архитектура сильно меняет принципы взаимодействия.

React Native: архитектура и платформенные особенности

JavaScript Interface (JSI) – легковесный C++ слой, заменяющий Bridge.

  • Синхронные вызовы. Прямой вызов нативных методов из JS.
  • Общая память. Передача данных по ссылке без сериализации.
  • Ленивая загрузка модулей. Модули загружаются только по требованию.

Результат: Устранение задержек, связанных с очередью и сериализацией.

Fabric – новый рендер на C++.

  • Единое дерево. Исчезает дублирование — единое дерево управляется React.
  • Синхронный рендеринг. Возможность применять изменения до отрисовки экрана (через useLayoutEffect).
  • Улучшенная работа списков. Эффективный рендеринг FlatList.

Результат: Повышенная производительность и предсказуемость рендеринга.

Hermes – собственный JS-движок.

  • AOT-компиляция. Компиляция JavaScript в байткод на этапе сборки.
  • Оптимизирован под мобильные устройства.

Результат: ускорение запуска, уменьшение размера билда.

Техническое резюме и варианты для использования

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

Идеальные сценарии для использования React Native:

  1. Проекты с ограниченными ресурсами, где необходимо охватить обе платформы силами одной команды.
  2. Приложения, ориентированные на бизнес-логику и контент, а не на сложную анимацию или тяжелые вычисления.
  3. Проекты, требующие высокой скорости итераций, где возможность OTA-обновлений критически важна для оперативного исправления ошибок и внедрения новых функций.
  4. Команды с опытом в веб-разработке (JavaScript/TypeScript, React), что позволяет им быстро включиться в работу.

Когда стоит рассмотреть другие варианты:

  1. Высоконагруженные приложения с сложной графикой и анимацией (например, мобильные игры).
  2. Проекты, глубоко интегрированные в специфические платформенные особенности, где требуется прямой и полный доступ к нативным API.

Теперь перейдем к практическим вопросам: как организован процесс разработки и какие платформенные особенности встретятся.

Процесс разработки

Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта.

Bare React Native

Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:

  1. Установка зависимостей,
  2. Запуск Metro bundler,
  3. Запуск приложения на эмуляторе или устройстве iOS/Android.

Процесс сборки приложения для продуктовой среды очень похож на традиционную мобильную разработку:

  1. Для iOS сборка происходит через Xcode, где для приложения настраиваются схемы, сертификаты, создается архив и т.д.
  2. Для Android в первый раз потребуется генерация keystore и настройка gradle под свои потребности. После этого происходит сборка apk/aab для публикации в стор.

У такого подхода к разработке есть свои преимущества и недостатки. В преимущества можно выделить:

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

К недостаткам можно отнести следующее:

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

Для удобства разработки можно использовать Expo – React Native фреймворк и платформа, которая помогает делать разработку быстрее и удобнее.

Expo

Expo предлагает инструменты для удобного процесса разработки, например, такие как:

  • Expo CLI - инструмент командной строки. В нем есть, например, команды для запуска приложения, сборки, установки зависимостей, обновления версий зависимостей и т.д.
  • Expo Go - мобильное приложение для тестирования, скачивается из App Store/Google Play и позволяет тестировать разрабатываемое приложение на своем устройстве.
  • Expo Router - позволяет работать с файловой маршрутизацией.
  • Также существует EAS – облачный сервис для сборок (EAS Build), обновлений over-the-air (EAS Update) и публикаций приложений в сторы (EAS Submit).
  • Expo SDK - предоставляет множество библиотек как с компонентами, так и пакеты для работы с функциональностью мобильных устройств (expo-camera, expo-location, expo-notifications, expo-secure-store и т.д.)

Преимущества Expo:

  • Быстрый старт - проект готов за минуты,
  • Богатый SDK - доступ к большинству нативных API,
  • Облачная инфраструктура - сборка без установки Xcode/Android Studio,
  • Over-the-air (OTA) обновления - мгновенные обновления без App Store,
  • Отличный DX - Hot Reload, debugging, тестирование,
  • Кроссплатформенность - один код для iOS/Android/Web.

Недостатки:

  • Размер приложения - Expo SDK добавляет вес,
  • Ограничения managed workflow - не все нативные модули доступны,
  • Зависимость от Expo - привязка к их инфраструктуре при использовании EAS,
  • Стоимость облачных сервисов для больших команд при использовании EAS.

Over-the-Air (OTA) обновления

OTA-обновления позволяют обновлять JavaScript-код приложения без публикации новой версии в магазинах приложений.

Как это работает: при запуске приложение проверяет сервер на наличие обновлений. Если новая версия есть, оно скачивает и применяет ее при следующем запуске.

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

Ограничения: можно обновлять только JavaScript-логику, но не нативный код. Необходимо соблюдать правила App Store и Google Play.

Основные компоненты и стилизация

Если погружаться в детали React Native, то можно сразу увидеть отличия от фреймворка веб-разработки React и от стандартной мобильной разработки для iOS/Android. В React Native используется свой набор компонентов, например,

  • View - аналог div с flex-свойствами,
  • Text – для любого текста,
  • Image, ImageBackground – для изображений,
  • Button, Pressable, TouchableOpacity, TouchableHighlight, TouchableWithoutFeedback – для кликабельных элементов и кнопок,
  • FlatList, ScrollView, VirtualizedList, SectionList – для списков или прокручивающихся элементов,
  • TextInput – поле ввода для текста,
  • и другие.

Стили в React Native — это не CSS, а отдельные объекты. Для удобства используется абстракция StyleSheet, похожая на CSS.

(Сравнение для React и React Native)
(Сравнение для React и React Native)
(Пример стилей для React Native)
(Пример стилей для React Native)

Пример реализации стилей показывает, что разметку можно описывать в терминах Flexbox, все декларативно, привычно и классно. Но ведь FlexBox — это модель CSS, и нативное приложение о нем ничего не знает, значит расположением компонентов занимается кто-то другой.

Здесь хочется рассказать о Yoga Layout Engine — это кроссплатформенный layout-движок на C++, который реализует алгоритм Flexbox.

Сам по себе он ничего не рисует, он вычисляет координаты и размеры элементов по Flexbox описанию, как в примере:

React Native: архитектура и платформенные особенности

Платформенные особенности iOS и Android

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

Платформенные особенности iOS.

  • настройка окружения (нужен MacOS),
  • создается папка iOS, в которой лежит конфигурация приложения, точка входа, конфигурация для Xcode, workspace с pods и т.д.
  • навигация в iOS – swipe back, это стоит учитывать при создании кастомных обработчиков навигации,
  • отличия в UI может проявляться в списках, так как у iOS есть эффект bouncing scroll,
  • присутствуют различия и в стилях, например, для создания эффекта тени нужно использовать свойства shadowColor, shadowOffset, shadowOpacity, shadowRadius.

Можно еще отменить, что в iOS не работает такой стиль как borderStyle: «dashed» и нужно искать альтернативы.

Платформенные особенности Android:

  • настройка окружения (нужна AndroidStudio),
  • создается папка Android, в которой лежит конфигурация приложения, точка входа, нативный код, ресурсы и т.д.
  • навигация с помощью аппаратной кнопки «Назад»,
  • у Android нет эффекта bouncing scroll,
  • для создания эффекта тени нужно использовать свойство elevation и borderStyle: «dashed» работает.

Заключение

Таким образом, для подавляющего большинства корпоративных задач — от систем CRM и ERP до внутренних порталов и инструментов для сотрудников — React Native предлагает оптимальное соотношение скорости разработки, производительности и стоимости владения.

1
Начать дискуссию