Де ховається затримка у React Native: перетини меж, а не повільний код

У документації щодо продуктивності також розділяють FPS потоку JavaScript та FPS основного потоку інтерфейсу. Коли потік JavaScript перевантажений, він не може швидко обробляти події дотику чи оновлення інтерфейсу, здійснені за допомогою JavaScript, тоді як взаємодії, які виконуються нативно, наприклад прокручування списку, можуть залишатися плавними. Саме це розділення пояснює класичну проблему під час дебаггінгу: одна частина екрана виглядає плавною, тоді як інша — застиглою.

Сценарій: передача координат у карту

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);

з тим, який приймає всі зміни одночасно:

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

Друга версія потребує значно меншої кількості перетинів меж для досягнення того ж результату. Основне правило просте:

Виконуйте більше роботи за кожен перетин та робіть його рідше.

Цей самий принцип застосовується до:

• HTTP API,
• викликів мікросервісів,
• доступу до баз даних,
• робочих потоків,
• міжпроцесного обміну даними,
• мобільних мостів,
• розподілених систем в цілому.

У мережевих технологіях це називається активною комунікацією. Стара версія Bridge просто перенесла цю класичну проблему розподілених систем у межі одного мобільного додатку.

Розмір вантажу — це другий фактор

Частота передачі даних — це лише половина проблеми; важливим є також обсяг даних, які передаються. Розгляньмо можливість передачі чогось подібного через межі старої версії:

{
  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++ кодом значно пряміше. Замість того, щоб повністю покладатися на процес серіалізації та чергування у старому мосту:

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

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

Тестування на пристроях, які насправді мають ваші користувачі

Проблеми з продуктивністю люблять ховатися на обладнанні розробників. Флагманський телефон має швидкий процесор, достатню кількість пам’яті, швидке зберігання, потужну GPU та гарну систему охолодження, тож усе виглядає нормально. Користувачі у реальних умовах запускають ту саму версію додатку на пристроях із значно меншими ресурсами, і

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?

Шукайте:

• дорогі цикли,