Біла книга

У цьому документі детально розглядаються архітектурний дизайн WSL Dashboard, вибір технологій та логіка реалізації ключових функцій, надаючи розробникам і досвідченим користувачам погляд із технічною глибиною.

1. Огляд архітектури

WSL Dashboard використовує класичну архітектуру «реактивний UI + асинхронні фонові завдання», застосовуючи систему типів і модель володіння Rust для забезпечення безпеки пам'яті та високої продуктивності при паралельній роботі.

Ключові компоненти

• Frontend (UI): декларативний інтерфейс на основі Slint. Потік UI відповідає за відтворення та взаємодію з користувачем.
• Backend (Runtime): асинхронний рантайм на основі Tokio. Відповідає за розподіл і виконання системних команд (CLI), файловий ввід-вивід і мережеве прослуховування.
• Communication: потік UI та асинхронні завдання обмінюються даними через Channel (MPSC) і Shared State (Arc/Mutex/RwLock) — ефективно та потокобезпечно.

2. Обґрунтування вибору технологій

Чому Rust?

• Продуктивність: абстракції з нульовою вартістю, компіляція в нативний машинний код, без пауз через збірник сміття.
• Безпека пам'яті: переповнення буфера та гонки даних виключаються на етапі компіляції — це критично важливо для інструмента, що працює з низькорівневими системними операціями (перенесення дисків, налаштування мережі).
• Розмір бінарного файлу: статичне компонування всіх залежностей дає один портативний виконуваний файл.

Чому Slint + Skia?

• Декларативний синтаксис: опис інтерфейсу відокремлено від логіки, код легко підтримувати.
• Відтворення Skia: безпосереднє використання апаратного прискорення GPU (через двигун Skia) забезпечує субпіксельну чіткість тексту та плавну анімацію.
• Низькі накладні витрати: порівняно з Electron або WPF накладні витрати рантайму Slint мінімальні.

3. Ключові технічні реалізації

3.1 Виявлення та розбір екземплярів WSL

Застосунок отримує стан екземплярів у реальному часі, викликаючи wsl.exe --list --verbose та розбираючи його вивід (з обробкою кодування UTF-16).

• Низькорівневе декодування: власний ефективний кодек гарантує коректний розбір виводу в середовищах Windows із різними регіональними налаштуваннями.
• Синхронізація стану: подвійний механізм — періодичне опитування + синхронізація, ініційована операціями.

3.2 Перенесення образів дисків (VHDX Move)

Функція перенесення використовує механізм імпорту/експорту WSL, але з високим ступенем абстракції та атомарної обробки.

• Гарантія транзакційності: перед початком перенесення застосунок блокує цільовий дистрибутив м'ютексом (Mutex), запобігаючи пошкодженню даних через паралельні операції.
• Автоматична реєстрація: після завершення перенесення застосунок автоматично перенаправляє шлях VHDX і заново реєструє дистрибутив — втручання користувача не потрібне.

3.3 Переадресація портів та автоматизація брандмауера

Мережеві функції — це не просто виклик netsh interface portproxy.

• Управління життєвим циклом правил: застосунок автоматично виявляє наявні правила брандмауера. При створенні переадресації застосунок через Windows API або CLI синхронно створює правило винятку для вхідного трафіку.
• Автоматичне отримання IP: шляхом розбору результату wsl hostname -I автоматично зіставляються віртуальні мережеві IP хоста та екземпляра.

3.4 Інтеграція USBIP

Використовується інтерфейс командного рядка usbipd-win.

• Обробка підвищення прав: операція прив'язки вимагає прав адміністратора; у бекенді реалізовано коректну передачу запиту на підвищення прав через UAC.
• Кінцевий автомат станів: усередині підтримується кінцевий автомат стану підключення USB-пристрою, що забезпечує простежуваність процесів Attach/Detach.

3.5 Моніторинг ресурсів та легкість

Застосунок контролює власне споживання ресурсів, викликаючи нативні API Windows (наприклад, GetProcessMemoryInfo).

• Максимальна легкість: у тихому режимі трею застосунок активно звільняє непотрібні ресурси UI. Для стандартних наборів символів, таких як англійська, споживання пам'яті може становити всього 10 МБ; для складних наборів символів (китайська, японська, корейська) через завантаження великого кешу відтворення шрифтів споживання становить близько 38 МБ.

4. Показники оптимізації продуктивності

Показник	Ціль/факт	Метод оптимізації
Швидкість запуску	< 500 мс	Попередня компіляція інтерфейсу Slint, зменшення розбору під час виконання.
Базова пам'ять (трей)	~10 МБ	Мінімізація частоти фонових опитувань, звільнення кешу відтворення на вимогу.
Навантаження CPU (у спокої)	< 0,1%	Використання подієвої моделі Windows, відсутність порожніх циклів опитування.
Частота кадрів відтворення	60 FPS	Апаратне прискорення Skia на GPU, субпіксельне згладжування.

5. Логіка розподілу фонових завдань

Для забезпечення плавності UI всі трудомісткі операції (наприклад, експорт VHDX) розподіляються через асинхронні завдання:

1. Інкапсуляція запиту: потік UI інкапсулює дію користувача в повідомлення Command.
2. Канал повідомлень: відправлення через tokio::sync::mpsc обробнику фонових завдань.
3. Зворотна передача стану: після завершення фонового завдання UI оновлюється через зворотний виклик або спільний стан. Така конструкція гарантує миттєву реакцію інтерфейсу на кліки користувача навіть при обробці завдань резервного копіювання обсягом у кілька ГБ.

6. Питання безпеки

• Атомарні операції: для ключових операцій видалення та перенесення екземплярів реалізовано попередню перевірку.
• Управління підвищенням прав UAC: права запитуються лише за необхідності (наприклад, при прив'язці USB-пристроїв), дотримується принцип мінімальних привілеїв.
• Локальне зберігання: конфігурація зберігається лише локально в ~\.wsldashboard, без будь-якої хмарної синхронізації, захищаючи конфіденційність користувача.