Нова Архітектура React Native у 2026: Hermes V1, Bridgeless Mode та Питання для Співбесід

Нова Архітектура React Native досягла повної зрілості у 2026 році. React Native 0.84 постачається з Hermes V1 як типовим JavaScript-движком, а версія 0.85 видалила останні залишки старого bridge. Фреймворк тепер забезпечує продуктивність, наближену до нативної, без необхідності налаштовувати архітектурні прапорці чи шари сумісності.

Що змінилося в архітектурному стеку React Native

Стара архітектура React Native спиралася на однопотоковий асинхронний JSON bridge для передачі повідомлень між JavaScript та нативним кодом. Кожна взаємодія проходила через це вузьке місце: події дотику, обчислення розмітки, виклики модулів. Нова Архітектура замінює кожен рівень цього конвеєра прямою синхронною альтернативою.

| Рівень | Стара Архітектура | Нова Архітектура | |--------|-------------------|------------------| | JS-движок | JavaScriptCore | Hermes V1 (байткод + JIT) | | Рендерер | Paper (асинхронний bridge) | Fabric (синхронний, спільний C++) | | Нативні модулі | Bridge Modules (серіалізація JSON) | TurboModules (JSI, прямі виклики) | | Комунікація | Асинхронний JSON Bridge | JSI (JavaScript Interface) | | Ініціалізація | Ініціалізація bridge + реєстрація модулів | Bridgeless (лінива, за запитом) |

JSI (JavaScript Interface) є фундаментом. Замість серіалізації кожного виклику в JSON та передачі через чергу, JSI надає C++ host-об'єкти безпосередньо в JavaScript. Виклик TurboModule, який раніше вимагав кодування JSON, постановки в чергу bridge та декодування JSON, тепер виконується як пряма інвокація функції.

Hermes V1: типовий JavaScript-движок

Hermes V1 став типовим движком у React Native 0.84, випущеному в лютому 2026 року. Це повний перепис компілятора та віртуальної машини, а не просто інкрементальне оновлення попередніх версій Hermes.

Покращення охоплюють чотири напрямки: переписаний компілятор з новим форматом байткоду, вдосконалений JIT-компілятор, конкурентний збирач сміття Hades та покращена підтримка сучасних патернів JavaScript, що використовуються React 19.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

Hades, конкурентний збирач сміття, заслуговує на окрему увагу. Попередні версії Hermes використовували GC типу stop-the-world, який час від часу спричиняв помітні затримки під час прокручування списків. Hades виконує збирання конкурентно у фоновому потоці, утримуючи паузи GC нижче 12 мс. Для застосунків, що рендерять довгі списки зі складними комірками, це усуває останнє джерело пропусків кадрів з боку JavaScript.

Рендерер Fabric: синхронна розмітка та відображення

Fabric замінює рендерер Paper ядром на C++, спільним для iOS та Android. Критична відмінність: обчислення розмітки відбуваються синхронно в потоці JavaScript замість асинхронної передачі через bridge.

Ця синхронна модель забезпечує дві можливості, які були неможливі з Paper:

1. Підтримка конкурентного рендерингу: Fabric інтегрується з конкурентними функціями React 19. Transitions, межі Suspense та useTransition працюють коректно, оскільки Fabric може переривати та відновлювати рендеринг.

2. Пряма розмітка C++: Yoga (движок розмітки) виконується в тому ж просторі пам'яті, що й JavaScript runtime. Без накладних витрат серіалізації для обчислень flexbox.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

Хук useTransition у цьому прикладі демонструє, чому Fabric має значення. З Paper startTransition не давав жодного ефекту, оскільки рендерер не міг перервати поточний рендеринг. Інтеграція Fabric з конкурентним режимом React 19 дозволяє відкладеним оновленням працювати як задумано, зберігаючи чутливість текстового поля під час фільтрації тисяч елементів у фоновому режимі.

TurboModules та JSI: усунення накладних витрат серіалізації

TurboModules замінюють стару систему NativeModules. Різниця у продуктивності полягає в повному усуненні серіалізації JSON. Виклик bridge-модуля відбувався за таким шляхом: JS-об'єкт -> JSON.stringify -> черга bridge -> JSON.parse -> нативний виклик -> JSON.stringify -> черга bridge -> JSON.parse -> JS callback. Виклик TurboModule — це пряма інвокація функції C++ через JSI.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo')

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

Ключова деталь: getDeviceModel(), getOSVersion() та getBatteryLevel() є синхронними. Потік JavaScript викликає нативний код безпосередньо та отримує значення повернення в тому ж тіку. Без promisів, без callbackів, без обходу bridge. Це можливо виключно завдяки JSI.

Bridgeless Mode: що він видаляє та чому це важливо

Bridgeless Mode, представлений у React Native 0.73 та встановлений за замовчуванням у 0.74, завершує міграцію архітектури, повністю видаляючи ініціалізацію bridge. Навіть після впровадження Fabric та TurboModules старий bridge все ще ініціалізувався при запуску для обслуговування глобальних емітерів подій, таймерів та обробки помилок. Bridgeless Mode переносить ці залишкові системи на реалізації на основі JSI.

Практичний вплив:

• Швидший запуск: Без накладних витрат ініціалізації bridge. Runtime завантажує лише те, що застосунок фактично використовує, завдяки лінивому завантаженню.
• Зменшене споживання пам'яті: Без виділення структур даних bridge при запуску.
• Чистіша обробка помилок: Error boundaries та глобальні обробники помилок працюють через нову архітектуру без fallback-ів bridge.

React Native 0.82 остаточно вимкнув старий bridge. React Native 0.85, випущений у квітні 2026, видалив увесь залишковий код bridge з кодової бази. Шляху повернення не існує.

Міграція у продакшні: реальні бенчмарки продуктивності

Продакшн-міграції зі старої архітектури на Нову Архітектуру демонструють стабільні покращення за ключовими метриками:

| Метрика | Стара Архітектура | Нова Архітектура | Покращення | |---------|-------------------|------------------|------------| | Холодний старт (TTI) | 1,4 с | 0,8 с | На 43% швидше | | Перехід між екранами | 180 мс | 110 мс | На 39% швидше | | Базове споживання пам'яті | 89 МБ | 66 МБ | На 26% менше | | Виклик JS-до-нативного | ~5 мс (async) | ~0,1 мс (sync) | У 40 разів швидше | | Макс. пауза GC | 45 мс | 12 мс | На 73% коротша | | Прокрутка FlatList (1000 ел.) | Періодичні затримки | Плавні 60 fps | Без пропущених кадрів |

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

Сумісність екосистеми у 2026 році

Екосистема повністю конвергувала на Нову Архітектуру. Expo SDK 55 та новіші версії працюють виключно на Новій Архітектурі без можливості її вимкнення. Сумісність ключових бібліотек:

• React Navigation 7.2+: Повна підтримка Fabric з native-stack екранами
• Reanimated 3.5+: Спільний бекенд анімацій з React Native 0.85
• Gesture Handler 2.16+: Розпізнавання жестів на основі JSI
• Vision Camera 4.0+: Обробка кадрів через JSI
• Detox: E2E-тестування, сумісне з Новою Архітектурою

Для команд, що використовують Expo, npx create-expo-app створює проєкт з Новою Архітектурою, увімкненою за замовчуванням. Налаштування не потрібне.

Питання для співбесід: Нова Архітектура React Native

Ці питання регулярно з'являються на технічних співбесідах рівня senior React Native у 2026 році. Кожна відповідь охоплює глибину, що очікується на рівні staff/senior.

П1: Поясніть різницю між старим Bridge та JSI. Чому JSI уможливлює синхронні нативні виклики?

Bridge серіалізував кожне повідомлення JS-до-нативного як JSON, поміщав його в асинхронну чергу та десеріалізував на нативному боці. JSI (JavaScript Interface) надає C++ host-об'єкти безпосередньо у віртуальній машині JavaScript. Нативні функції, зареєстровані через JSI, виглядають як звичайні функції JavaScript, які виконують нативний код inline, без серіалізації чи постановки в чергу. Синхронні виклики можливі тому, що JSI працює в тому ж контексті потоку без проміжної черги повідомлень.

П2: Яку проблему вирішує рендерер Fabric, яку Paper не міг вирішити?

Paper рендерив асинхронно через bridge, що унеможливлювало підтримку конкурентних функцій React. Виклик startTransition не давав ефекту, оскільки Paper не міг перервати поточне побудоване дерево рендерингу. Fabric реалізує рендеринг у спільному коді C++, інтегрується безпосередньо з reconciler-ом React 19 та підтримує конкурентний рендеринг, Suspense та transitions. Обчислення розмітки через Yoga також відбуваються синхронно в тому ж просторі пам'яті, усуваючи затримку розмітки через bridge.

П3: Чому Hermes необхідний для Нової Архітектури? Чи можна використати інший движок?

Нова Архітектура залежить від JSI, який вимагає, щоб JavaScript-движок підтримував реєстрацію C++ host-об'єктів. Hermes був розроблений з нуля з інтеграцією JSI. JavaScriptCore теоретично міг би підтримувати JSI, але офіційна реалізація та тестування побудовані навколо Hermes. Hermes V1 додатково надає прекомпіляцію байткоду (усуває парсинг у runtime), конкурентний GC Hades (паузи менше 12 мс) та підтримку WebAssembly — нічого з цього немає в інтеграції React Native з JSC.

П4: Чим TurboModules відрізняються від старого API NativeModules з точки зору розробника?

TurboModules вимагають специфікації Codegen (TypeScript-інтерфейсу, що розширює TurboModule), яка генерує типобезпечні нативні зв'язування під час збирання. Старі NativeModules використовували рефлексію runtime без перевірки типів. TurboModules підтримують синхронні значення повернення (не лише promise), ліниву ініціалізацію (модулі завантажуються лише при першому зверненні) та прямі виклики JSI без серіалізації JSON. Розробник пише TypeScript-специфікацію, запускає Codegen та реалізує згенерований нативний інтерфейс.

П5: Опишіть Bridgeless Mode та що він видаляє порівняно з наявністю лише Fabric та TurboModules.

Навіть після впровадження Fabric та TurboModules старий bridge все ще ініціалізувався при запуску для обслуговування глобальних емітерів подій, таймерів, обробки помилок та іншої runtime-інфраструктури. Bridgeless Mode замінює ці залишкові залежні від bridge системи реалізаціями на основі JSI. Він усуває накладні витрати ініціалізації bridge, зменшує базове споживання пам'яті та гарантує, що весь runtime працює через JSI. Починаючи з React Native 0.85, Bridgeless Mode є єдиним режимом роботи.

Практика цих питань з робочими прикладами коду зміцнює як концептуальне розуміння, так і практичне запам'ятовування. Модуль Нова Архітектура React Native на SharpSkill охоплює понад 40 додаткових питань щодо Fabric, TurboModules, внутрішньої механіки Hermes та стратегій міграції.

Висновок

• Hermes V1 забезпечує на 29% швидший холодний старт, на 38% менше споживання пам'яті та паузи GC менше 12 мс одразу після встановлення у React Native 0.84+
• Fabric уможливлює конкурентні функції React 19 (transitions, Suspense), які Paper ніколи не міг підтримувати
• TurboModules усувають серіалізацію JSON, прискорюючи виклики JS-до-нативного у 40 разів завдяки прямій інвокації JSI
• Bridgeless Mode видаляє останні залежності bridge; у React Native 0.85 не залишилося жодного рядка коду bridge
• Екосистема повністю сумісна: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ та всі основні бібліотеки підтримують виключно Нову Архітектуру
• Підготовка до співбесід має фокусуватися на механіці JSI, порівнянні Fabric та Paper, робочому процесі Codegen TurboModules та змінах runtime у Bridgeless Mode