Разбираем архитектуру React Native изнутри — мост между JS и нативным кодом, новую архитектуру на JSI, и где у этого подхода объективные технические границы.
Мы уже разбирали, чем React Native отличается от WebView-обёрток и полностью нативной разработки, в общем обзоре подходов к созданию мобильных приложений. Но за формулировкой «React Native даёт нативную производительность» стоит конкретная техническая архитектура, понимание которой объясняет и сильные стороны фреймворка, и его реальные ограничения — а не маркетинговые формулировки.
Как JavaScript управляет нативным интерфейсом
Ключевая идея React Native в том, что бизнес-логика и описание интерфейса пишутся на JavaScript, но фактические элементы интерфейса — это настоящие нативные компоненты платформы, а не веб-элементы, отрисованные в WebView. Когда React-компонент описывает кнопку, на экране появляется настоящая UIButton на iOS или Button на Android, а не HTML-элемент, притворяющийся кнопкой.
Долгое время связь между JS-кодом и нативной стороной обеспечивалась через так называемый мост (bridge) — асинхронный канал, по которому команды сериализовались в JSON и передавались между JS-потоком и нативным потоком. Это работало, но создавало накладные расходы на сериализацию и делало анимации, завязанные на постоянный обмен данными с нативной стороной, потенциально менее плавными по сравнению с полностью нативным кодом.
Новая архитектура: JSI, Fabric и TurboModules
Современная версия React Native отказалась от асинхронного JSON-моста в пользу JSI (JavaScript Interface) — механизма, который позволяет JS-коду напрямую вызывать методы нативных объектов без сериализации в промежуточный формат. Это принципиально снижает накладные расходы и позволяет синхронно обмениваться данными между JS и нативным слоем там, где это нужно.
- Fabric — новый механизм рендеринга интерфейса, который строит дерево компонентов согласованно между JS и нативной стороной и синхронизирует его быстрее, чем старая архитектура;
- TurboModules — механизм подключения нативных модулей, которые теперь загружаются по требованию (lazy loading), а не все сразу при старте приложения, что ускоряет время запуска;
- Codegen — генерация типобезопасных интерфейсов между JS и нативным кодом на основе TypeScript-описаний, что снижает число ошибок несоответствия типов на границе двух языков.
Практический эффект новой архитектуры — более плавные анимации и жесты, которые могут выполняться в нативном потоке без ожидания ответа от JS-потока на каждый кадр. Это закрывает значительную часть исторических претензий к React Native по поводу «дёрганых» анимаций на сложных экранах.
Expo и управляемый workflow
Expo — это надстройка над React Native, которая берёт на себя конфигурацию нативных проектов, сборку, публикацию в сторы и механизм OTA-обновлений (over-the-air) — возможность доставлять обновления JS-кода пользователям без повторного прохождения модерации в App Store и Google Play. Это огромная экономия времени для большинства коммерческих проектов, но у неё есть архитектурная цена: часть низкоуровневого нативного кода скрыта за абстракциями Expo, и для специфичных нативных возможностей иногда приходится «выходить» из управляемого workflow в bare-режим, где разработчик получает прямой доступ к нативным проектам iOS и Android.
Мы разбирали, как связка React Native и Expo ускоряет разработку и сопровождение мобильных приложений, в статье «Что ускоряет разработку мобильных приложений без потери качества» — для большинства коммерческих сценариев это действительно золотая середина между скоростью и контролем.
Где у React Native есть объективные границы
Даже с новой архитектурой остаются классы задач, где React Native уступает полностью нативной разработке: сложная 3D-графика и игровые движки, интенсивная фоновая обработка (аудио, видео в реальном времени), глубокая интеграция со специфичным оборудованием — Bluetooth Low Energy с нестандартными протоколами, специализированные датчики, ARKit/ARCore на пределе возможностей платформы. Для таких сценариев чаще пишут нативный модуль под конкретную задачу и подключают его к остальному React Native-приложению через TurboModules, комбинируя оба подхода в одном проекте.
Важно понимать: необходимость написать один нативный модуль под специфичную задачу не означает, что весь проект нужно делать полностью нативным. Гибридная модель — React Native для основной части интерфейса и бизнес-логики, нативные модули для узких участков с высокими требованиями к производительности — на практике закрывает подавляющее большинство коммерческих задач.
Наш опыт работы с React Native
В Codeking React Native с Expo — основной стек для мобильной разработки, потому что он покрывает подавляющее большинство коммерческих сценариев с оптимальным соотношением скорости разработки и качества результата. Для проектов с интеграцией в 1С-Битрикс мы используем собственный модуль, опирающийся на штатное REST API платформы — подробнее об этом можно прочитать в статье «Мобильное приложение для Битрикс24: интеграция и кастомная разработка».
Когда в проекте появляется задача, для которой стандартных возможностей React Native недостаточно, мы не переписываем приложение целиком, а разрабатываем точечный нативный модуль под конкретную функциональность. Это позволяет сохранить единую кодовую базу и скорость разработки для большей части приложения, добавляя нативный код только там, где он действительно необходим.