ผมสร้าง Traverba ขึ้นมา — แอปแปลภาษาแบบเรียลไทม์ที่ทำงาน 100% บนโทรศัพท์ของคุณ โดยไม่ต้องพึ่ง cloud API เลย ไม่ว่าจะเป็นการรู้จำเสียง, การแปลใน 108 ภาษา, OCR กล้องรองรับ 92 สคริปต์, การแปลข้อความที่ปรากฏบนหน้าจอแบบ overlay, การถอดเสียงไฟล์, และแชทกลุ่มออฟไลน์ผ่าน Bluetooth สำหรับผู้ใช้สูงสุด 7 คน
ทั้งแอปสร้างด้วย Flutter ร่วมกับโค้ด native ของแต่ละแพลตฟอร์มสำหรับงานหนัก นี่คือสิ่งที่แอปทำได้, เหตุผลที่ Flutter เป็นตัวเลือกที่ใช่, และความท้าทายที่ยากที่สุดในการ ship ไปยัง production ทั้งบน iOS และ Android
สิ่งที่แอปทำได้
Traverba มี 5 ฟีเจอร์หลัก ทำงานได้ทั้งหมดแบบออฟไลน์:
การแปลเสียงแบบสด — พูดภาษาหนึ่ง ฟังและอ่านคำแปลในอีกภาษา มีสามโหมด: ในแอป, การดักจับเสียงระบบแบบ floating (แปลเสียงจาก Zoom/Teams/Meet) และไมโครโฟนแบบ floating อ่านคำแปลออกเสียงในภาษาปลายทางโดยอัตโนมัติ
การแปลผ่านกล้อง — จับกล้องไปที่เมนู ป้าย แบบฟอร์ม หรือเอกสาร ใช้ OCR สองเอนจิน: Basic mode (ML Kit) สำหรับอ่านเร็ว และ Professional mode (PaddleOCR) สำหรับสคริปต์ซับซ้อน เช่น CJK, อาหรับ, ซีริลลิก และเทวนาครี รองรับ 92 ภาษา แอปจะแทนที่ข้อความต่างภาษาด้วยคำแปลโดยตรงบนรูปภาพ
การแปลหน้าจอ — overlay แบบลอยตัวที่แปลข้อความในทุกแอป ไม่ว่าจะดูอนิเมะ อ่านข่าวเกาหลี เล่นเกมญี่ปุ่น หรือรับข้อความ WeChat เพียงแตะปุ่ม overlay แล้วข้อความจะถูกแปลในที่นั้นเลย ไม่ต้องสลับแอป
การถอดเสียงจากไฟล์ — นำเข้าไฟล์เสียงหรือวิดีโอ (mp3, m4a, wav, mp4) แล้วรับผลลัพธ์เป็น transcript คู่ต้นฉบับและคำแปล พร้อม timestamp
แชทกลุ่มออฟไลน์ — ผู้ใช้สูงสุด 7 คนเชื่อมต่อกันผ่าน Bluetooth mesh แต่ละคนพูดภาษาของตัวเอง ทุกข้อความจะถูกแปลเป็นภาษาของผู้เข้าร่วมทุกคนแบบเรียลไทม์ ไม่ต้องต่ออินเทอร์เน็ต ไม่มีเซิร์ฟเวอร์ แต่ละโทรศัพท์จัดการ ASR และการแปลของตัวเองอย่างอิสระ
ทั้งหมดนี้ทำงานในเครื่องบนโปรเซสเซอร์ของโทรศัพท์ ไม่ต้องใช้ API key ไม่มีค่าใช้จ่ายเซิร์ฟเวอร์ ไม่มีข้อมูลออกจากอุปกรณ์
ทำไมถึงเลือก Flutter
ผมประเมิน Flutter, React Native และ native เต็มรูปแบบ (โค้ดเบส Swift + Kotlin แยกกัน) ตั้งแต่ต้น
การทำงาน cross-platform จาก codebase เดียวเป็นสิ่งที่ต้องมี นักพัฒนาคนเดียวที่ดูแล native codebase สองชุดสำหรับแอปที่ซับซ้อนขนาดนี้เป็นเรื่องที่ไม่สมเหตุสมผล UI layer ใน Dart ได้แก่ การตั้งค่า, ฟองแชท, มุมมอง transcript, ทัวร์ onboarding, หน้าต่างดาวน์โหลด, ตัวเลือกภาษา คิดเป็นประมาณ 60% ของโค้ดทั้งหมด การเขียนซ้ำสองครั้งจะทำให้เวลาพัฒนาโปรเจกต์เพิ่มขึ้นเป็นสองเท่า
ระบบ platform channel ของ Flutter ทำให้การผสานรวม native เป็นเรื่องจริงในทางปฏิบัติ งานที่หนักด้าน AI (การอนุมาน ASR, การแปลด้วย LLM, OCR, Bluetooth mesh, floating overlay) ทำงานใน native Swift/Kotlin ผ่าน platform channel และ method channel Flutter ไม่ได้พยายามเป็น AI runtime แต่เป็น UI layer และ orchestration layer ที่เชื่อมต่อเอนจิน native ต่างๆ
ประสิทธิภาพดีพอ ความกังวลกับ Flutter สำหรับแอปประเภทนี้คือ overhead ทุกมิลลิวินาทีมีความสำคัญเมื่อต้องเชื่อมต่อ ASR → การแปล → TTS ในการสนทนา ในทางปฏิบัติ Flutter layer เพิ่ม latency เพียงเล็กน้อยมาก เพราะการคำนวณหนักเกิดขึ้นใน native code Dart layer จัดการ state management, routing และการอัปเดต UI ซึ่งทำได้ดี
Hot reload เร่งการทำซ้ำ UI ได้อย่างมาก ด้วยพื้นที่ฟีเจอร์ที่แตกต่างกันถึง 5 ส่วน (เสียง, กล้อง, หน้าจอ, ไฟล์, แชทกลุ่ม) แต่ละส่วนมีหลาย state และโหมด ความสามารถในการทำซ้ำ UI โดยไม่ต้อง rebuild จึงเป็นตัวคูณประสิทธิภาพที่สำคัญมาก
สถาปัตยกรรม: Flutter ในฐานะ Orchestrator
แอปแบ่งหน้าที่ชัดเจน:
Flutter/Dart layer รับผิดชอบ:
- UI ทั้งหมด (Material 3, layout แบบ adaptive สำหรับโทรศัพท์และแท็บเล็ต)
- State management และ feature routing
- การเลือกภาษา/locale และการตั้งค่าผู้ใช้
- การจัดการดาวน์โหลดสำหรับโมเดลเสริม
- ระบบเหรียญและการ gating subscription
- ทัวร์ onboarding แบบ guided
Native layer รับผิดชอบ (ผ่าน platform channel):
- การอนุมาน ASR (sherpa-onnx / whisper.cpp)
- การแปลด้วย LLM (Gemma ผ่าน runtime บนอุปกรณ์)
- การแปลแบบ ML ดั้งเดิม (โมเดล ONNX NMT)
- OCR กล้อง (ML Kit + PaddleOCR)
- Text-to-speech
- Bluetooth mesh สำหรับแชทกลุ่ม
- Floating overlay (การแปลหน้าจอ + การดักจับเสียงระบบ)
- การจัดการ memory budget และการโหลด/ขับโมเดลออก
สะพานเชื่อมระหว่างสองเลเยอร์นี้คือชุด platform channel ที่มี contract ที่กำหนดไว้อย่างชัดเจน ฝั่ง Dart ส่งคำสั่ง ("เริ่ม ASR สำหรับภาษากวางตุ้ง," "แปลข้อความนี้จากญี่ปุ่นเป็นอังกฤษ," "จับภาพหน้าจอและทำ OCR") ฝั่ง native ส่งผลลัพธ์กลับแบบ asynchronous
ASR 3 โมเดล, เส้นทางอัตโนมัติ
ไม่มีโมเดลรู้จำเสียงพูดใดที่ครอบคลุมทุกภาษาได้ดี แทนที่จะยอมรับคุณภาพที่ต่ำสำหรับบางภาษา แอปจึงมีโมเดลเฉพาะทางสามตัว:
- Parakeet เพิ่มประสิทธิภาพสำหรับภาษาอังกฤษ รวมมากับแอปเพื่อ ASR อังกฤษทันทีโดยไม่ต้องดาวน์โหลด
- Whisper.cpp ครอบคลุมหลายภาษากว้างขวางกว่า 30+ ภาษา
- Qwen3-ASR เพิ่มประสิทธิภาพสำหรับ CJK พร้อมรองรับภาษากวางตุ้งโดยเฉพาะ
เมื่อผู้ใช้เลือกภาษาต้นทาง Dart routing layer จะเลือกโมเดลที่ดีที่สุดและบอก native side ว่าให้เปิดใช้งานเอนจินใด ผู้ใช้ไม่ต้องเห็นหรือจัดการการเลือกโมเดลเอง
ส่วนที่ยุ่งยากคือ memory โมเดลเหล่านี้ใช้ RAM ตั้งแต่ 500MB ถึง 1.9GB การโหลดทั้งสามพร้อมกันจะทำให้โทรศัพท์ส่วนใหญ่พัง memory budget planner (เขียนใน Dart, query ข้อมูล memory จาก native) ติดตามสิ่งที่โหลดอยู่และขับโมเดลที่ใช้งานนานที่สุดออกเมื่อต้องโหลดโมเดลใหม่ backend preference store จดจำว่า compute backend ใด (NPU, GPU, CPU) ทำงานได้บนอุปกรณ์แต่ละเครื่อง เพื่อให้การรันครั้งต่อไปข้าม backend ที่ล้มเหลวได้
108 ภาษา ผ่านสองระดับการแปล
การแปลทำงานผ่านสองเส้นทาง:
ระดับ 1 — โมเดล NMT แบบดั้งเดิม (61 ภาษา): เร็ว ใช้ memory น้อย คุณภาพดีสำหรับคู่ภาษาที่มีทรัพยากรมาก โมเดล ONNX รันผ่าน sherpa-onnx บนทั้งสองแพลตฟอร์ม
ระดับ 2 — Gemma LLM บนอุปกรณ์ (47 ภาษาเพิ่มเติม): สำหรับภาษาที่ไม่มีโมเดล NMT เฉพาะ (Yoruba, Amharic, ลาว, พม่า และอื่นๆ) โมเดล Gemma 2B แบบ quantized จัดการการแปลในเครื่อง ช้ากว่าระดับ 1 แต่ขยายการครอบคลุมไปยังภาษาที่โมเดลดั้งเดิมรองรับได้ไม่ดี
Dart layer จัดการว่าจะใช้ระดับใดตามคู่ภาษา ผู้ใช้เห็นประสบการณ์เดียวกัน
OCR กล้อง: สองเอนจิน, 92 ภาษา
การแปลผ่านกล้องรันสองเอนจินที่ผู้ใช้เลือกได้:
Basic mode ใช้การรู้จำข้อความบนอุปกรณ์ของ Google ML Kit เร็ว รองรับ Latin, Cyrillic และ CJK ได้ดี เหมาะสำหรับการใช้งานแบบ viewfinder แบบเรียลไทม์
Professional mode ใช้ PaddleOCR รันบนอุปกรณ์ ความแม่นยำดีกว่าสำหรับ layout ซับซ้อน, สคริปต์ผสม, ข้อความโค้ง และคอนทราสต์ต่ำ ใช้ระบบเหรียญ (5 เหรียญต่อการจับภาพ) เนื่องจากใช้ compute มากกว่า
บทเรียนที่เรียนรู้มาจากประสบการณ์จริง: iOS รวมเฉพาะโมเดลสคริปต์ OCR สำหรับ Latin เป็นค่าเริ่มต้น CJK, Devanagari และอาหรับต้องเพิ่ม pod เฉพาะสคริปต์ใน Podfile อย่างชัดเจน ความล้มเหลวนั้นเงียบสนิท — ML Kit ส่งคืนผลลัพธ์ว่างเปล่าสำหรับสคริปต์ที่ไม่รองรับโดยไม่มีข้อผิดพลาด ถ้าคุณกำลังสร้าง OCR หลายภาษาบน iOS ด้วย ML Kit ให้ตรวจสอบ Podfile ของคุณ
Floating Overlay: Native ไม่ใช่ Flutter
ฟีเจอร์การแปลหน้าจอและเสียงระบบทำงานเป็น native overlay ที่อยู่นอกพื้นที่ rendering ของ Flutter บน Android นี่คือ system overlay service ที่เขียนใน Kotlin บน iOS ใช้ screen capture API ใน Swift
overlay เหล่านี้สื่อสารกลับไปยังเอนจินแปลภาษา Flutter ผ่าน platform channel ความท้าทายทางสถาปัตยกรรมคือการจัดการ lifecycle — overlay ต้องทำงานต่อในขณะที่ Flutter activity หลักอาจถูก background
บทเรียนสำคัญ: บน iOS instance ของ native bridge ต้องถูก retain อย่างแน่นหนา (static หรือถือโดย singleton) หาก bridge เป็น instance variable ที่ไม่มีอะไร retain ARC จะ garbage-collect มันและ handler closure ทั้งหมดจะกลายเป็น no-op อย่างเงียบ ผมเสียเวลาหลายวันไปกับตัวแสดงความคืบหน้าการดาวน์โหลดที่ค้างอยู่ที่ 0% เพราะ bridge ถูก collect ไป ไม่มี crash ไม่มีข้อผิดพลาด แค่ล้มเหลวอย่างเงียบ
Bluetooth แชทกลุ่ม
แชทกลุ่มออฟไลน์ใช้โปรโตคอล Bluetooth mesh โทรศัพท์แต่ละเครื่องทำหน้าที่ทั้งเป็นผู้รับและตัวส่งต่อ ข้อความกระจายไปยังอุปกรณ์ที่เชื่อมต่อทั้งหมด แต่ละอุปกรณ์รัน ASR และการแปลของตัวเองอย่างอิสระ — ไม่มีโทรศัพท์ "host" หรือ "server"
Flutter จัดการ UI แชท, สถานะข้อความ และการจัดการผู้เข้าร่วม Bluetooth stack เป็น native เต็มรูปแบบ (CoreBluetooth บน iOS, Android Bluetooth API) เชื่อมผ่าน platform channel
Latency ของ pipeline ทั้งหมด (เสียง → ASR → แปล → broadcast → แสดงผล) อยู่ที่ประมาณ 1 วินาที Dart UI ใช้การแสดงผลแบบ optimistic (แสดง "กำลังแปล..." ทันทีเมื่อส่ง) เพื่อให้การสนทนารู้สึกตอบสนองดี
ตัวเลข
- ภาษา: 108 ภาษา (61 ML + 47 AI)
- ภาษา ASR: รู้จำเสียงพูดบนอุปกรณ์ 30 ภาษา
- ภาษา OCR: รู้จำข้อความกล้อง 92 ภาษา
- ขนาดแอปพื้นฐาน: ~150MB + โมเดลที่ดาวน์โหลดได้
- แพลตฟอร์ม: iOS + Android จาก Flutter codebase เดียว
- โค้ด Dart/Flutter: ~60% ของ codebase ทั้งหมด (UI, state, routing, business logic)
- โค้ด Native: ~40% (ASR, LLM, OCR, Bluetooth, overlay, การจัดการ memory)
- ขนาดทีม: 1 คน
สิ่งที่ Flutter ทำได้ถูกต้องสำหรับโปรเจกต์นี้
Codebase เดียวสำหรับ UI ที่ซับซ้อน พื้นที่ฟีเจอร์ 5 ส่วน, หลายโหมดในแต่ละส่วน, หน้าต่างดาวน์โหลด, ทัวร์ onboarding, layout แบบ adaptive — การเขียนครั้งเดียวแทนที่จะสองครั้งเป็นความแตกต่างระหว่างการ ship ได้และ ship ไม่ได้สำหรับนักพัฒนาคนเดียว
Platform channel ออกแบบมาดี สะพานระหว่าง Dart และโค้ด native นั้นสะอาด, มีเอกสารประกอบดี และเชื่อถือได้ สำหรับแอปที่การคำนวณหนักอยู่ใน native แต่ประสบการณ์ผู้ใช้อยู่ใน Flutter นี่คือสถาปัตยกรรมที่ถูกต้องพอดี
Hot reload สำหรับการทำซ้ำอย่างรวดเร็ว การปรับ layout, ทดสอบ state, ทำซ้ำ UX flow — hot reload ลดเวลาทำซ้ำจากนาทีเป็นวินาทีตลอดการเปลี่ยนแปลง UI หลายร้อยครั้ง
Ecosystem มีความสมบูรณ์ State management (Riverpod), navigation, localization (117 locale), adaptive design — Flutter ecosystem มีโซลูชันระดับ production สำหรับทั้งหมดนี้
สิ่งที่ยากลำบาก
Memory pressure คือจุดอ่อนแอของ Flutter Flutter ไม่เปิดเผยการควบคุม memory ที่ละเอียด เมื่อคุณโหลด native ML model หลายตัวพร้อมกับ Flutter engine คุณต้องจัดการ memory ในระดับ native และส่งข้อมูลกลับมายัง Dart ไม่มี Flutter API ในตัวสำหรับ "แอปของฉันใช้ RAM เท่าไหร่" หรือ "memory pressure ของระบบอยู่ที่เท่าไหร่"
Lifecycle ของ native overlay Floating overlay ที่ทำงานนอกพื้นที่ Flutter มีความซับซ้อนทางสถาปัตยกรรม Flutter activity อาจถูก background ในขณะที่ overlay ทำงานอยู่ การรักษา bridge ให้มีชีวิต, การซิงค์ state, และการจัดการ lifecycle event เฉพาะแพลตฟอร์มต้องใช้โค้ด native จำนวนมากที่ Flutter ไม่สามารถ abstract ได้
ความซับซ้อนในการ build iOS CocoaPods กับ ML Kit script pod, entitlement (increased-memory-limit สำหรับการโหลด ASR + LLM พร้อมกัน), App Tracking Transparency timing, code signing — iOS build pipeline มีส่วนที่เคลื่อนไหวหลายส่วนที่ Flutter tooling ไม่ได้จัดการครบถ้วน
ลองใช้งาน
Traverba ฟรีบนทั้งสองแพลตฟอร์ม เสียง, กล้อง, การแปลหน้าจอ และการแปลข้อความทั้งหมดฟรีและไม่จำกัด Premium ($1.99/month) ปลดล็อคแชทกลุ่ม, การถอดเสียงไฟล์ และสรุปการประชุม
ดาวน์โหลดได้ที่ Google Play และ App Store ข้อมูลเพิ่มเติมที่ traverba.com
ยินดีตอบคำถามเกี่ยวกับสถาปัตยกรรม, รูปแบบการผสานรวม Flutter + native หรือ on-device AI โดยทั่วไป