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

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

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

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

1. Сериализация/десериализация каждого сообщения, создающее накладные расходы.

2. Асинхронная очередь сообщений, которая может вызывать задержки в отклике UI. Например, при быстром скролле очередь забивается сообщениями, которые еще и отменить нельзя, потому что отмена тоже будет стоять в очереди.

3. Дублирование layout-деревьев - у каждого потока было свое дерево компонентов, потому что создание происходило на одной стороне, а расчет и отрисовка - на другой. Еще их приходилось синхронизовать, опять же асинхронно.

4. Все нативные модули загружались при старте приложения, даже если не использовались, что ухудшало startup time.

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

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

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.

Заключение

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

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

А пока делитесь в комментариях, на каких проектах вы используете или планируете использовать React Native? С какими техническими проблемами столкнулись при работе с ним?