ทำไมเราเลือกเนทีฟแทน Electron (และจะเลือกอีกครั้ง)

ทุกคนบอกให้เราใช้ Electron เขียนครั้งเดียว รันได้ทุกที่ เคลื่อนไหวเร็ว เราทำตรงข้าม — SwiftUI บน Apple, Jetpack Compose บน Android, C++/WinRT บน Windows, Metal และ Vulkan ดิบ ๆ ในที่ที่เราต้องการพิกเซลตามนาฬิกา นี่คือสิ่งที่เราเรียนรู้จากการสร้างไคลเอนต์เนทีฟสี่ตัวสำหรับผลิตภัณฑ์เดียว

ทางง่ายเทียบกับทางที่ถูก

เมื่อคุณบอกคนว่ากำลังสร้างแอปรีโมทเดสก์ท็อปตั้งแต่ศูนย์ในปี 2024 คำถามแรกเสมอคือ: "ทำไมไม่ใช้ Electron ล่ะ?"

เป็นคำถามที่สมเหตุสมผล Electron ขับเคลื่อนแอปที่ประสบความสำเร็จที่สุดบางตัวบนโลก — VS Code, Slack, Discord, ตัวห่อเดสก์ท็อปของ Figma มันให้คุณเขียนครั้งเดียวแล้วปรับใช้ได้ทุกที่ นักพัฒนาเว็บของคุณกลายเป็นนักพัฒนาเดสก์ท็อปข้ามคืน ข้อได้เปรียบด้านเวลาออกสู่ตลาดเป็นของจริง

เราดูตัวเลข ชั่งข้อแลกเปลี่ยน และเลือกทางที่ยากที่สุดเท่าที่เป็นไปได้: เนทีฟเต็มรูปแบบบนทุกแพลตฟอร์ม SwiftUI บน iOS และ macOS Jetpack Compose บน Android C++/WinRT บน Windows Metal สำหรับเรนเดอร์บน Apple Vulkan บนทุกอย่างที่เหลือ เซิร์ฟเวอร์ Go แบบกำหนดเองที่แกนกลาง

ไม่ใช่เพราะเราชอบทุกข์ แม้บางวันจะรู้สึกอย่างนั้น แต่เพราะสำหรับแอปแบบนี้ เนทีฟไม่ใช่ความฟุ่มเฟือย แต่เป็นข้อกำหนด

ภาษีของ Electron เป็นของจริง

เริ่มจากสิ่งที่ Electron เป็นจริง ๆ: หน้าต่างเบราว์เซอร์ Chromium ที่แสร้งเป็นแอปเดสก์ท็อป นั่นไม่ใช่การวิจารณ์ — เป็นสถาปัตยกรรม และสำหรับแอปจำนวนมาก มันก็ใช้ได้ดี

แต่สำหรับรีโมทเดสก์ท็อปล่ะ? คุณสตรีมพิกเซลจากคอมพิวเตอร์อีกเครื่องและเรนเดอร์แบบเรียลไทม์ ขณะจับทุกเหตุการณ์อินพุตแล้วส่งกลับ ความหน่วงไม่ใช่ของแถม แต่คือผลิตภัณฑ์ทั้งหมด

นี่คือสิ่งที่เราวัดได้เมื่อสร้างต้นแบบทั้งสองแนวทาง:

• หน่วยความจำ — ไคลเอนต์เนทีฟขณะคงที่: ~45 MB ต้นแบบ Electron: ~380 MB ต่างกัน 8.4 เท่าตอนว่าง ก่อนที่แอปใดจะเริ่มถอดรหัสแม้เฟรมเดียว
• การเริ่มเย็น — แอป macOS เนทีฟเริ่มเย็นภายใน 200 มิลลิวินาที ต้นแบบ Electron ใช้เวลา 2 ถึง 3 วินาที สำหรับเครื่องมือที่คุณเปิดยี่สิบครั้งต่อวัน มันสะสมเป็นแรงเสียดทานจริง
• แบตเตอรี่ — บน Mac ที่ใช้แบตเตอรี่ บิลด์ Electron กินวัตต์ราว 3 เท่าระหว่างการเชื่อมต่อที่ไม่ได้ใช้งาน Chromium ไม่หลับอย่างประหยัด

380 MB ไม่ใช่ว่า Electron บวม แต่เป็น Chromium ทำหน้าที่ของมัน — V8, โปรเซส GPU, โปรเซสยูทิลิตี้, เอนจินเบราว์เซอร์ทั้งตัว เป็นงานวิศวกรรมที่น่าประทับใจ แต่เป็นงานวิศวกรรมที่ออกแบบมาสำหรับปัญหาอื่น

เฟรมสำคัญกว่าฟีเจอร์

รีโมทเดสก์ท็อปเป็นหนึ่งในไม่กี่หมวดแอปที่ ทุกเฟรมสำคัญ หลุดหนึ่งเฟรมผู้ใช้รู้สึก เพิ่มความหน่วงอินพุต 16 มิลลิวินาที นักออกแบบวาดเส้นโค้งเรียบไม่ได้ เพิ่ม 32 มิลลิวินาที เกมเมอร์เล่นไม่ได้

ด้วยการเรนเดอร์เนทีฟ เราคุยกับ GPU โดยตรง บนแพลตฟอร์ม Apple VideoToolbox ให้เราเข้าถึงการถอดรหัสวิดีโอด้วยฮาร์ดแวร์โดยตรง เราดึงเฟรม H.265 จากเครือข่าย ถอดรหัสด้วยฮาร์ดแวร์ และแสดงผล — โดยเฟรมไม่เคยแตะหน่วยความจำหลัก ไปป์ไลน์จากถอดรหัสถึงแสดงผลทำงานต่ำกว่า 4 มิลลิวินาทีบน Mac สมัยใหม่

ใน Electron เฟรมเดียวกันเดินทางผ่านคอมโพซิเตอร์ของ Chromium ผ่านบริดจ์ IPC ถูกวาดโดย Skia แล้วถูกประกอบอีกครั้งโดยระบบปฏิบัติการ ทุกฮอปเพิ่มความหน่วง ทุกฮอปเพิ่มจิตเตอร์ และจิตเตอร์ — จังหวะเฟรมที่ไม่สม่ำเสมอ — คือสิ่งที่ทำให้รีโมทเดสก์ท็อปรู้สึกผิดปกติแม้ FPS เฉลี่ยดูปกติ

เราไม่ได้เลือกเนทีฟเพราะเป็นพวกบริสุทธิ์นิยม เราเลือกเพราะฟิสิกส์ของปัญหาเรียกร้อง — การประมวลผลราว 8 มิลลิวินาทีบน LAN (ที่เหลือคือจังหวะรีเฟรช 60 Hz ของจอคุณเอง) ไม่เหลือที่ให้เบราว์เซอร์อยู่ตรงกลาง

บัญชีความสามารถ เนทีฟเทียบเว็บ

การถกเถียง Electron เทียบเนทีฟมักติดอยู่ที่ความรู้สึก เราจึงเขียนความสามารถของระบบปฏิบัติการเจ็ดอย่างที่ Remio พึ่งพาทุกวินาทีของทุกเซสชัน แล้วถามตรง ๆ ว่า: แต่ละอย่างเป็นอย่างไรภายใต้แต่ละรันไทม์?

แต่ละแถวคือฟีเจอร์ที่เราส่งมอบวันนี้ แต่ละ — ในคอลัมน์เว็บคือวิธีเลี่ยงที่เราต้องประดิษฐ์ เขียนเอกสาร และขอโทษ การเป็นเนทีฟหมายความว่าเราถือความสามารถเหล่านั้นเป็นพื้นฐานแทนที่จะเป็น polyfill

การเป็นพลเมืองที่ดีของแพลตฟอร์ม

นี่คือสิ่งที่กลุ่มเขียนครั้งเดียวรันได้ทุกที่แทบไม่พูดถึง: ผู้ใช้บอกได้

พวกเขาบอกได้เมื่อแอปไม่เคารพการเปลี่ยนผ่านโหมดมืดของระบบ เมื่อฟิสิกส์การเลื่อนรู้สึกผิดเล็กน้อย เมื่อแอปไม่ปรากฏใน Spotlight หรือไม่จัดการหน้าต่างของ macOS อย่างเหมาะสม เมื่อเมนูบริบทดูเหมือนหน้าเว็บแทนเมนูเนทีฟ

สิ่งเหล่านี้ไม่ใช่ของแถม แต่คือความต่างระหว่างแอปที่คนทนกับแอปที่คนรัก บน iOS สำคัญเป็นพิเศษ — การตรวจสอบของ App Store จะปฏิเสธแอปที่รู้สึกไม่เนทีฟ และสมควรแล้ว

ด้วย SwiftUI เราได้ทั้งหมดนี้ฟรี Dynamic Type, การช่วยการเข้าถึง VoiceOver, แฮปติกของระบบ, มัลติทาสก์บน iPad, คีย์ลัดบน Mac เราไม่ได้สร้างฟีเจอร์ของแพลตฟอร์มซ้ำ เราใช้มัน

ต้นทุนก็เป็นของจริงเช่นกัน

ขอซื่อตรงเรื่องข้อเสีย: การเป็นเนทีฟแพง ไม่ใช่เป็นเงิน — แต่เป็นเวลาและความซับซ้อน

เราดูแลโค้ด UI สี่ชุด เลเยอร์เครือข่ายและโคเดกของเราใช้ร่วมกัน (Go สำหรับสัญญาณ C++ สำหรับโปรโตคอลสตรีมมิ่ง) แต่ทุกพิกเซลที่คุณเห็นบนหน้าจอเป็นโค้ดเฉพาะแพลตฟอร์ม ฟีเจอร์ที่ใช้หนึ่งวันใน Electron ใช้เวลาเราสามถึงห้าวัน เพราะเราสร้างสี่ครั้ง ปรับให้เหมาะกับแต่ละแพลตฟอร์ม

เรามีสัปดาห์ที่แอนิเมชันเดียวทำงานสวยงามบน iOS พังบน Android และกระตุกบน Windows เมทริกซ์การดีบักโหดมาก

แต่สิ่งที่เราเรียนรู้คือ: ทางที่ยากที่สุดกับทางที่ถูกมักเป็นทางเดียวกัน ผู้ใช้ของเราไม่รู้หรือไม่สนใจสถาปัตยกรรมของเรา พวกเขารู้ว่า Remio รู้สึกเร็ว รู้สึกถูก และไม่กินแบตเตอรี่ของพวกเขาเป็นอาหารเช้า

จะทำอีกครั้งไหม

โดยไม่ลังเล

แนวทางเนทีฟให้ประสิทธิภาพที่ Electron โดยพื้นฐานแล้วเทียบไม่ได้สำหรับกรณีใช้งานนี้ ให้แอปที่รู้สึกว่าเป็นส่วนหนึ่งของแต่ละแพลตฟอร์ม ให้พื้นที่หน่วยความจำต่ำกว่า 45 MB แทน 380 MB ให้การประมวลผลราว 8 มิลลิวินาทีบน LAN (ที่เหลือคือจังหวะรีเฟรช 60 Hz ของจอคุณเอง) ขณะที่คู่แข่งที่ห่อด้วยเบราว์เซอร์อยู่เหนือ 60 มิลลิวินาที

ที่สำคัญที่สุด มันให้คูเมืองทางเทคนิค การสร้างเนทีฟข้ามสี่แพลตฟอร์มยากพอที่คู่แข่งส่วนใหญ่จะไม่ทำ ความยากนั้นคือข้อได้เปรียบของเรา

หมวดรีโมทเดสก์ท็อปถูกครอบงำโดยเว็บแอปที่ห่อด้วย Electron และแอปเนทีฟรุ่นเก่าที่ไม่ได้อัปเดตอย่างมีความหมายมาหลายปี มีที่ว่างสำหรับสิ่งที่ทั้งทันสมัยและเนทีฟ — สิ่งที่สร้างจากศูนย์โดยคำนึงถึงฮาร์ดแวร์ปัจจุบัน

นั่นคือ Remio สร้างด้วยวิธียาก เพราะบางสิ่งคุ้มค่าที่จะทำให้ถูก