การเปิดตัว macOS 26 Tahoe เวอร์ชันล่าสุดของ Apple ได้นำมาซึ่งปัญหาด้านประสิทธิภาพที่สำคัญซึ่งส่งผลกระทบต่อแอปพลิเคชันยอดนิยมอย่าง Discord, VS Code, Slack และซอฟต์แวร์อื่นๆ ที่ใช้ Electron ผู้ใช้รายงานว่าระบบกระตุกและช้าลงทั้งระบบเมื่อแอปพลิเคชันเหล่านี้ทำงาน โดยการใช้งาน GPU เพิ่มขึ้นอย่างมากแม้ในงานง่ายๆ เช่น การเลื่อนหน้าต่างหรือการเลื่อนหน้า
ปัญหาดูเหมือนจะเกิดจากการตัดสินใจของ Electron ที่จะแทนที่ private API ของ macOS ที่เรียกว่า _cornerMask ซึ่งใช้สำหรับสร้างมุมที่เรียบสำหรับ vibrant views ในแอปพลิเคชัน เมื่อ Apple เปลี่ยนวิธีการทำงานของ private API นี้ใน macOS 26 ได้สร้างปฏิสัมพันธ์ที่ไม่คาดคิดซึ่งทำให้กระบวนการ WindowServer ของระบบใช้ทรัพยากร GPU มากเกินไป
แอปพลิเคชันที่ได้รับผลกระทบ:
- Discord
- VS Code
- Slack
- Ferdium
- Bitwarden Desktop
- SiYuan
- DeltaChat
- Yandex Music
- Jitsi Meet
- Cursor IDE
สาเหตุหลัก: การใช้ Private API ในทางที่ผิด
การตรวจสอบทางเทคนิคเผยให้เห็นว่า Electron กำลังแทนที่ private API _cornerMask ของ Apple เพื่อใช้ corner masks แบบกำหนดเองกับ vibrant views การแทนที่นี้รบกวนไปป์ไลน์การเรนเดอร์เงาใหม่ของ macOS 26 ทำให้ระบบต้องใช้วิธีการเรนเดอร์ที่ไม่มีประสิทธิภาพ ปัญหาจะรุนแรงขึ้นเมื่อมีแอปพลิเคชัน Electron หลายตัวทำงานพร้อมกัน โดยผู้ใช้บางคนรายงานว่าการใช้งาน GPU เพิ่มขึ้นถึง 100% และพัดลมหมุนด้วยความเร็วสูงสุด
Private APIs เป็นฟังก์ชันระบบภายในที่ Apple กำหนดให้เป็นพื้นที่ต้องห้ามสำหรับนักพัฒนา เนื่องจากสามารถเปลี่ยนแปลงได้โดยไม่แจ้งให้ทราบล่วงหน้าระหว่างการอัปเดตระบบ
ผลกระทบต่อประสิทธิภาพ:
- การใช้งาน GPU เพิ่มขึ้นจาก 0% เป็น 25% เมื่อเปิดแอป Electron หนึ่งตัว
- การใช้งาน GPU ขึ้นถึง 100% เมื่อเปิดแอป Electron หลายตัวพร้อมกัน
- ระบบ UI ทั้งหมดช้าลงและกระตุก
- ความเร็วพัดลมเพิ่มขึ้นสูงสุด
- ปัญหาจะหายไปเมื่อย่อแอปลง
การถกเถียงในชุมชนเกี่ยวกับความรับผิดชอบ
ชุมชนนักพัฒนาแบ่งออกเป็นสองฝ่ายเกี่ยวกับผู้ที่ต้องรับผิดชอบต่อปัญหานี้ บางคนโต้แย้งว่านักพัฒนา Electron ไม่ควรใช้ private APIs เลย เนื่องจาก Apple เตือนอย่างชัดเจนเกี่ยวกับการปฏิบัตินี้ คนอื่นๆ โต้แย้งว่า Apple ควรทดสอบการอัปเดตระบบปฏิบัติการของตนกับแอปพลิเคชันที่ใช้กันอย่างแพร่หลายให้ดีกว่านี้ก่อนเปิดตัว
ฉันไม่เข้าใจว่าอะไรผ่านเข้าไปในใจของนักพัฒนา เมธอดถูกทำเครื่องหมายว่าเป็น private มีเอกสารระบุว่าไม่ควรใช้โดยนักพัฒนา เอกสารเพิ่มเติมบอกว่าการใช้งานอาจทำให้แอปพลิเคชันของคุณเสียหายในรูปแบบแปลกๆ ในปัจจุบันหรืออนาคต
สถานการณ์นี้เน้นย้ำถึงความตึงเครียดที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ระหว่างการปฏิบัติตามแนวทางอย่างเป็นทางการและการบรรลุฟังก์ชันการทำงานที่ต้องการเมื่อ public APIs ไม่ได้ให้โซลูชันที่เพียงพอ
วิธีแก้ไขชั่วคราวและโซลูชัน
มีการแก้ไขชั่วคราวหลายวิธีที่เกิดขึ้นจากชุมชน สำหรับแอปพลิเคชันที่ใช้ Chrome ผู้ใช้สามารถใช้คำสั่งเพื่อปิดใช้งานฟีเจอร์ autofill บางอย่างที่ดูเหมือนจะมีปฏิสัมพันธ์ที่ไม่ดีกับปัญหาการเรนเดอร์ อย่างไรก็ตาม วิธีแก้ไขนี้มาพร้อมกับคำเตือนว่าอาจทำให้ฟังก์ชันการทำงานอื่นๆ เสียหายในอนาคต
ทีม Electron ได้ยอมรับปัญหาและกำลังทำงานเพื่อแก้ไขอย่างเหมาะสมที่จะลบการแทนที่ private API ของพวกเขาในขณะที่ยังคงรักษารูปลักษณ์ที่ผู้ใช้คาดหวัง Apple ก็ได้รับทราบปัญหาผ่านระบบ feedback ของพวกเขาแล้ว แม้ว่าพวกเขาจะยืนยันว่าความรับผิดชอบอยู่ที่นักพัฒนาที่เลือกใช้ APIs ที่ไม่ได้รับการสนับสนุน
รายละเอียดทางเทคนิค:
- สาเหตุหลัก: Electron แทนที่ API ส่วนตัว
_cornerMaskของ AppKit - ระบบที่ได้รับผลกระทบ: macOS 26 Tahoe RC บน Apple Silicon (M1, M4)
- เวอร์ชัน Electron: 37.3.1
- วิธีแก้ไขชั่วคราว:
defaults write com.google.Chrome NSAutoFillHeuristicControllerEnabled -bool false
ผลกระทบต่อผู้ใช้และแอปพลิเคชัน
การลดลงของประสิทธิภาพส่งผลกระทบต่อแอปพลิเคชันเพื่อการทำงานที่ใช้กันมากที่สุดบน macOS ผู้ใช้ที่มี MacBook Pro รุ่น M1 และ M4 รายงานว่าแม้แต่การโต้ตอบระบบพื้นฐานก็กลายเป็นเรื่องช้าๆ เมื่อแอปพลิเคชันอย่าง Discord หรือ VS Code เปิดอยู่และไม่ได้ย่อเก็บ น่าสนใจที่การย่อเก็บแอปพลิเคชันที่ได้รับผลกระทบจะแก้ไขปัญหาประสิทธิภาพทันที ซึ่งบ่งชี้ว่าปัญหาเกี่ยวข้องโดยเฉพาะกับการเรนเดอร์หน้าต่างที่ทำงานอยู่
สถานการณ์นี้เป็นเครื่องเตือนใจถึงความเสี่ยงที่เกี่ยวข้องกับการใช้ฟีเจอร์ระบบที่ไม่มีเอกสาร แม้ว่าจะให้ฟังก์ชันการทำงานที่ดูเหมือนจำเป็นก็ตาม ในขณะที่การใช้ private API ของ Electron มีจุดประสงค์เพื่อปรับปรุงประสบการณ์ทางภาพ แต่ในท้ายที่สุดกลับสร้างการพึ่งพาที่เปราะบางซึ่งพังเมื่อ Apple อัปเดตสถาปัตยกรรมระบบของพวกเขา
อ้างอิง: Electron-based apps cause a huge system-wide lag on macOS 26 #48311