React Native DevTools คู่มือดีบัก 2026

อัปเดต: 2 มิถุนายน 2026

React Native DevTools คือเครื่องมือดีบักอย่างเป็นทางการของ React Native ที่สร้างบน Chrome DevTools Frontend และเชื่อมต่อกับ Hermes engine โดยตรง เปิดตัวพร้อม React Native 0.76 และกลายเป็นค่าเริ่มต้นในปี 2026 หลังจาก Meta ประกาศหยุดสนับสนุน Flipper อย่างเป็นทางการ ในคู่มือฉบับนี้ ผมจะพาคุณตั้งค่า เปิดใช้งาน และใช้ทุกฟีเจอร์ของ React Native DevTools ตั้งแต่ Console, Network, Performance Profiler ไปจนถึงการดีบัก Memory leaks ในแอปจริงที่ผมส่งขึ้น Production ทุกสัปดาห์

React Native DevTools เป็นค่าเริ่มต้นใน RN 0.76+ และทำงานเฉพาะกับ Hermes engine เท่านั้น (ไม่รองรับ JSC อีกต่อไป)
Flipper ถูก deprecate อย่างเป็นทางการตั้งแต่ RN 0.74 และถูกถอดออกจาก template ในเวอร์ชันใหม่
เปิด DevTools ด้วยการกด j ใน Metro terminal หรือเปิด Dev Menu บนอุปกรณ์แล้วเลือก "Open DevTools"
Network panel ใช้ดูทุก fetch/XHR request พร้อม headers, payload และเวลา latency ในรูปแบบ Chrome DevTools คุ้นเคย
Performance profiler ช่วยหา JS thread bottlenecks ที่ทำให้แอปกระตุก โดยเฉพาะใน list rendering และ animations
React DevTools รวมอยู่ในตัวแล้ว ตรวจสอบ props, state, hooks และ component tree ได้โดยไม่ต้องติดตั้งเพิ่ม

React Native DevTools คืออะไร?

React Native DevTools คือเครื่องมือดีบักเดสก์ท็อปที่ Meta พัฒนาขึ้นใหม่และเปิดตัวพร้อม React Native 0.76 ในปลายปี 2024 ตัวมันสร้างบน Chrome DevTools Frontend ที่นักพัฒนาเว็บคุ้นเคย แต่ปรับให้สื่อสารกับ Hermes JavaScript engine ผ่าน Chrome DevTools Protocol (CDP) โดยตรง ผลคือคุณได้ประสบการณ์ดีบักที่เหมือนเปิด chrome://inspect ในเว็บ มี Sources, Console, Network, Memory, Performance ครบ แต่ทำงานกับโค้ด JavaScript ที่รันบน iOS Simulator, Android Emulator หรือเครื่องจริง

สิ่งที่ผมประทับใจที่สุดในการใช้งานจริงคือความเร็วในการ attach debugger ที่ลดลงจากหลายวินาทีในยุค Flipper เหลือไม่ถึงครึ่งวินาที และ source maps ที่ตรงกับโค้ด TypeScript จริงโดยไม่ต้องตั้งค่าเพิ่ม สำหรับโปรเจกต์ที่ใช้ React Native New Architecture (Fabric, TurboModules, JSI) ตัว DevTools รองรับ breakpoint ใน worklets ของ Reanimated และในโค้ดที่รันบน UI thread ผ่าน JSI ได้แล้วในเวอร์ชัน 2026

ตามที่ระบุใน บันทึกการเปิดตัว React Native 0.76 ทีม Meta ตั้งใจให้ DevTools เป็น "single source of truth" สำหรับการดีบักทุกประเภท ตั้งแต่ JS, Network, Performance ไปจนถึง React component inspection

ทำไม Flipper ถึงถูก Deprecate?

Flipper ถูกประกาศ deprecate อย่างเป็นทางการตั้งแต่ React Native 0.74 (พฤษภาคม 2024) และถูกถอดออกจาก default template ใน RN 0.75 เหตุผลหลักมาจากสามประเด็น คือ (1) ภาระการบำรุงรักษา. Flipper เป็น Electron app ขนาดใหญ่ที่ต้องมี SDK ฝั่ง native ทั้งบน iOS และ Android ทำให้เพิ่มเวลา build และขนาด debug binary อย่างมาก (2) ความไม่เข้ากันกับ New Architecture เมื่อ Fabric และ TurboModules กลายเป็นค่าเริ่มต้น Flipper plugins หลายตัวต้อง rewrite ซึ่ง community ตามไม่ทัน (3) ระบบนิเวศซ้ำซ้อน เมื่อ Hermes มี Chrome DevTools Protocol built-in แล้ว การมี debugger ตัวที่สามไม่จำเป็นอีกต่อไป

ในทางปฏิบัติ ผมเห็นทีมที่ยังพยายามใช้ Flipper ในปี 2026 มักเจอปัญหา crash เมื่อเปิดร่วมกับ Xcode 16 หรือ Android Gradle Plugin 8.x และ plugins ยอดนิยมอย่าง Network และ Layout Inspector ไม่ทำงานกับ New Architecture หากโปรเจกต์ของคุณยังพึ่งพา Flipper อยู่ ขอแนะนำให้วางแผน migrate ภายในไตรมาสนี้เพื่อหลีกเลี่ยงปัญหาตอน upgrade RN เวอร์ชันถัดไป

วิธีเปิดและตั้งค่า React Native DevTools

การตั้งค่า React Native DevTools ในปี 2026 ง่ายมาก เพราะมันมาพร้อม React Native CLI และ Expo CLI โดยอัตโนมัติ ไม่ต้องลง package เพิ่มและไม่ต้องแก้ Podfile หรือ build.gradle ขั้นตอนเบื้องต้นมีเพียงสามอย่าง คือ ใช้ RN 0.76+ (หรือ Expo SDK 52+), เปิด Hermes, และรัน Metro bundler

ขั้นตอนเปิดใช้งาน

รัน npx react-native start หรือ npx expo start เพื่อเริ่ม Metro
เปิดแอปบน simulator/emulator หรือเครื่องจริงที่เชื่อมต่อกับ Metro
ใน terminal ที่รัน Metro กดปุ่ม j แล้ว DevTools จะเปิดในเบราว์เซอร์อัตโนมัติ
หรือเปิด Dev Menu บนอุปกรณ์ (เขย่าเครื่อง / กด Cmd+D ใน iOS Simulator / กด Cmd+M ใน Android Emulator) แล้วเลือก "Open DevTools"

# เริ่ม Metro bundler
npx react-native start

# หรือสำหรับ Expo
npx expo start --dev-client

# กด j ใน terminal เพื่อเปิด DevTools
# กด r เพื่อ reload, m เพื่อเปิด Dev Menu

การใช้ Console และ LogBox

Console panel เป็นจุดเริ่มต้นที่ทุกคนใช้บ่อยที่สุด ทุก console.log, console.warn, console.error ในโค้ดของคุณจะปรากฏที่นี่พร้อม source location ที่ลิงก์ตรงไปไฟล์ต้นฉบับ คุณสามารถพิมพ์ JavaScript expressions ลงใน console เพื่อ inspect ค่าตัวแปรในขณะที่แอปกำลัง pause อยู่ที่ breakpoint ได้ทันที

สิ่งที่ผมแนะนำให้ทำตั้งแต่วันแรกคือใช้ console.group() และ console.table() เพื่อจัดระเบียบ log ที่ซับซ้อน เช่นการดีบัก Redux/Zustand store หรือ list ของ rows ที่ render ผิดพลาด

// ตัวอย่างการจัดกลุ่ม log ขณะดีบัก state
function UserProfile({ userId }: { userId: string }) {
  const user = useUserStore((s) => s.users[userId]);

  console.group(`UserProfile render: ${userId}`);
  console.log('user:', user);
  console.table(user?.permissions ?? []);
  console.groupEnd();

  return <Text>{user?.name}</Text>;
}

LogBox ซึ่งเป็น overlay สีเหลือง/แดงในแอปยังทำงานคู่กับ Console panel เช่นเดิม คุณสามารถปิด LogBox สำหรับ warning ที่ทราบแล้วด้วย LogBox.ignoreLogs(['Warning: ...']) แต่อย่าใช้ LogBox.ignoreAllLogs() ใน production เพราะจะปิด stack trace ที่จำเป็นเวลาเกิด crash

วิธีดีบัก Network Requests

Network panel ใน React Native DevTools คือการอัปเกรดครั้งใหญ่จาก Flipper Network plugin ตัวมันดักจับทุก fetch, XMLHttpRequest และ WebSocket message โดยอัตโนมัติ โดยไม่ต้องเพิ่ม middleware หรือ wrapper ในโค้ดของคุณ ฟีเจอร์ที่ผมใช้บ่อยคือ Filter ตาม resource type, Throttling เพื่อจำลอง 3G/Slow 4G, และ Copy as cURL ซึ่งช่วยให้ทดสอบ API ใน terminal ได้ทันที

ตัวอย่างการดีบัก fetch ที่ล้มเหลว

สมมติว่า request ไปที่ https://api.example.com/users คืน 401 โดยไม่ทราบสาเหตุ ขั้นตอนที่ผมทำคือ

เปิด Network panel แล้ว reload แอปด้วย r
คลิกที่ request นั้นเพื่อดู Request Headers แล้วตรวจสอบว่า Authorization header ถูกส่งจริงหรือไม่
ดู Payload tab เพื่อยืนยัน body ที่ส่งไป
คลิก "Copy as cURL" และรันใน terminal เพื่อแยกแยะว่าปัญหาอยู่ที่ client หรือ server

// ตัวอย่าง fetch wrapper ที่ทำงานคู่กับ Network panel ได้ดี
async function apiCall<T>(path: string, init?: RequestInit): Promise<T> {
  const token = await getAuthToken();
  const res = await fetch(`https://api.example.com${path}`, {
    ...init,
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${token}`,
      ...(init?.headers ?? {}),
    },
  });

  if (!res.ok) {
    // Network panel จะแสดง response นี้พร้อม status code
    throw new Error(`API ${path} failed: ${res.status}`);
  }
  return res.json();
}

การใช้ Performance Profiler

Performance panel เป็นเครื่องมือที่ทรงพลังที่สุดสำหรับการหา bottleneck ที่ทำให้แอปกระตุก โดยเฉพาะใน scroll lists หรือ animations ที่ตกเฟรม มันบันทึก CPU profile ของ JavaScript thread พร้อม flame chart ที่แสดงเวลาที่ใช้ใน function แต่ละตัว และ stack ของการเรียกที่ทำให้ frame เกิน 16.67ms (60 FPS budget)

ขั้นตอน profile แอปที่กระตุก

เปิด Performance panel แล้วกดปุ่ม Record (วงกลมสีดำ)
กลับไปที่แอปและทำ interaction ที่กระตุก เช่น scroll list หรือเปิด animation
หยุดบันทึกหลังจาก 5-10 วินาที
ดู flame chart โดย function ที่กว้างคือใช้เวลานาน หาก function ของคุณกว้างผิดปกติ คลิกเพื่อเปิด source
ดู Bottom-Up tab เพื่อเรียง function ที่ใช้ CPU มากที่สุด

จากประสบการณ์ของผม สาเหตุที่พบบ่อยที่สุดของแอป React Native กระตุกในปี 2026 มีสามแบบ คือ (1) Inline functions ใน FlatList renderItem ที่ทำให้เกิด re-render ทุก scroll, (2) JSON.parse/stringify ใน hot path โดยเฉพาะใน AsyncStorage operations และ (3) Reanimated worklets ที่เรียก JS function ผ่าน runOnJS บ่อยเกินไป. สำหรับเรื่องสุดท้าย ผมแนะนำให้อ่าน คู่มือ React Native Reanimated 4 ที่ครอบคลุมวิธีเขียน worklets ให้รันบน UI thread อย่างถูกต้อง

// Anti-pattern: inline function ทำให้ re-render ทุกครั้ง
<FlatList
  data={items}
  renderItem={({ item }) => <Row item={item} />}  // ❌
/>

// แก้: ใช้ useCallback หรือประกาศนอก component
const renderItem = useCallback(
  ({ item }: { item: Item }) => <Row item={item} />,
  []
);

<FlatList data={items} renderItem={renderItem} />  // ✅

วิธีดีบัก Memory Leaks ใน React Native

Memory leaks ใน React Native มักเกิดจาก subscription ที่ไม่ unsubscribe, timer ที่ไม่ clear, หรือ closure ที่อ้างถึง state เก่า Memory panel ใน DevTools ช่วยตรวจจับด้วย Heap Snapshot ซึ่งจะบันทึกสถานะ heap ของ Hermes ณ จุดเวลาหนึ่ง และเปรียบเทียบสองสแน็ปช็อตเพื่อหา object ที่ไม่ถูก garbage collect

วิธีหา leak จาก navigation

เปิด Memory panel แล้วถ่าย Heap Snapshot ครั้งแรก (Baseline)
นำทางเข้า/ออก screen ที่สงสัย 5-10 ครั้ง
กด "Collect garbage" (ไอคอนถังขยะ) เพื่อบังคับ GC
ถ่าย Snapshot ครั้งที่สองและเลือก "Comparison" view
เรียง column "Delta" โดย object ที่เพิ่มขึ้นเรื่อยๆ คือผู้ต้องสงสัย

// Pattern ที่มัก leak: subscription ไม่ cleanup
function ChatScreen({ roomId }: { roomId: string }) {
  useEffect(() => {
    const socket = io(`wss://chat.example.com/${roomId}`);
    socket.on('message', handleMessage);

    // ✅ ต้อง return cleanup function
    return () => {
      socket.off('message', handleMessage);
      socket.disconnect();
    };
  }, [roomId]);

  // ...
}

จริงๆ แล้ว ผมเจอบั๊กแบบนี้ตอนส่งฟีเจอร์ chat ขึ้น Production เมื่อปลายปีที่แล้ว Heap snapshot ชี้ตรงไปที่ Socket.IO instances ที่ค้างใน memory เพราะลืม disconnect ใน cleanup กว่าจะเจอใช้เวลาสองวัน เพราะแอปยังไม่ crash จนกว่าผู้ใช้จะเข้า-ออก chat 30 ครั้งขึ้นไป

React DevTools: ตรวจสอบ Components และ Hooks

React DevTools ถูกรวมเข้ามาใน React Native DevTools ตั้งแต่ RN 0.76 แล้ว ไม่ต้องรัน npx react-devtools แยกอีกต่อไป Tab "Components" แสดง tree ของ component พร้อม props และ state ส่วน "Profiler" ใช้บันทึก render timing เพื่อหา component ที่ render บ่อยเกินไป

ฟีเจอร์ที่ผมใช้บ่อยที่สุดคือ "Highlight updates when components render" ใน Settings ตัวมันวาดกรอบสีรอบ component ทุกครั้งที่ re-render ทำให้เห็นทันทีว่า component ไหน render โดยไม่จำเป็น โดยเฉพาะเมื่อใช้ร่วมกับ Zustand หรือ Redux ที่หาก selector ไม่ memoize อาจทำให้ทั้งแอป re-render

// Zustand selector ที่ memoize ถูกต้อง
import { shallow } from 'zustand/shallow';

// ❌ จะ re-render ทุกครั้งที่อะไรใน store เปลี่ยน
const { user, settings } = useStore((s) => ({
  user: s.user,
  settings: s.settings,
}));

// ✅ ใช้ shallow comparator
const { user, settings } = useStore(
  (s) => ({ user: s.user, settings: s.settings }),
  shallow
);

เปรียบเทียบ React Native DevTools, Flipper, Reactotron

แม้ว่า React Native DevTools จะเป็นมาตรฐานใหม่ในปี 2026 แต่ทีมจำนวนมากยังคงพิจารณา Reactotron สำหรับงานเฉพาะทาง ตารางด้านล่างสรุปจุดแข็งและจุดอ่อนของแต่ละเครื่องมือเพื่อช่วยตัดสินใจ

คุณสมบัติ	React Native DevTools	Flipper	Reactotron
สถานะปี 2026	Active, ค่าเริ่มต้น	Deprecated	Community-maintained
รองรับ New Architecture	ครบ	บางส่วน	ครบ
Network inspector	มี (built-in)	มี (plugin)	มี
Performance profiler	มี (CPU + Memory)	มีบางส่วน	ไม่มี
React component inspector	มี (รวม React DevTools)	มี (plugin)	ไม่มี
การติดตั้ง	ไม่ต้องลงเพิ่ม	ต้องลง SDK และ Electron app	ต้องลง package + desktop app
การใช้ Custom commands	ไม่รองรับ	รองรับผ่าน plugins	รองรับเต็มที่
การดู AsyncStorage/MMKV	ผ่าน Console	มี plugin	มี built-in

ข้อสรุปของผมคือ ใช้ React Native DevTools เป็นเครื่องมือหลัก สำหรับงานดีบักประจำวันทั้งหมด เพิ่ม Reactotron เป็นเสริม หากทีมต้องการ custom command ที่ trigger จาก desktop (เช่น reset store, mock API) และ เลิกใช้ Flipper ในโปรเจกต์ใหม่ทั้งหมด

เคล็ดลับการดีบักขั้นสูงและ Pitfalls

หลังจากใช้ React Native DevTools มาหนึ่งปีเต็มในโปรเจกต์ Production มีเทคนิคหลายอย่างที่ไม่ได้อยู่ในเอกสารทางการ แต่ช่วยประหยัดเวลาดีบักได้มาก

1. ใช้ Conditional Breakpoints ใน Sources

แทนที่จะ pause ทุก iteration ของ loop ให้คลิกขวาที่ line number แล้วเลือก "Add conditional breakpoint" ตัวอย่าง: item.id === 'user-42' จะ pause เฉพาะเมื่อ render row ที่มีปัญหา

2. Source Maps สำหรับ Production Crashes

เมื่อแอปขึ้น Production และเกิด crash ผ่าน Sentry หรือ Crashlytics stack trace จะเป็น minified code ตั้งค่า sourceMap.enabled = true ใน metro.config.js และอัปโหลด source map ไปที่ crash reporter เพื่อให้ DevTools resolve กลับเป็น TypeScript ต้นฉบับ ดู เอกสาร debugging อย่างเป็นทางการของ React Native สำหรับการตั้งค่าเต็มรูปแบบ

3. Debug บนเครื่องจริงผ่าน Wi-Fi

ใน iOS Simulator/Android Emulator การเชื่อม DevTools ทำงานอัตโนมัติ แต่บนเครื่องจริงต้องตั้ง Metro ให้ listen ที่ IP ของเครื่อง dev ไม่ใช่ localhost ใช้คำสั่ง npx react-native start --host 0.0.0.0 และตั้งค่า Dev Settings > Debug server host บน device ให้ชี้ไปที่ 192.168.x.x:8081

4. ระวัง Source Map ที่ผิดเวอร์ชัน

หาก breakpoint ของคุณ pause ที่บรรทัดผิดหรือไม่ pause เลย มักเป็นเพราะ Metro cache ของ source map เก่า ลบ cache ด้วย npx react-native start --reset-cache หรือลบโฟลเดอร์ $TMPDIR/metro-cache

5. ใช้คู่กับ Maestro/Detox

หากคุณรัน E2E tests กับ Maestro หรือ Detox ดังที่อธิบายใน คู่มือ React Native Testing สามารถเปิด DevTools ขณะ test รันได้ ช่วยเห็น network calls และ console errors ที่ทำให้ test ล้มเหลวโดยไม่ต้อง re-run

สำหรับรายละเอียดทาง protocol เพิ่มเติม โดยเฉพาะหากคุณต้องการพัฒนา tooling ของตัวเอง ดู เอกสาร Chrome DevTools Protocol ซึ่งเป็นมาตรฐานที่ Hermes implement

คำถามที่พบบ่อย

React Native DevTools รองรับ JavaScriptCore (JSC) ไหม?

ไม่รองรับ React Native DevTools ทำงานเฉพาะกับ Hermes engine เท่านั้น เพราะใช้ Chrome DevTools Protocol ที่ Hermes implement โดยตรง หากโปรเจกต์ของคุณยังใช้ JSC จะต้องเปลี่ยนเป็น Hermes ก่อน ซึ่งเป็นค่าเริ่มต้นใน RN 0.70+ อยู่แล้ว

จะใช้ Chrome Debugger เดิม (Remote JS Debugging) ได้อีกไหม?

ไม่ได้ Remote JS Debugging ผ่าน Chrome ถูกถอดออกตั้งแต่ RN 0.76 เพราะเปลี่ยน execution context ทำให้ผลลัพธ์ต่างจาก production และก่อให้เกิดบั๊กที่ debug ได้ยาก ใช้ React Native DevTools แทนซึ่งดีบักโค้ดที่รันบน Hermes จริงๆ

ทำไม Breakpoint ไม่ทำงาน?

สาเหตุที่พบบ่อยสามอย่าง คือ (1) source maps ผิดเวอร์ชัน ให้ลบ Metro cache ด้วย --reset-cache, (2) ไฟล์ถูก Hermes pre-compile เป็น bytecode ที่ไม่มี debug info ให้ตรวจสอบว่า build เป็น dev mode, (3) breakpoint อยู่ใน worklet ซึ่งต้องใช้ Reanimated 3.10+ จึงรองรับ debug worklets

มีวิธีดู AsyncStorage และ MMKV จาก DevTools ไหม?

ปัจจุบัน DevTools ไม่มี panel เฉพาะสำหรับ storage แต่สามารถพิมพ์คำสั่งใน Console ได้โดยตรง เช่น await AsyncStorage.getAllKeys() หรือสำหรับ MMKV ใช้ storage.getAllKeys() หากต้องการ UI สวยกว่านี้ Reactotron มี storage inspector แบบเต็มรูปแบบ

DevTools ทำงานกับ Expo Go ได้ไหม?

ได้ แต่มีข้อจำกัด Expo Go บน Expo SDK 52+ รองรับ DevTools เต็มรูปแบบ ส่วน SDK เก่ากว่านั้นสามารถใช้ Console และ React DevTools ได้ แต่ Performance/Memory panel อาจไม่สมบูรณ์ แนะนำให้ใช้ Development Build (expo run:ios หรือ expo run:android) สำหรับการดีบักจริงจัง