Hur fungerar React Natives arkitektur (bridge vs ny arkitektur)?

Question

Accepted Answer

React Native kör **JavaScript** och **native**-kod som måste kommunicera. Den ursprungliga arkitekturen använde en asynkron **bridge**; den **nya arkitekturen** (JSI, TurboModules, Fabric) möjliggör snabbare, synkron kommunikation. Att förstå detta klargör React Natives beteende och prestanda.

## Den ursprungliga arkitekturen: bridge

```text
React Native runs:
  → a JS THREAD (your React/JS code) and the NATIVE side (UI, native modules)
  → they communicate over a BRIDGE: messages are SERIALIZED (to JSON), passed ASYNC,
    and deserialized on the other side
Limitations:
  ✗ ASYNCHRONOUS only (can't call native synchronously)
  ✗ SERIALIZATION overhead; the bridge can be a BOTTLENECK with heavy traffic
  ✗ e.g. fast scrolling/animations passing data over the bridge → jank
```

## Den nya arkitekturen (JSI, TurboModules, Fabric)

```text
The NEW ARCHITECTURE replaces the bridge:
  JSI (JavaScript Interface) → JS can call native code DIRECTLY and SYNCHRONOUSLY
    (no serialization bridge) → much faster JS↔native interop
  TURBOMODULES → native modules loaded lazily, via JSI (faster, on-demand)
  FABRIC → the new rendering system → better, more efficient UI rendering; sync layout
  CODEGEN → type-safe JS↔native interfaces
→ Result: better performance, less overhead, synchronous calls, smoother UI.
```

## Varför det är viktigt (praktiskt)

```text
→ Explains React Native's PERFORMANCE characteristics (why bridge traffic was costly)
→ The new architecture (default in recent RN) improves performance and interop
→ Informs optimization (minimize bridge crossings on the old architecture; native-thread
  animations) and understanding of how RN executes
```

## Varför det är viktigt

Att förstå React Natives arkitektur är värdefull kunskap på seniornivå eftersom det **förklarar React Natives beteende och prestanda**, vilket fördjupar förmågan att resonera om och optimera appar.

Den grundläggande strukturen — React Native som kör en **JS-tråd** (din kod) och **native-sidan** (UI, native-moduler) som måste **kommunicera** — är nyckeln till att förstå hur React Native fungerar.

Att förstå **den ursprungliga bridge-arkitekturen** (där JS och native kommunicerar via en asynkron bridge som serialiserar meddelanden till JSON och skickar dem över) förklarar React Natives historiska prestanda och begränsningar: kommunikationen var endast asynkron, hade serialiseringsomkostnad, och bridge kunde bli en **flaskhals vid tung trafik** (orsakar skärrat vid snabb scrollning eller animationer som skickar data över) — vilket är **varför minimering av bridge-korsningar och körning av animationer på native-tråden var viktiga optimeringar**, vilket kopplar arkitektur till praktisk prestandaråd.

Att förstå den **nya arkitekturen** (**JSI** som möjliggör direkta, synkrona JS↔native-anrop utan serialiserings-bridge; **TurboModules** för lat inladdning av native-moduler; **Fabric** för bättre rendering; Codegen för typ-säkra gränssnitt) blir allt viktigare eftersom det blir standard — det förbättrar prestanda, reducerar omkostnad, möjliggör synkrona anrop, och ger smidigare UI, vilket representerar React Natives betydande utveckling.

Att förstå denna arkitektur **förklarar React Natives prestanda** (varför bridge var viktig), **informerar optimering** (de metoder som följer från arkitekturen), och klargör hur React Native körs — och transformerar React Native från en svart låda till ett förståeligt system.

Eftersom förståelse av arkitekturen (bridge och den nya JSI-baserade arkitekturen) förklarar React Natives prestandaegenskaper, informerar optimering, och reflekterar medvetenhet om dess viktig utveckling, och eftersom denna djupgång lyfter en från att använda React Native till att förstå det, är förståelse av React Natives arkitektur värdefull kunskap på seniornivå — förklarar dess beteende och prestanda, informerar optimering, och reflekterar den djup och medvetenhet om plattformutveckling som förväntas för seniora React Native-roller.