เอกสารทางเทคนิค

เอกสารนี้ให้มุมมองเชิงลึกเกี่ยวกับการออกแบบสถาปัตยกรรม การเลือกเทคโนโลยี และตรรกะการนำไปใช้ของคุณสมบัติหลักใน WSL Dashboard สำหรับนักพัฒนาและผู้ใช้ขั้นสูงที่ต้องการมุมมองทางเทคนิค

1. ภาพรวมสถาปัตยกรรม

WSL Dashboard ใช้สถาปัตยกรรม UI แบบ reactive ขับเคลื่อน + งาน backend แบบอะซิงโครนัส แบบคลาสสิก โดยใช้ประโยชน์จากระบบประเภทและแบบจำลองความเป็นเจ้าของของ Rust เพื่อรับประกันความปลอดภัยของหน่วยความจำและประสิทธิภาพการทำงานพร้อมกันสูง

คอมโพเนนต์หลัก

• Frontend (UI): สร้างบนอินเทอร์เฟซแบบประกาณ์ Slint เธรด UI รับผิดชอบการเรนเดอร์และการโต้ตอบกับผู้ใช้
• Backend (Runtime): สร้างบน runtime แบบอะซิงโครนัส Tokio รับผิดชอบการdispatch และดำเนินการคำสั่งระบบ (CLI), I/O ไฟล์ และตัวรับฟังเครือข่าย
• การสื่อสาร: เธรด UI และงานแบบอะซิงโครนัสสื่อสารอย่างมีประสิทธิภาพและปลอดภัยผ่าน Channels (MPSC) และ Shared State (Arc/Mutex/RwLock)

2. เหตุผลทางเทคโนโลยี

ทำไม Rust?

• ประสิทธิภาพ: นามธรรมต้นทุนเป็นศูนย์ คอมไพล์เป็นโค้ดเครื่องเนทีฟ ไม่มีการหยุด GC
• ความปลอดภัยของหน่วยความจำ: ขจัดการล้นบัฟเฟอร์และการแข่งขันของข้อมูลในขั้นตอนการคอมไพล์ — สำคัญสำหรับเครื่องมือที่ทำงานในระดับระบบ (การย้ายดิสก์ การกำหนดค่าเครือข่าย)
• ขนาดไบนารี: เชื่อมต่อการพึ่งพาทั้งหมดแบบสถิตเพื่อสร้างไฟล์ที่ทำงานได้แบบพกพาไฟล์เดียว

ทำไม Slint + Skia?

• ไวยากรณ์แบบประกาณ์: แยกคำอธิบาย UI ออกจากตรรกะ รักษาโค้ดเบสให้สะอาดและบำรุงรักษาได้ง่าย
• การเรนเดอร์ Skia: ใช้ประโยชน์จาก GPU acceleration โดยตรง (ผ่านเอนจิน Skia) ให้ความชัดเจนของข้อความระดับซับพิกเซลและแอนิเมชันที่ลื่นไหล
• ค่าใช้จ่ายต่ำ: เปรียบเทียบกับ Electron หรือ WPF ค่าใช้จ่าย runtime ของ Slint น้อยที่สุด

3. การนำไปใช้ทางเทคนิคหลัก

3.1 การตรวจจับและการแยกวิเคราะห์ Instance WSL

แอปดึงสถานะ instance แบบเรียลไทม์โดยเรียก wsl.exe --list --verbose และแยกวิเคราะห์ผลลัพธ์ (จัดการการเข้ารหัส UTF-16)

• การถอดรหัสระดับต่ำ: เอนโค้ดเดอร์/ดีโค้ดเดอร์ที่กำหนดเองและมีประสิทธิภาพรับประกันการแยกวิเคราะห์ผลลัพธ์ที่ถูกต้องในสภาพแวดล้อม Windows ที่แตกต่างกันด้วยการตั้งค่าภูมิภาคที่แตกต่างกัน
• การซิงโครไนซ์สถานะ: ใช้กลไกซิงโครไนซ์คู่ที่รวมการpolling ปกติกับการอัปเดตที่trigger โดยการดำเนินงาน

3.2 การย้ายอิมเมจดิสก์ (VHDX Move)

คุณสมบัติการย้ายใช้ประโยชน์จากกลไกนำเข้า/ส่งออกของ WSL แต่มีระดับนามธรรมและอะตอมมิกสูง

• การรับประกันธุรกรรม: ก่อนที่การย้ายจะเริ่มต้น แอปจะล็อคดิสทริบิวชันเป้าหมายผ่าน Mutex เพื่อป้องกันการทำงานพร้อมกันที่อาจทำให้ข้อมูลเสียหาย
• การลงทะเบียนอัตโนมัติ: หลังจากการย้ายเสร็จสิ้น แอปจะเปลี่ยนเส้นทาง VHDX และลงทะเบียนดิสทริบิวชันใหม่โดยอัตโนมัติ — ไม่ต้องการการแทรกแซงด้วยตนเอง

3.3 การส่งต่อพอร์ตและการทำงานอัตโนมัติของไฟร์วอลล์

คุณสมบัติเครือข่ายเหนือกว่าการเรียก netsh interface portproxy อย่างง่าย

• การจัดการวงจรชีวิตกฎ: แอปตรวจจับกฎไฟร์วอลล์ที่มีอยู่โดยอัตโนมัติ เมื่อผู้ใช้สร้างกฎการส่งต่อ มันจะสร้างข้อยกเว้นขาเข้าผ่าน Windows API หรือ CLI พร้อมกัน
• การแปล IP อัตโนมัติ: โดยการแยกวิเคราะห์ผลลัพธ์ของ wsl hostname -I มันจะแมป IP เครือข่ายเสมือนระหว่างโฮสต์และ instance โดยอัตโนมัติ

3.4 การผสานรวม USBIP

ใช้ประโยชน์จากอินเทอร์เฟซคำสั่ง usbipd-win

• การจัดการการเพิ่มสิทธิ์: การดำเนินการผูกต้องการสิทธิ์ของผู้ดูแลระบบ Backend ใช้การส่งต่อคำขอการเพิ่มสิทธิ์ UAC อย่างสง่างาม
• สถานะเครื่อง: รักษาสถานะเครื่องการเชื่อมต่ออุปกรณ์ USB ภายในเพื่อให้แน่ใจว่าสามารถตรวจสอบย้อนกลับได้เต็มรูปแบบของการดำเนินการ Attach/Detach

3.5 การตรวจสอบทรัพยากรและรอยเท้าขั้นต่ำ

แอปตรวจสอบการใช้ทรัพยากรของตัวเองโดยเรียก Windows API ดั้งเดิม (เช่น GetProcessMemoryInfo)

• ประสิทธิภาพสูงสุด: ในโหมดเทรย์เงียบ แอปจะปล่อยทรัพยากร UI ที่ไม่จำเป็นอย่างแข็งขัน สำหรับชุดอักขระมาตรฐาน (เช่น ภาษาอังกฤษ) การใช้หน่วยความจำอาจต่ำถึง 10MB; สำหรับชุดอักขระที่ซับซ้อน (เช่น CJK) จะอยู่ที่ประมาณ 38MB เนื่องจากแคชเรนเดอร์ฟอนต์ที่ใหญ่กว่า

4. การวัดประสิทธิภาพ

เมตริก	เป้าหมาย / วัดได้	แนวทางการเพิ่มประสิทธิภาพ
เวลาเริ่มต้น	< 500ms	อินเทอร์เฟซ Slint ที่คอมไพล์ไว้ล่วงหน้า ลดการแยกวิเคราะห์ runtime
หน่วยความจำพื้นฐาน (เทรย์)	~10MB	ลดความถี่ polling พื้นหลัง ปล่อยแคชเรนเดอร์ตามความต้องการ
การใช้ CPU (idle)	< 0.1%	แบบจำลองขับเคลื่อนเหตุการณ์ Windows ไม่มี busy-loop polling
อัตราเฟรมเรนเดอร์	60 FPS	Subpixel anti-aliased rendering ของ Skia GPU

5. ตรรกะการdispatch งาน backend

เพื่อให้แน่ใจว่า UI ตอบสนอง การดำเนินการที่ใช้เวลานานทั้งหมด (เช่น การส่งออก VHDX) จะถูกdispatch เป็นงานแบบอะซิงโครนัส:

1. การห่อหุ้มคำขอ: เธรด UI ห่อหุ้มการกระทำของผู้ใช้เป็นข้อความ Command
2. ช่องทางข้อความ: ส่งไปยังตัวจัดการงานพื้นหลังผ่าน tokio::sync::mpsc
3. Callback สถานะ: เมื่องานพื้นหลังเสร็จสิ้น จะอัปเดต UI ผ่าน callback หรือสถานะที่ใช้ร่วมกัน การออกแบบนี้รับประกันว่าแม้ในขณะประมวลผลงานสำรองข้อมูลหลายกิกะไบต์ อินเทอร์เฟซยังคงตอบสนองต่ออินพุตของผู้ใช้อย่างเต็มที่

6. การพิจารณาด้านความปลอดภัย

• การดำเนินการแบบอะตอมมิก: การตรวจสอบก่อนบินถูกนำไปใช้สำหรับการดำเนินการที่สำคัญในการยกเลิกการลงทะเบียนและการย้าย instance
• การจัดการการเพิ่มสิทธิ์ UAC: สิทธิ์ที่เพิ่มขึ้นจะถูกร้องขอเมื่อจำเป็นเท่านั้น (เช่น การผูกอุปกรณ์ USB) ตามหลักการสิทธิ์ขั้นต่ำ
• การจัดเก็บในเครื่อง: การกำหนดค่าจะถูกบันทึกเฉพาะในไดเรกทอรีในเครื่อง ~\.wsldashboard โดยไม่มีการซิงค์คลาวด์ใดๆ เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้