Где скрывается задержка в React Native: пересечение границ, а не медленный код

В документации по производительности также разделяются FPS потока JavaScript и FPS основного потока интерфейса. Когда поток JavaScript перегружен, он не может оперативно обрабатывать события сенсорного ввода или обновления интерфейса, запускаемые с помощью JavaScript, в то время как взаимодействия, реализованные нативно, такие как прокручивание списка, могут оставаться плавными. Именно это разделение объясняет классическую проблему при отладке: одна часть экрана работает плавно, а другая — замедляется.

Сценарий: передача данных о местоположении в карту

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

Native GPS
    ↓
Bridge
    ↓
JavaScript
    ↓
State Update
    ↓
React Render
    ↓
Bridge
    ↓
Native Map
    ↓
Marker Position Updated

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

Native → JS → Native

Этот процесс продолжается до тех пор, пока экран открыт. Если отобразить множество драйверов одновременно, нагрузка увеличивается во много раз:

Driver 1 position
Driver 2 position
Driver 3 position
Driver 4 position
...
Driver 100 position

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

Сценарий: потоки данных с датчиков

Данные акселерометра и гироскопа следуют тому же принципу. Предположим, что нативный код отправляет:

60 events / second

Каждое событие попадает в JavaScript, обрабатывается и может запустить новое обновление, направленное обратно в нативный интерфейс. В результате формируется поток данных в реальном времени, проходящий через границу между двумя средами:

Sensor
  ↓
Native
  ↓
 JS
  ↓
Calculation
  ↓
React
  ↓
Native UI

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

Очереди, которые растут быстрее, чем опустошаются

Предположим, события поступают каждый

10 ms

но для их эффективной обработки требуется

15 ms

Это уже не просто медленная операция; это накопление задач, которое растёт без ограничений. Поступают новые данные, в то время как старые всё ещё ожидают обработки, поэтому интерфейс всегда отображает прошлые данные. Для реальных временных интерфейсов это худший возможный исход. Пользователю редко нужны все промежуточные значения; ему нужна самая свежая значимая информация. Дизайны, которые объединяют или удаляют устаревшие события, позволяют сохранять очередь небольшой и отображение актуальным.

Интерфейсы с возможностью обмена сообщениями увеличивают количество операций пересечения границ

Этот принцип характерен не только для React Native; инженеры, разрабатывающие распределённые системы, сталкиваются с ним ежедневно. Сравните API модуля, который устанавливает по одному полю за каждый вызов:

await nativeModule.setName(name);
await nativeModule.setEmail(email);
await nativeModule.setAge(age);
await nativeModule.setCountry(country);
await nativeModule.setLanguage(language);

с API, принимающим всю информацию для обновления сразу:

await nativeModule.updateProfile({
  name,
  email,
  age,
  country,
  language,
});

Вторая версия требует гораздо меньшего количества операций пересечения границ для достижения того же результата. Краткое правило звучит так:

Выполняйте больше работы за одну операцию пересечения и делайте её реже.

Этот же принцип применим к:

• HTTP-API,
• запросам к микросервисам,
• доступу к базе данных,
• рабочим потокам,
• межпроцессному взаимодействию,
• мобильным мостам связи,
• распределённым системам в целом.

В сетевых технологиях это называется активным обменом сообщениями. Традиционный мост просто перенёс эту классическую проблему распределённых систем внутрь одного мобильного приложения.

Размер полезной нагрузки — второй фактор

Частота передачи данных — это лишь половина картинки; важен также объём передаваемых данных. Рассмотрим возможность передачи чего-то подобного через границы традиционной архитектуры:

{
  users: [...10000Users]
}

Отправитель должен закодировать структуру данных, а получатель — воссоздать её и обработать. Большие массивы, глубоко вложенные объекты, метаданные изображений, двоичные данные и крупные деревья конфигураций всё это увеличивает нагрузку. Наиболее подверженными этой проблеме являются следующие задачи:

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

В документации по архитектуре React Native приводится крайний, но показательный пример: буферы кадров камеры в реальном времени, объем которых может достигать десятков мегабайт на кадр и огромных объемов в секунду. Постоянная сериализация таких данных через асинхронный мост — это просто неподходящий инструмент.

Почему цепочки обработки кадров делают издержки очевидными

Один кадр может содержать мегабайты пикселей. Теперь представим передачу кадров с

30 FPS

или даже

60 FPS

Если каждый из них должен быть преобразован в формат, подходящий для JavaScript и сериализуемый, и отправлен через асинхронный слой, транспортировка становится узким местом. Необходимо избегать такой ситуации для каждого отдельного кадра:

    Native Camera
         ↓
Huge serialized payload
         ↓
    JavaScript
         ↓
      Process
         ↓
   Serialized result
         ↓
      Native

Именно поэтому библиотеки с высокой производительностью всё чаще размещают тяжелую обработку рядом с нативной памятью и предоставляют JavaScript узкий, эффективный интерфейс. Такой подход приводит к одному из самых значимых изменений в современном React Native.

Как меняется JSI

JSI (JavaScript Interface) позволяет JavaScript взаимодействовать с нативным и C++ кодом гораздо более прямо. В отличие от старого механизма Bridge, который полностью основывался на сериализации и очереди:

JavaScript
     ↓
 Serialize
     ↓
   Bridge
     ↓
Deserialize
     ↓
  Native

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

JavaScript
     ↓
    JSI
     ↓
C++ / Native

Согласно документации React Native, JSI позволяет JavaScript хранить ссылки на объекты C++ и C++ — ссылки на объекты JavaScript, что позволяет вызывать методы без использования модели сериализации Bridge. Концептуально вызов нативного метода начинает напоминать вызов функции в хост-объекте, а не отправку сообщения другому процессу. Это фундаментальное изменение в архитектуре.

Почему JSI не решает проблем с производительностью

Часто возникает следующее неверное понимание:

"JSI устраняет Bridge, поэтому проблемы с производительностью исчезают."

Это не так. Механизм передачи данных становится гораздо лучше, но плохой проектирование системы всё равно приводит к задержкам. Сто тысяч синхронных вызовов через JSI:

100,000 synchronous native calls

Каждый из этих способов может оказаться дешевле вызова Bridge, однако большая часть работы при этом всё равно остается ненужной. То же самое касается передачи огромных объектов снова и снова, выполнения ресурсоемкой логики на потоке JavaScript, блокировки основного потока UI или отрисовки тысяч компонентов, которые на самом деле не требовали отрисовки. Синхронный доступ также создаёт новый риск: медленный синхронный вызов нативного кода теперь блокирует поток JavaScript напрямую, вместо того чтобы обработаться позже.

Следовательно, правильный вывод — это не «Bridge был медленным, а JSI — быстрым». Более точно будет сказано следующее:

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

TurboModules: современная система нативных модулей

TurboModules заменяют устаревшую систему Native Modules. Старые модули были доступны через Bridge; новые интегрируются более тесно с помощью JSI и Codegen, который генерирует типизированные связи на основе спецификации. Среди преимуществ, перечисленных React Native, — следующие:

• синхронный доступ к нативному коду, когда это необходимо в конкретном случае использования,
• типобезопасность на всем протяжении границы взаимодействия,
• возможность совместной работы с C++,
• возможность общего использования кода на разных платформах,
• задержанная загрузка модулей.

Задержанная загрузка заслуживает особого внимания. В старой модели инициализация нативных модулей во время запуска могла привести к дополнительной работе до появления первого экрана. С задержанной загрузкой модуль инициализируется только тогда, когда он впервые используется. Вместо того чтобы:

Application starts
        ↓
Initialize everything
        ↓
Eventually show UI

запуск может выглядеть более так:

    Application starts
              ↓
Initialize required components
              ↓
           Show UI
              ↓
Load additional modules when needed

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

Fabric: часть редизайна, отвечающая за отрисовку

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

• синхронный доступ к макету там, где это необходимо,
• лучшую взаимосовместимость,
• несколько уровней приоритетов обновлений,
• поддержку современных функций React,
• более гибкое планирование.

Приоритеты важны, потому что интерфейсы не обрабатывают каждое обновление одинаково:

User presses button        → HIGH priority
Background data refresh    → LOWER priority
Analytics event            → LOW priority
Animation                  → HIGH priority
Prefetching                → LOW priority

Качественный рендерер не должен считать нажатие кнопки и отправку данных в систему аналитики одинаково срочными. Приоритизация является основой адаптивного интерфейса, и именно Fabric позволяет React Native использовать модель планирования React. Если вы хотите узнать, как сам React кодирует приоритет обновлений, статья о том, как React использует маски битов для кодирования приоритета объясняет этот механизм.

Настоящим врагом является постоянная смена границ

Если весь проблемный феномен нужно свести к двум словам, это будет постоянная смена границ: многократная передача небольших фрагментов информации туда-сюда между средами выполнения.

  JS
  ↓
Native
  ↓
  JS
  ↓
Native
  ↓
  JS
  ↓
Native

Когда вы видите такую структуру, это обычно означает, что ответственность за ту или иную функцию разделена не в том месте. Необходимо спросить себя, где на самом деле должна находиться эта работа. Возьмем обработку аудио. Дизайн с высоким уровнем нагрузки выглядит так:

Native microphone
→ JS audio frame
→ calculate
→ native
→ next frame
→ JS
→ calculate
→ native

Лучший вариант разделения заключается в том, чтобы обработка высокочастотных сигналов выполнялась нативно, а в JavaScript передавались только те результаты, которые требуют дальнейших действий:

Native microphone
        ↓
Native processing
        ↓
Native processing
        ↓
Native processing
        ↓
Meaningful result
        ↓
    JavaScript

Объем вычислений может быть примерно одинаковым, но паттерн взаимодействия совершенно разный, как и нагрузка на оба потока.

Практические методы для снижения нагрузки

Группировка операций в один вызов

Цикл, который ожидает нативный вызов для каждого элемента, является распространенной причиной высокой нагрузки:

for (const item of items) {
  await NativeModule.saveItem(item);
}

При наличии 500 элементов возникает потенциально сотни отдельных операций пересечения, каждая из которых сопряжена с дополнительными затратами на планирование. Лучший нативный API принимает всю коллекцию целиком и позволяет нативному коду выполнять итерацию:

await NativeModule.saveItems(items);

Различия в структуре легко описать:

❌ 500 boundary crossings × small operation

✅ 1 boundary crossing × 500 native operations

Группировка операций является одной из самых простых и эффективных архитектурных оптимизаций. Один из аспектов дизайна, который необходимо учесть: при групповом вызове требуется четкое описание возможных ошибок, например информация о том, какие элементы не обработались, чтобы один неисправный элемент не привел к безвозвратной потере остальных.

Ограничение частоты или объединение высокочастотных событий

Предположим, что нативный модуль генерирует 120 обновлений в секунду. JavaScript редко нуждается во всех из них. Для многих интерфейсов примерно 20 значимых обновлений в секунду выглядят практически одинаково на экране. Вместо того чтобы обрабатывать

120 events / second

вы можете обработать

20 events / second

или накапливать события на уровне операционной системы и передавать только самое последнее состояние. Реализация ограничения скорости непосредственно на уровне операционной системы обычно лучше, чем в JavaScript, поскольку события, обработанные в JavaScript, уже понесли затраты на передачу. Такой подход подходит для:

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

Самым дешевым событием является то, которое никогда не отправляется.

Передавайте смысл, а не сырые данные

Вместо того чтобы передавать что-то вроде

10 MB raw dataset

от уровня операционной системы в JavaScript и просить JavaScript вычислить ответ, вычисляйте ответ там, где уже находятся данные. Замените этот поток:

Native
  ↓
10 MB data
  ↓
JavaScript
  ↓
find average

на этот:

        Native
          ↓
  calculate average
          ↓
JavaScript receives: 42.7

Короче говоря, передавайте

meaning

вместо того чтобы

raw information

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

Задержка в сети — это не задержка взаимодействия

Быстрый бэкенд может скрыть медленную работу. Предположим, API отвечает за

120 ms

и панель мониторинга показывает зеленый цвет. Однако после получения ответа ещё многое должно произойти:

API Response
    ↓
JSON Parsing
    ↓
State Transformation
    ↓
Redux / Zustand / Context
    ↓
Component Re-rendering
    ↓
JS ↔ Native interaction
    ↓
Layout
    ↓
UI Commit

К тому моменту, когда результат появляется на экране, пользователь уже мог подождать

200+ ms

Отчеты о мониторинге бэкенда показывают, что все работает быстро; пользователи жалуются на медленную работу приложения. Обе стороны говорят правду, поскольку они измеряют разные вещи. Задержка бэкенда и задержка взаимодействия — это разные показатели, и для мобильных приложений именно второй фактор обычно определяет, насколько удобен продукт.

Тестируйте на устройствах, которые действительно используют ваши пользователи

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

small inefficiency × thousands of operations

проблемы вдруг становятся заметными. Тестирование только на премиум-устройствах сопряжено с рисками. Надежная матрица тестирования должна включать по меньшей мере:

High-end device
Mid-range device
Lower-end supported device

Это особенно важно, когда ваша аудитория включает рынки, где большая доля пользователей пользуется доступными Android-телефонами.

Измеряйте версии для выпуска, а не версии разработки

Версии разработки выполняют дополнительные операции для отображения предупреждений, отладки и работы с инструментами, и официальное руководство по производительности прямо рекомендует использовать версии для выпуска при измерениях. Прежде чем делать вывод о медленной работе самого React Native, проведите профилирование

Release / Production build

вместо того чтобы полагаться только на

Development build

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

Чек-лист для диагностики медленного отображения экрана

Использование функции useMemo() в коде с медленной работой редко является правильным первым шагом. Вместо этого рассмотрите следующие вопросы.

1. Занят ли поток JavaScript?

Ищите:

• дорогостоящие циклы,