Як влаштований React Native «під капотом»

Навіщо ця стаття

У попередньому матеріалі йшлося про задачу: навіщо існує React Native і чим мобільний застосунок відрізняється від сайту. Тут — наступний крок: як загалом влаштоване середовище, у якому цей код живе.

Мета не в тому, щоб запам’ятати десяток внутрішніх назв з документації. Мета — отримати робочу картину в голові:

• хто виконує JavaScript;
• хто малює кнопки й тексти на екрані;
• як натискання пальцем доходить до обробника в коді;
• що робить програма-збирач під час розробки;
• чому інколи кажуть про «старий» і «новий» способи зв’язку між JavaScript і системою телефону.

Усе складне спочатку пояснюється звичайними словами. Технічні назви з’являються після інтуїції. Глибокі деталі сучасної внутрішньої перебудови React Native (окремі шари з довгими англійськими іменами) у цій статті лише окреслені; повний розбір буде в пізнішому матеріалі курсу.

Спочатку згадаємо браузер

У вебі ланцюжок знайомий.

Важливий висновок: React і середовище малювання — різні ролі. React відповідає за логіку «що показати при якому стані». Середовище (браузер) відповідає за «як це виглядає на екрані насправді».

Та сама ідея в React Native

У React Native ролі подібні, але середовище інше.

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

package "Браузер" #f5f5f5 {
  rectangle "React:\nопис UI" as R1 #e3f2fd
  rectangle "Браузер:\nDOM + малювання" as B1 #fff3e0
  R1 --> B1
}

package "React Native" #f5f5f5 {
  rectangle "React:\nопис UI" as R2 #e3f2fd
  rectangle "React Native:\nзв'язок" as M #f3e5f5
  rectangle "ОС телефону:\nкнопки, тексти, списки" as OS #e8f5e9
  R2 --> M
  M --> OS
}

@enduml

Дві «служби» всередині застосунку: логіка й малювання

Щоб розуміти, чому інколи інтерфейс «гальмує», а логіка — ні (або навпаки), зручно уявити дві служби, які працюють поруч.

У розмовній інженерній мові ці служби часто називають потоками (threads — «нитки» виконання всередині програми). Для курсу на старті достатньо формулювань:

• потік JavaScript (або «потік логіки») — місце, де крутиться JS-код;
• потік інтерфейсу (або «UI-потік») — місце, тісно пов’язане з малюванням екрана операційною системою.

Чому це важливо вже зараз, ще до написання складного коду:

• довга синхронна робота в обробнику натискання може «підвісити» відчуття відгуку;
• важкі списки й зображення навантажують і логіку, і малювання — цим займуться окремі статті про списки й продуктивність;
• анімації, які мають бути дуже плавними, інколи свідомо переносять ближче до малювання (окрема тема жестів і анімацій).

Повну модель з усіма допоміжними потоками й сучасними змінами не потрібно тримати в голові після цієї статті. Достатньо: логіка й малювання — різні обов’язки, і між ними є зв’язок.

Зв’язок між JavaScript і «телефонною» частиною

JavaScript у React Native не є мовою, якою операційна система напряму малює кожну кнопку «з нуля» у стилі HTML. Потрібен посередник: домовитися, що «компонент тексту в React» відповідає «системному тексту на iOS/Android», що натискання треба передати в JS-обробник, що зміна стану має оновити підписи на екрані.

Старіший спосіб: черга повідомлень

Довгий час у React Native переважала модель, яку зручно уявити як чергу листів між двома кабінетами.

1. Кабінет JavaScript пише: «покажи текст “Зберегти”».
2. Лист кладуть у чергу.
3. Кабінет нативної (системної) частини читає лист і малює системний елемент.
4. Користувач натискає.
5. Нативна частина кладе у зворотну чергу лист: «було натискання».
6. JavaScript читає лист і викликає функцію-обробник.

Такий асинхронний обмін (не все відбувається в одному миттєвому «дзвінку») історично називали мостом (bridge — міст між світами).

Новіший напрям: тісніший зв’язок

З часом екосистема пішла до моделі, де JavaScript і нативна частина можуть спілкуватися без такої товстої черги листів — швидше й передбачуваніше для складних жестів і оновлень інтерфейсу. У документації це часто збирають під загальною назвою нова архітектура (New Architecture).

Усередині цієї «нової архітектури» є кілька частин з окремими іменами (новий спосіб малювати дерево інтерфейсу, новий спосіб підключати модулі телефону тощо). На цьому етапі курсу їхні абревіатури запам’ятовувати не обов’язково. Достатньо знати:

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

rectangle "JavaScript\n(логіка екранів)" as JS #e3f2fd

package "Шар зв'язку React Native" #fff8e1 {
  rectangle "Раніше: черга\nповідомлень (міст)" as OLD #ffcdd2
  rectangle "Сучасний напрям:\nтісніший зв'язок" as NEW #c8e6c9
}

rectangle "Системна частина\n(малювання, камера,\nфайли, …)" as NAT #e8f5e9

JS --> OLD
JS --> NEW
OLD --> NAT
NEW --> NAT

@enduml

Що відбувається після натискання кнопки

Розглянемо життєвий сценарій. На екрані є кнопка «Додати поїздку». Користувач торкається її. У коді (ще схематично) передбачено обробник на кшталт «викликати функцію при натисканні».

Нижче — спрощена послідовність. Реальний рушій має більше кроків і оптимізацій; для навчання важливий порядок думок.

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

actor "Користувач" as U
rectangle "ОС телефону\n(дотик, малювання)" as OS #e8f5e9
rectangle "Шар React Native" as RN #fff3e0
rectangle "JavaScript\n(обробник, стан, React)" as JS #e3f2fd

U -> OS : дотик до кнопки
OS -> RN : подія натискання
RN -> JS : передати в обробник
JS -> JS : оновити стан\nперерахувати UI
JS -> RN : потрібні зміни на екрані
RN -> OS : оновити системні елементи
OS -> U : новий вигляд екрана

@enduml

Хто виконує JavaScript: рушій

JavaScript потрібен рушій (engine) — програма всередині застосунку, яка розуміє мову JS і виконує її.

У браузері рушії свої (наприклад, у Chrome — один відомий рушій, у Safari — інший). У React Native на мобільних пристроях сьогодні зазвичай використовують Hermes — рушій, орієнтований саме на мобільні сценарії.

Порівняння з вебом:

Хто збирає код під час розробки: Metro

Поки пишуть код, потрібен інструмент, який:

• знаходить імпорти (import … from '…');
• перетворює TypeScript на вигляд, зрозумілий рушію;
• швидко віддає оновлення після збереження файлу.

У React Native цю роль зазвичай виконує Metro.

@startuml
skinparam style plain
skinparam backgroundColor #ffffff

rectangle "Файли проєкту\n.ts / .tsx" as SRC #e3f2fd
rectangle "Metro\n(збирає модулі)" as METRO #fff3e0
rectangle "Бандл JS\nдля застосунку" as BUNDLE #f3e5f5
rectangle "Застосунок на телефоні\n(Hermes виконує JS)" as APP #e8f5e9

SRC --> METRO
METRO --> BUNDLE
BUNDLE --> APP

@enduml

Два режими: розробка і «як у користувача»

Під час навчання легко змішати два світи.

Модулі можливостей телефону

Окремий шар — доступ до камери, файлів, сповіщень, геолокації. У JavaScript ці речі не з’являються «самі»; їх надають модулі, які з одного боку мають JS-API для розробника, з іншого — вміють викликати системні функції iOS/Android.

На рівні архітектури зараз важливо лише: екран (UI) і можливості пристрою — сусідні, але різні двері з боку JavaScript. Обидві двері проходять через шар React Native / модулів, а не через DOM браузера.

Зв’язок із веб-React: що переноситься, а що ні

Міні-проєкт: трасування натискання кнопки

Завдання

Код писати не обов’язково. Потрібен короткий текст (половина–одна сторінка), у якому простежується шлях події.

Сценарій. У майбутньому застосунку Nomad на екрані списку поїздок є кнопка «Нова поїздка». Користувач натискає її. У результаті відкривається екран форми створення поїздки (поки що можна уявити це як «змінився поточний екран» без деталей бібліотеки навігації).

Що має бути в тексті

Критерій «готово»

Текст може зрозуміти колега, який читав лише попередню статтю курсу. Якщо з’являється термін на кшталт «міст» або «Metro» — поруч є пояснення одним реченням.

Nomad: що з цього випливає вже зараз

Коду Nomad у цій статті ще немає. Але архітектурна картина вже накладається на продукт.

Окремий git-коміт у застосунок на цьому кроці не потрібен. Достатньо зберегти текст міні-проєкту поруч із майбутніми нотатками продукту (коли з’явиться Nomad — можна покласти в docs/).

Підсумок

Наступна стаття порівняє Expo і класичний проєкт React Native (CLI) уже не одним абзацом, а як два практичні шляхи роботи з тією самою архітектурою, яку щойно розглянуто.

Практичні завдання

Базовий рівень

1. Пояснити своїми словами різницю між службою логіки і службою малювання.
2. Назвати роль Metro і роль Hermes (по одному реченню на кожну).
3. Відповісти: чи малює React Native інтерфейс через HTML DOM у звичайному мобільному сценарії?

Середній рівень

1. Виконати міні-проєкт (повне трасування натискання).
2. Описати, що зміниться в трасуванні, якщо після натискання кнопки не змінюється екран, а лише текст на тій самій кнопці («Зберегти» → «Збережено»).
3. Навести приклад важкої роботи, яку не варто синхронно виконувати прямо в обробнику натискання, і коротко чому.

Професійний рівень

1. Порівняти (пів сторінки) модель «React → браузер» і «React → React Native → ОС» для колеги, який знає лише веб.
2. Сформулювати три запитання, які варто поставити, якщо користувач каже: «Застосунок гальмує».
3. Коротко пояснити, навіщо екосистемі був потрібен перехід від «черги листів» до тіснішого зв’язку — без переліку внутрішніх абревіатур.

Часті запитання