Интерфейс Javascript (JSI): обзор и необходимость перестройки архитектуры React Native
React Native имеет множество преимуществ, таких как кроссплатформенная поддержка, обновления OTA, перезагрузка в реальном времени, экономическая эффективность и т. д., но самым большим узким местом в масштабировании нативных приложений React является производительность при добавлении дополнительных модулей, когда приложение становится интенсивным по данным или когда их несколько. требуется пропуск через мост.
Но как работает текущая архитектура?
Архитектура React Native зависит от трех потоков: а) поток пользовательского интерфейса: это основной поток приложения, который используется для рендеринга представлений Android и iOS. б) Теневой поток: это своего рода фоновый поток, который вычисляет расположение элементов (с помощью Yoga ) перед рендерингом на хост-платформе. c) Поток JS: связанный JS, который отвечает за обработку всей логики в вашем родном приложении.

Взаимодействие между этими потоками не является прямым, и каждый раз, когда одному потоку необходимо взаимодействовать с другим потоком, ему приходится выполнять тяжелую задачу сериализации и десериализации данных в JSON, чтобы пройти через мост. Это приводит к ненужному копированию данных, и этот мост может довольно легко переполниться, поскольку операции асинхронны и нет строгой типизации.
Некоторые ограничения текущей архитектуры:
1. Javascript и собственная сторона не знают друг о друге и полагаются на асинхронные сообщения JSON.
2. Все модули загружаются при запуске, что увеличивает время взаимодействия.
3. Нет приоритизации действий. Важные взаимодействия с пользователем не могут иметь приоритет над другими действиями.
4. Мостовая сериализация
. 5. Элементы пользовательского интерфейса недоступны напрямую из потока JS.

Представляем JSI

JSI вносит большие изменения во взаимодействие javascript и нативной части. Он обеспечивает прямую связь между двумя сферами с помощью интерфейса между JS и C++. Используя интерфейс JavaScript, JS может хранить ссылку на хост-объекты и вызывать для них методы. С помощью хост-объекта теперь мы можем использовать нативные объекты в контексте javascript. Мост, который был самым большим узким местом, разделен на части:
Ткань
Новая система рендеринга, созданная Facebook, представляет собой новую архитектуру менеджера пользовательского интерфейса. Этот рендерер реализован на C++, а его ядро используется всеми платформами. В предыдущей реализации создание макета включало несколько шагов, таких как сериализация JSON и переходы через мост, что вызывало серьезные проблемы, когда мост блокировался, например: пропадание кадров при прокрутке бесконечного списка. Новая реализация позволяет UI-менеджеру создавать Shadow Tree непосредственно на C++, что значительно расширяет возможности за счет уменьшения количества переходов между областями. Операции являются синхронными и потокобезопасными, они выполняются из React (JavaScript) в средство визуализации (C++), обычно в потоке JavaScript. Это также требует меньшей сериализации данных, поскольку значения javascript можно напрямую выбирать из JSI. Это прямое управление также помогает приоритизировать действия: средство визуализации теперь может расставлять приоритеты для определенных взаимодействий пользователя, чтобы обеспечить их своевременную обработку. Это значительно улучшит производительность в списках, навигации и обработке жестов.
Турбо модули
В предыдущей реализации у нас не было ссылки на собственные модули, поэтому каждый модуль загружался при запуске, что увеличивает TTI (время до интерактивности), но с турбо-модулями мы можем лениво загружать модули по мере необходимости, что поможет в улучшении времени запуска. Например: если у вас есть модуль для печати документа по ссылке, теперь мы можем загружать этот модуль при переходе на экран печати, а не при запуске приложения, как это делалось в предыдущей архитектуре. Возможность написать модуль на C++ также дает преимущество, поскольку уменьшает количество дублирующихся реализаций на разных платформах.
Кодеген
Чтобы склеить все это вместе и сделать обе сферы совместимыми, команда React Native создала средство проверки типов для автоматизации совместимости между JS и Native. Этот инструмент называется Codegen. Он использует модульный подход, что означает, что любой статически типизированный язык Javascript может поддерживаться с помощью синтаксического анализатора для этой системы. Используя типизированный JavaScript в качестве источника правды, этот генератор может определять файлы интерфейса, необходимые Fabric и TurboModules для уверенной отправки сообщений через области. Codegen также обеспечивает безопасность типа во время компиляции, что означает, что обе среды могут выполнять команды без каких-либо проверок во время выполнения, что означает меньший размер кода для доставки и более быстрое выполнение.
Поскольку теперь у нас есть код C++, а C++ строго типизирован, мы как бы заставляем наш JS-код быть типизированным, потому что мы должны определять типы и не можем писать их где- либо в коде. По сути, он создает для вас интерфейс, и теперь, поскольку они сгенерированы и написаны на C++, теперь мы можем в основном доверять отправляемым данным, и нам не нужно постоянно проверять данные. Это также означает, что с помощью проверки типов мы можем легко выявить проблемы на этапе разработки, которые могли привести к фатальным сбоям или плохому взаимодействию с пользователем.
Некоторые основные преимущества JSI
- Код Javascript может содержать ссылку на любые элементы собственного пользовательского интерфейса и вызывать методы для него (аналогично манипулированию DOM в Интернете).
- Быстрые и прямые привязки к собственному коду, которые могут значительно повысить производительность, например, MMKV использует JSI, который примерно в 30 раз быстрее, чем Asyncstorage.
- Можно использовать другие движки, кроме JavaScript Core.
- Нативные модули могут быть загружены при необходимости.
- Статическая проверка типов для обеспечения совместимости кода JS и Native.
React Native JSI в настоящее время находится в экспериментальной фазе развертывания, и по мере того, как все больше проектов примут это изменение, мы узнаем больше об ограничениях и влиянии новой архитектуры, но одно можно сказать наверняка — будущее React Native и кросс-платформенной разработки приложений. кажется захватывающим.