React Native New Architecture คู่มือฉบับสมบูรณ์ 2026: Hermes V1, Fabric, TurboModules และ Bridgeless Mode

React Native New Architecture ถือเป็นการปฏิวัติครั้งสำคัญในการพัฒนาแอปพลิเคชันมือถือแบบ Cross-platform ในปี 2026 การเปลี่ยนแปลงครั้งนี้ไม่ใช่เพียงการอัปเดตเล็กน้อย แต่เป็นการออกแบบสถาปัตยกรรมใหม่ทั้งหมดตั้งแต่ระดับ JavaScript Engine จนถึงการสื่อสารกับ Native Platform ผลลัพธ์ที่ได้คือประสิทธิภาพที่เทียบเคียงกับแอป Native ได้อย่างแท้จริง พร้อมประสบการณ์การพัฒนาที่ดีขึ้นอย่างมาก บทความนี้จะพานักพัฒนาไปสำรวจทุกองค์ประกอบของสถาปัตยกรรมใหม่ พร้อมตัวอย่างโค้ดที่นำไปใช้งานได้จริง

ภาพรวมสถาปัตยกรรมใหม่ของ React Native

การทำความเข้าใจความแตกต่างระหว่างสถาปัตยกรรมเก่าและใหม่เป็นพื้นฐานสำคัญ ตารางด้านล่างแสดงให้เห็นการเปลี่ยนแปลงในแต่ละ Layer อย่างชัดเจน

| Layer | สถาปัตยกรรมเดิม | สถาปัตยกรรมใหม่ | |-------|-----------------|------------------| | JS Engine | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderer | Paper (async bridge) | Fabric (synchronous, shared C++) | | Native Modules | Bridge Modules (JSON serialization) | TurboModules (JSI, direct calls) | | Communication | Async JSON Bridge | JSI (JavaScript Interface) | | Initialization | Bridge init + module registration | Bridgeless (lazy, on-demand) |

สถาปัตยกรรมเดิมมีข้อจำกัดหลักคือการพึ่งพา Bridge ที่ทำงานแบบ Asynchronous ทุกการสื่อสารระหว่าง JavaScript และ Native จะต้องผ่านการแปลงเป็น JSON และส่งผ่าน Queue ซึ่งสร้างความล่าช้าและใช้หน่วยความจำมาก สถาปัตยกรรมใหม่แก้ปัญหานี้ด้วย JSI (JavaScript Interface) ที่ช่วยให้ JavaScript เรียกใช้โค้ด C++ ได้โดยตรง

Hermes V1: JavaScript Engine รุ่นใหม่

Hermes V1 เป็น JavaScript Engine ที่ Meta พัฒนาขึ้นเฉพาะสำหรับ React Native โดยมีเป้าหมายเพื่อลดเวลา Cold Start และการใช้หน่วยความจำ คุณสมบัติเด่นของ Hermes V1 ประกอบด้วย Ahead-of-Time Compilation ที่แปลง JavaScript เป็น Bytecode ตั้งแต่ขั้นตอน Build, Hades Garbage Collector ที่ทำงานแบบ Concurrent และ JIT Compiler รุ่นใหม่ที่เพิ่มประสิทธิภาพ Runtime

// 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 Garbage Collector เป็นหนึ่งในนวัตกรรมสำคัญของ Hermes V1 ระบบ GC รุ่นเก่าจะหยุดการทำงานของ JavaScript Thread ทั้งหมดขณะเก็บขยะ ส่งผลให้เกิดอาการกระตุกในแอปพลิเคชัน Hades แก้ปัญหานี้ด้วยการทำงานแบบ Concurrent และ Incremental ทำให้ GC Pause ลดลงจาก 45ms เหลือเพียง 12ms หรือต่ำกว่า

Fabric Renderer: ระบบเรนเดอร์ประสิทธิภาพสูง

Fabric เป็นระบบเรนเดอร์ใหม่ที่เขียนด้วย C++ และทำงานแบบ Synchronous แทนที่จะส่งคำสั่งผ่าน Bridge แบบ Asynchronous เหมือนระบบ Paper เดิม Fabric สามารถอัปเดต UI ได้ทันทีผ่าน JSI การเปลี่ยนแปลงนี้ส่งผลให้ Screen Transition เร็วขึ้น 39% และรองรับ React 18+ Concurrent Features ได้อย่างสมบูรณ์

ตัวอย่างการใช้ Concurrent Features กับ Fabric แสดงให้เห็นการทำงานร่วมกันระหว่าง useTransition และระบบเรนเดอร์ใหม่

// 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' },
})

ในตัวอย่างข้างต้น การอัปเดต query จะเกิดขึ้นทันทีเพื่อให้ผู้ใช้เห็นการพิมพ์ของตนเอง ในขณะที่การ Filter รายการจะถูกเลื่อนออกไปเป็น Non-urgent Update Fabric รองรับการทำงานนี้ได้อย่างสมบูรณ์ ทำให้ UI ตอบสนองได้ลื่นไหลแม้มีข้อมูลจำนวนมาก

TurboModules: Native Modules ยุคใหม่

TurboModules เป็นระบบ Native Modules รุ่นใหม่ที่ใช้ JSI ในการเรียกใช้งาน Native Code โดยตรง แทนที่จะส่งข้อมูลผ่าน Bridge แบบเดิม ข้อดีหลักของ TurboModules คือรองรับการเรียกแบบ Synchronous สำหรับ Operation ที่ต้องการผลลัพธ์ทันที, Lazy Loading ที่โหลด Module เฉพาะเมื่อถูกเรียกใช้ และ Type Safety ผ่าน Codegen

การสร้าง TurboModule เริ่มต้นด้วยการกำหนด Spec ใน TypeScript

// 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')

Spec นี้กำหนด Interface ที่ Native Module จะต้อง Implement โดย Codegen จะสร้าง Native Interface อัตโนมัติจาก TypeScript Spec ทำให้มั่นใจได้ว่า Type ระหว่าง JavaScript และ Native ตรงกัน

สำหรับ Android การ Implement TurboModule ใน Kotlin มีลักษณะดังนี้

// 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"
}

สังเกตว่า Method อย่าง getDeviceModel() และ getBatteryLevel() สามารถ Return ค่าได้ทันทีแบบ Synchronous ผ่าน JSI ไม่ต้องรอ Bridge Queue เหมือนระบบเก่า ทำให้ JS-to-Native Call เร็วขึ้นถึง 40 เท่า

JSI: หัวใจของสถาปัตยกรรมใหม่

JSI (JavaScript Interface) เป็น Layer ที่ช่วยให้ JavaScript สามารถเรียกใช้ C++ Object ได้โดยตรง โดยไม่ต้องผ่านการ Serialize เป็น JSON ก่อน JSI เป็นพื้นฐานที่ทำให้ทั้ง Fabric และ TurboModules ทำงานได้

ข้อดีหลักของ JSI ประกอบด้วย Direct Memory Access ที่ช่วยให้ JavaScript เข้าถึง Native Object ได้โดยตรง, Engine Agnostic ที่รองรับทั้ง Hermes, JSC และ V8 และ Zero-Copy Communication ที่ลดการ Copy ข้อมูลระหว่าง Layer

Bridgeless Mode: อนาคตของ React Native

Bridgeless Mode เป็นขั้นตอนสุดท้ายของการเปลี่ยนผ่านไปสู่สถาปัตยกรรมใหม่ ในโหมดนี้ Bridge เดิมจะถูกลบออกทั้งหมด ทุกการสื่อสารจะผ่าน JSI โดยตรง ผลลัพธ์คือการ Startup ที่เร็วขึ้นเนื่องจากไม่ต้อง Initialize Bridge และ Register Module ทั้งหมดล่วงหน้า

Bridgeless Mode ใช้ระบบ Lazy Initialization ที่โหลด TurboModule เฉพาะเมื่อถูกเรียกใช้ครั้งแรก ซึ่งช่วยลดเวลา Cold Start อย่างมาก โดยเฉพาะในแอปพลิเคชันขนาดใหญ่ที่มี Native Module จำนวนมาก

ผลลัพธ์ด้านประสิทธิภาพ

ตารางด้านล่างแสดงการเปรียบเทียบประสิทธิภาพระหว่างสถาปัตยกรรมเก่าและใหม่ ข้อมูลมาจากการทดสอบจริงบนอุปกรณ์ระดับกลาง

| Metric | สถาปัตยกรรมเดิม | สถาปัตยกรรมใหม่ | การปรับปรุง | |--------|-----------------|------------------|-------------| | Cold start (TTI) | 1.4s | 0.8s | เร็วขึ้น 43% | | Screen transition | 180ms | 110ms | เร็วขึ้น 39% | | Memory baseline | 89MB | 66MB | ลดลง 26% | | JS-to-native call | ~5ms (async) | ~0.1ms (sync) | เร็วขึ้น 40x | | GC max pause | 45ms | 12ms | สั้นลง 73% | | FlatList scroll (1000 items) | กระตุกเป็นครั้งคราว | ลื่นไหล 60fps | ไม่มี Frame ตก |

ตัวเลขเหล่านี้แสดงให้เห็นว่าสถาปัตยกรรมใหม่ไม่ใช่การปรับปรุงเล็กน้อย แต่เป็นการยกระดับประสิทธิภาพอย่างมีนัยสำคัญในทุกด้าน

คำถามสัมภาษณ์ React Native New Architecture 2026

สำหรับนักพัฒนาที่กำลังเตรียมตัวสัมภาษณ์งาน ต่อไปนี้คือคำถามที่พบบ่อยเกี่ยวกับสถาปัตยกรรมใหม่

คำถาม: อธิบายความแตกต่างระหว่าง Bridge เดิมกับ JSI

คำตอบที่ดีควรอธิบายว่า Bridge เดิมทำงานแบบ Asynchronous โดยแปลงข้อมูลเป็น JSON และส่งผ่าน Queue ในขณะที่ JSI ช่วยให้ JavaScript เรียกใช้ C++ Object ได้โดยตรงแบบ Synchronous ไม่ต้องมีการ Serialize ข้อมูล

คำถาม: Hermes V1 ปรับปรุงอะไรบ้างจาก Hermes รุ่นก่อน

ควรกล่าวถึง Hades Garbage Collector ที่ทำงานแบบ Concurrent, JIT Compiler รุ่นใหม่ และ Bytecode Format ที่ปรับปรุงแล้ว

คำถาม: ทำไม TurboModules ถึงเร็วกว่า Bridge Modules

คำตอบควรครอบคลุมการเรียกใช้แบบ Synchronous ผ่าน JSI, การไม่ต้อง Serialize เป็น JSON และ Lazy Loading ที่โหลด Module เฉพาะเมื่อจำเป็น

คำถาม: Fabric ต่างจาก Paper อย่างไร

ควรอธิบายว่า Fabric ใช้ C++ Shared Core ที่ทำงานแบบ Synchronous รองรับ Concurrent Rendering และอัปเดต UI ผ่าน JSI โดยตรง

คำถาม: Bridgeless Mode มีประโยชน์อย่างไร

คำตอบควรกล่าวถึงการลบ Bridge ออกทั้งหมด, Lazy Module Initialization และการ Startup ที่เร็วขึ้น

การเตรียมตัวสำหรับการ Migrate

สำหรับโปรเจกต์ที่ต้องการ Migrate ไปใช้สถาปัตยกรรมใหม่ มีขั้นตอนที่ควรปฏิบัติดังนี้

ขั้นตอนแรกคือการอัปเกรด React Native เป็นเวอร์ชัน 0.76 หรือใหม่กว่า ซึ่งเปิดใช้งานสถาปัตยกรรมใหม่เป็นค่าเริ่มต้น ขั้นตอนต่อไปคือการตรวจสอบ Third-party Library ว่ารองรับ Fabric และ TurboModules หรือไม่ Library ยอดนิยมส่วนใหญ่ได้รับการอัปเดตแล้ว แต่บาง Library อาจต้องรอหรือหาทางเลือกอื่น

สำหรับ Custom Native Modules จะต้อง Migrate ไปใช้ TurboModule Pattern โดยสร้าง Spec ใน TypeScript และ Implement Native Code ตาม Interface ที่ Codegen สร้างขึ้น

บทสรุป

React Native New Architecture ในปี 2026 นำเสนอการปรับปรุงที่สำคัญในทุกระดับ

• Hermes V1 ให้ประสิทธิภาพ JavaScript ที่ดีขึ้นพร้อม Hades GC ที่ลด Pause Time
• Fabric Renderer ทำงานแบบ Synchronous รองรับ Concurrent Features ของ React 18+
• TurboModules ใช้ JSI สำหรับการเรียก Native Code โดยตรงและรวดเร็ว
• JSI เป็นพื้นฐานที่เชื่อมต่อทุกองค์ประกอบเข้าด้วยกัน
• Bridgeless Mode ลบ Bridge เดิมออกทั้งหมดเพื่อประสิทธิภาพสูงสุด

สำหรับนักพัฒนาที่ต้องการเตรียมตัวสำหรับการสัมภาษณ์งาน การเข้าใจสถาปัตยกรรมใหม่เป็นสิ่งจำเป็น โดยเฉพาะการอธิบายความแตกต่างระหว่างระบบเก่าและใหม่ รวมถึงเหตุผลที่ทำให้ประสิทธิภาพดีขึ้น