Nowa Architektura React Native w 2026: Hermes V1, Tryb Bridgeless i Pytania Rekrutacyjne

Nowa Architektura React Native osiągnęła pełną dojrzałość w 2026 roku. React Native 0.84 wprowadził Hermes V1 jako domyślny silnik JavaScript, a wersja 0.85 usunęła ostatnie ślady starego bridge'a. Framework zapewnia teraz wydajność zbliżoną do natywnej bez konieczności konfigurowania flag architektonicznych czy warstw kompatybilności.

Co się zmieniło w stosie architektonicznym React Native

Stara architektura React Native opierała się na jednowątkowym, asynchronicznym bridge'u JSON, który przekazywał wiadomości między JavaScriptem a kodem natywnym. Każda interakcja przechodziła przez to wąskie gardło: zdarzenia dotykowe, obliczenia layoutu, wywołania modułów. Nowa Architektura zastępuje każdą warstwę tego potoku bezpośrednim, synchronicznym odpowiednikiem.

| Warstwa | Stara Architektura | Nowa Architektura | |---------|-------------------|-------------------| | Silnik JS | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderer | Paper (asynchroniczny bridge) | Fabric (synchroniczny, współdzielony C++) | | Moduły natywne | Bridge Modules (serializacja JSON) | TurboModules (JSI, bezpośrednie wywołania) | | Komunikacja | Asynchroniczny bridge JSON | JSI (JavaScript Interface) | | Inicjalizacja | Inicjalizacja bridge'a + rejestracja modułów | Bridgeless (leniwa, na żądanie) |

JSI (JavaScript Interface) stanowi fundament. Zamiast serializować każde wywołanie do JSON i przekazywać je przez kolejkę, JSI udostępnia obiekty hosta C++ bezpośrednio w JavaScript. Wywołanie TurboModule, które wcześniej wymagało kodowania JSON, kolejkowania w bridge'u i dekodowania JSON, jest teraz realizowane jako bezpośrednia inwokacja funkcji.

Hermes V1: domyślny silnik JavaScript

Hermes V1 stał się domyślnym silnikiem w React Native 0.84, wydanym w lutym 2026 roku. To pełne przepisanie kompilatora i maszyny wirtualnej, a nie jedynie przyrostowa aktualizacja poprzednich wersji Hermes.

Ulepszenia obejmują cztery obszary: przepisany kompilator z nowym formatem bytecode'u, ulepszony kompilator JIT, współbieżny garbage collector Hades oraz lepszą obsługę nowoczesnych wzorców JavaScript używanych przez 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, współbieżny garbage collector, zasługuje na szczególną uwagę. Poprzednie wersje Hermes używały GC typu stop-the-world, który od czasu do czasu powodował widoczne przycięcia podczas przewijania list. Hades wykonuje zbieranie współbieżnie w wątku w tle, utrzymując pauzy GC poniżej 12 ms. W aplikacjach renderujących długie listy ze złożonymi komórkami eliminuje to ostatnie źródło spadków klatek po stronie JavaScriptu.

Renderer Fabric: synchroniczny layout i renderowanie

Fabric zastępuje renderer Paper rdzeniem napisanym w C++, współdzielonym między iOS a Androidem. Kluczowa różnica: obliczenia layoutu odbywają się synchronicznie w wątku JavaScript, a nie asynchronicznie przez bridge.

Ten synchroniczny model umożliwia dwie funkcjonalności, które były niemożliwe z Paper:

1. Obsługa renderowania współbieżnego: Fabric integruje się z funkcjami współbieżnymi React 19. Transitions, granice Suspense i useTransition działają poprawnie, ponieważ Fabric może przerywać i wznawiać renderowanie.

2. Bezpośredni layout C++: Yoga (silnik layoutu) działa w tej samej przestrzeni pamięci co runtime JavaScript. Brak narzutu serializacji dla obliczeń 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' },
})

Hook useTransition w tym przykładzie pokazuje, dlaczego Fabric ma znaczenie. W przypadku Paper startTransition nie miał żadnego efektu, ponieważ renderer nie mógł przerwać trwającego renderowania. Integracja Fabric z trybem współbieżnym React 19 sprawia, że odroczone aktualizacje działają zgodnie z zamierzeniem, utrzymując responsywność pola tekstowego podczas filtrowania tysięcy elementów w tle.

TurboModules i JSI: eliminacja narzutu serializacji

TurboModules zastępują stary system NativeModules. Różnica wydajnościowa wynika z całkowitej eliminacji serializacji JSON. Wywołanie modułu bridge'a przebiegało następująco: obiekt JS -> JSON.stringify -> kolejka bridge'a -> JSON.parse -> wywołanie natywne -> JSON.stringify -> kolejka bridge'a -> JSON.parse -> callback JS. Wywołanie TurboModule to bezpośrednia inwokacja funkcji C++ przez 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"
}

Kluczowy szczegół: getDeviceModel(), getOSVersion() i getBatteryLevel() są synchroniczne. Wątek JavaScript wywołuje bezpośrednio kod natywny i otrzymuje wartość zwrotną w tym samym tiku. Bez promisów, bez callbacków, bez okrążenia bridge'a. Jest to możliwe wyłącznie dzięki JSI.

Tryb Bridgeless: co usuwa i dlaczego ma znaczenie

Tryb Bridgeless, wprowadzony w React Native 0.73 i ustawiony jako domyślny w 0.74, kończy migrację architektury, usuwając inicjalizację bridge'a całkowicie. Nawet po przyjęciu Fabric i TurboModules stary bridge wciąż inicjalizował się podczas uruchomienia, aby obsługiwać globalne emittery zdarzeń, timery i obsługę błędów. Tryb Bridgeless przenosi te pozostałe systemy na implementacje oparte na JSI.

Praktyczny wpływ:

• Szybsze uruchamianie: Brak narzutu inicjalizacji bridge'a. Runtime uruchamia się tylko z tym, czego aplikacja faktycznie używa, dzięki leniwemu ładowaniu.
• Mniejsze zużycie pamięci: Brak alokacji struktur danych bridge'a przy uruchomieniu.
• Czystsza obsługa błędów: Error boundaries i globalne handlery błędów działają przez nową architekturę bez fallbacków bridge'a.

React Native 0.82 trwale wyłączył stary bridge. React Native 0.85, wydany w kwietniu 2026, usunął cały pozostały kod związany z bridge'em z bazy kodu. Nie ma ścieżki powrotnej.

Migracja produkcyjna: benchmarki wydajnościowe

Migracje produkcyjne ze starej architektury na Nową Architekturę pokazują spójne ulepszenia w kluczowych metrykach:

| Metryka | Stara Architektura | Nowa Architektura | Poprawa | |---------|-------------------|-------------------|----------| | Zimny start (TTI) | 1,4 s | 0,8 s | 43% szybciej | | Przejście ekranu | 180 ms | 110 ms | 39% szybciej | | Bazowe zużycie pamięci | 89 MB | 66 MB | 26% mniej | | Wywołanie JS-do-natywne | ~5 ms (async) | ~0,1 ms (sync) | 40x szybciej | | Maks. pauza GC | 45 ms | 12 ms | 73% krótsza | | Scroll FlatList (1000 el.) | Sporadyczne przycięcia | Płynne 60 fps | Bez zgubionych klatek |

Najbardziej odczuwalną poprawą dla użytkownika końcowego jest redukcja pauz GC. Hades utrzymuje pauzy zbierania poniżej budżetu jednej klatki (16,6 ms przy 60 fps), eliminując najczęstszą przyczynę widocznych przycięć w złożonych aplikacjach React Native.

Kompatybilność ekosystemu w 2026 roku

Ekosystem w pełni skonwergował w kierunku Nowej Architektury. Expo SDK 55 i nowsze działają wyłącznie na Nowej Architekturze, bez opcji jej wyłączenia. Kompatybilność kluczowych bibliotek:

• React Navigation 7.2+: Pełne wsparcie Fabric z ekranami native-stack
• Reanimated 3.5+: Współdzielony backend animacji z React Native 0.85
• Gesture Handler 2.16+: Rozpoznawanie gestów oparte na JSI
• Vision Camera 4.0+: Przetwarzanie klatek przez JSI
• Detox: Testy E2E kompatybilne z Nową Architekturą

Dla zespołów korzystających z Expo, npx create-expo-app generuje projekt z Nową Architekturą włączoną domyślnie. Konfiguracja nie jest potrzebna.

Pytania rekrutacyjne: Nowa Architektura React Native

Poniższe pytania regularnie pojawiają się na rozmowach kwalifikacyjnych na stanowiska senior React Native w 2026 roku. Każda odpowiedź obejmuje głębię oczekiwaną na poziomie staff/senior.

P1: Wyjaśnij różnicę między starym Bridge'em a JSI. Dlaczego JSI umożliwia synchroniczne wywołania natywne?

Bridge serializował każdą wiadomość JS-do-natywne jako JSON, umieszczał ją w asynchronicznej kolejce i deserializował po stronie natywnej. JSI (JavaScript Interface) udostępnia obiekty hosta C++ bezpośrednio w maszynie wirtualnej JavaScript. Funkcje natywne zarejestrowane przez JSI pojawiają się jako zwykłe funkcje JavaScript, które wykonują kod natywny inline, bez serializacji czy kolejkowania. Wywołania synchroniczne są możliwe, ponieważ JSI działa w tym samym kontekście wątkowym bez pośredniej kolejki wiadomości.

P2: Jaki problem rozwiązuje renderer Fabric, którego Paper nie mógł rozwiązać?

Paper renderował asynchronicznie przez bridge, co uniemożliwiało obsługę współbieżnych funkcji React. Wywołanie startTransition nie miało efektu, ponieważ Paper nie mógł przerwać renderowania drzewa w trakcie pracy. Fabric implementuje renderowanie we współdzielonym kodzie C++, integruje się bezpośrednio z reconcilerem React 19 i obsługuje renderowanie współbieżne, Suspense oraz transitions. Obliczenia layoutu przez Yoga również odbywają się synchronicznie w tej samej przestrzeni pamięci, eliminując opóźnienia layoutu przez bridge.

P3: Dlaczego Hermes jest wymagany dla Nowej Architektury? Czy można użyć innego silnika?

Nowa Architektura zależy od JSI, który wymaga, aby silnik JavaScript obsługiwał rejestrację obiektów hosta C++. Hermes został zaprojektowany od podstaw z integracją JSI. JavaScriptCore mógłby teoretycznie obsługiwać JSI, ale oficjalna implementacja i testy są zbudowane wokół Hermes. Hermes V1 dodatkowo oferuje prekompilację bytecode'u (eliminującą parsowanie w runtime), współbieżny GC Hades (pauzy poniżej 12 ms) oraz obsługę WebAssembly, których brak w integracji React Native z JSC.

P4: Czym TurboModules różnią się od starego API NativeModules z perspektywy programisty?

TurboModules wymagają specyfikacji Codegen (interfejsu TypeScript rozszerzającego TurboModule), która generuje typobezpieczne bindingi natywne w czasie budowania. Stare NativeModules używały refleksji runtime bez sprawdzania typów. TurboModules obsługują synchroniczne wartości zwrotne (nie tylko promise), leniwą inicjalizację (moduły ładują się dopiero przy pierwszym dostępie) oraz bezpośrednie wywołania JSI bez serializacji JSON. Programista pisze specyfikację TypeScript, uruchamia Codegen i implementuje wygenerowany interfejs natywny.

P5: Opisz Tryb Bridgeless i co usuwa w porównaniu z samym Fabric i TurboModules.

Nawet po przyjęciu Fabric i TurboModules stary bridge wciąż inicjalizował się przy uruchomieniu, aby obsługiwać globalne emittery zdarzeń, timery, obsługę błędów i inną infrastrukturę runtime. Tryb Bridgeless zastępuje te pozostałe systemy zależne od bridge'a implementacjami opartymi na JSI. Eliminuje narzut inicjalizacji bridge'a, zmniejsza bazowe zużycie pamięci i zapewnia, że cały runtime działa przez JSI. Od React Native 0.85 tryb Bridgeless jest jedynym trybem operacyjnym.

Przećwiczenie tych pytań z działającymi przykładami kodu wzmacnia zarówno zrozumienie koncepcyjne, jak i praktyczne zapamiętywanie. Moduł Nowa Architektura React Native na SharpSkill obejmuje ponad 40 dodatkowych pytań dotyczących Fabric, TurboModules, mechanizmów wewnętrznych Hermes i strategii migracji.

Podsumowanie

• Hermes V1 zapewnia 29% szybsze zimne starty, 38% mniejsze zużycie pamięci i pauzy GC poniżej 12 ms od razu po wyjęciu z pudełka w React Native 0.84+
• Fabric umożliwia współbieżne funkcje React 19 (transitions, Suspense), których Paper nigdy nie mógł obsługiwać
• TurboModules eliminują serializację JSON, przyspieszając wywołania JS-do-natywne 40-krotnie dzięki bezpośredniej inwokacji JSI
• Tryb Bridgeless usuwa ostatnie zależności bridge'a; React Native 0.85 nie zawiera żadnego kodu bridge'a
• Ekosystem jest w pełni kompatybilny: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ i wszystkie główne biblioteki obsługują wyłącznie Nową Architekturę
• Przygotowanie do rozmów rekrutacyjnych powinno koncentrować się na mechanice JSI, porównaniu Fabric vs Paper, workflow Codegen TurboModules i zmianach runtime Trybu Bridgeless