В предыдущей статье мы рассказали, почему для тестовой ветки БОЛТУНа выбрали Tauri 2 и при этом решили не выбрасывать работающие нативные части приложения.
Спасибо всем, кто прочитал статью и дал ценные мысли. Один вопрос оказался особенно полезным: нужен ли вообще красивый интерфейс программе, которая большую часть времени висит в трее рядом с игрой? И если новый клиент начнёт занимать 200 МБ, не выберет ли игрок более лёгкую альтернативу?
Можно было ответить, что в 2026 году сто мегабайт — мелочь. Можно было вспомнить, что Tauri использует системный WebView и не кладёт собственный Chromium рядом с EXE. Можно было долго спорить о том, что важнее: память или скорость разработки.
Вместо этого мы запустили обе версии и посмотрели на цифры.
Спойлер: в пустом лобби старый Win32-клиент занял около 2,2 МБ собственной памяти, а новый клиент на Tauri вместе с деревом WebView2 — около 128 МБ.
Разница получилась примерно в 58 раз. Это не универсальный приговор Tauri и не лабораторный тест всех GUI-фреймворков. Это один реальный голосовой клиент, один компьютер и один одинаковый сценарий. Но даже такой замер оказался полезнее наших прежних рассуждений: он сразу показал, где именно новый интерфейс расходует ресурсы и что нужно менять первым.
Что именно мы сравнивали
В левом углу был БОЛТУН 0.4.44 — рабочий клиент на C++ и Win32. Один EXE, нативные окна, трей, глобальный Push-to-talk, WASAPI, Opus и игровой оверлей.
В правом — БОЛТУН 2 0.0.14 на Tauri, Rust и TypeScript. Интерфейс работает в Microsoft Edge WebView2, а рядом живут комнаты, голос, радио, настройки и анимации.
Это не сравнение двух пустых окон «Hello, world». И не микробенчмарк Win32 API против одной кнопки в WebView. Мы сравнивали два поколения настоящего приложения в том виде, в котором ими пользуется человек.
У такого подхода есть минус: версии не идентичны по функциям. В БОЛТУНЕ 2 больше интерфейсных состояний, графики и веб-логики. Зато результат отвечает на практический вопрос пользователя: сколько занимает не абстрактный фреймворк, а программа, которую он действительно запускает рядом с игрой.
Тестовый компьютер
Замер проходил на нашем обычном рабочем ноутбуке, а не на специально подготовленном стенде.
Компонент | Значение |
|---|---|
ОС | Windows 11, build 26200 |
Процессор | Intel Core i5-11400H, 6 ядер / 12 потоков |
Оперативная память | 15,7 ГБ доступной физической памяти |
Графика | Intel UHD + NVIDIA GeForce RTX 3050 Ti Laptop |
Экран | 1920×1080, 144 Гц |
Масштаб Windows | 100% |
Точную версию Evergreen WebView2 во время первого прогона мы не записали. Это наш недочёт и одна из причин, почему результат нельзя переносить на все компьютеры. Версия системного WebView обновляется отдельно от приложения и тоже должна попадать в протокол следующего замера.
Как мы выровняли условия
Обе версии запускались по очереди. Состояние было одинаковым:
открыто основное окно;
загружено пустое лобби;
пользователь не находится в комнате;
голос не передаётся;
радио выключено;
после запуска клиенту дали несколько секунд успокоиться.
Для старого БОЛТУНа этого достаточно: у него один основной процесс.
С Tauri сложнее. Если посмотреть только на БОЛТУН 2.exe, получится красивая, но неправильная цифра. Интерфейс живёт в дочерних msedgewebview2.exe, поэтому мы собирали всё дерево процессов от корневого EXE и суммировали его показатели.
Основной показатель в нашей таблице — сумма частной памяти процессов. Отдельно мы смотрели рабочие наборы. Это важно, потому что Working Set включает и частные, и разделяемые страницы. Если без пояснения сложить рабочие наборы нескольких процессов, часть общих страниц можно посчитать больше одного раза.
Результат
Показатель | БОЛТУН 0.4.44, Win32 | БОЛТУН 2 0.0.14, Tauri | Разница |
|---|---|---|---|
Строки исполняемого кода | 22 381 | 20 284 | БОЛТУН 2 на 9,4% меньше |
Размер текстового кода | 0,77 МБ | 0,75 МБ | почти одинаково |
Исходники с рабочими ассетами | 4,75 МБ | 7,27 МБ | +53% |
Windows EXE | 16,19 МБ | 26,47 МБ | +64% |
Полная папка Windows | 19,78 МБ | 26,62 МБ | +35% |
Частная память в пустом лобби | около 2,2 МБ | около 128 МБ | примерно в 58 раз больше |
Процессов | 1 | 9 | основной процесс и WebView2 |
Самое забавное обнаружилось в первой строке. Новый проект оказался меньше по количеству кода, но значительно больше по количеству процессов и памяти.
То есть формула «больше строк — тяжелее программа» здесь не работает вообще.
Откуда взялись 20 тысяч строк
Пользователь видит один клиент, но БОЛТУН 2 уже состоит из нескольких частей. Мы посчитали весь исполняемый код проекта, при этом общий код веба и Desktop учитывали один раз.
Часть БОЛТУНа 2 | Строк |
|---|---|
Общий Desktop + веб-клиент | 6 527 |
Tauri/Rust-оболочка | 233 |
Сервер комнат, голоса и радио | 6 348 |
APK и Android-сервисы | 6 617 |
AudioWorklet и публичный код | 93 |
Точки входа и сборка | 36 |
Главная страница сайта | 430 |
Всего | 20 284 |
В подсчёт не входили картинки, шрифты, музыка, документация, готовые EXE и APK, сторонние библиотеки, node_modules, target и остальные кэши сборки.
Мы не считаем строки кода показателем качества. Здесь эта цифра нужна для другого: показать, что рост памяти пришёл не из-за огромного Rust-бэкенда или сотен тысяч строк TypeScript. Tauri/Rust-оболочка на тот момент занимала всего 233 строки. Основная цена появилась во время выполнения интерфейса.
Почему один EXE превратился в девять процессов
Tauri действительно не кладёт собственный браузерный runtime в папку приложения. Он использует WebView операционной системы; это одна из базовых частей архитектуры Tauri.
Но «не лежит рядом с EXE» не означает «ничего не занимает в памяти».
На Windows интерфейс запускается внутри WebView2. А WebView2 использует многопроцессную модель Edge: отдельный browser process, один или несколько renderer-процессов и вспомогательные процессы для GPU, сети и аудио. Microsoft подробно описывает это в документации по модели процессов WebView2.
В нашем пустом лобби получилось девять процессов. Их число не является константой Tauri: оно меняется в зависимости от количества WebView, происхождения контента, GPU и используемых функций.
Здесь обнаружилась уже наша собственная архитектурная ошибка. В измеренной версии заранее создавались два WebView:
Главное окно приложения.
Скрытое окно игрового оверлея.
Пользователь ещё даже не вошёл в комнату, оверлей ему не нужен, а второй интерфейсный контур уже существует и участвует в замере.
Именно поэтому бенчмарк оказался полезен не только для статьи. Он дал конкретную задачу: не создавать оверлей при запуске.
Было: запуск → главное окно + скрытый оверлей → пустое лобби Должно быть: запуск → только главное окно ↓ вход в комнату ↓ создание оверлея ↓ выход из комнаты ↓ закрытие оверлея
Возможно, оверлей вообще не должен быть WebView. Для небольшого прозрачного click-through окна нативный Win32 по-прежнему выглядит естественнее. Новый основной интерфейс и старый нативный оверлей вполне могут жить в одном приложении.
А откуда тогда взялись 575 МБ
Во время отдельного наблюдения за активным разговором частная память БОЛТУНа 2 выросла примерно до 223 МБ, а сумма рабочих наборов процессов WebView2 доходила до 575 МБ.
Эта цифра выглядит страшнее, но ставить её рядом с 2,2 МБ пустого Win32-клиента было бы нечестно сразу по двум причинам.
Во-первых, сценарии разные. В одном случае открыто пустое лобби, в другом работают комната, голос, дополнительные процессы и интерфейсные состояния.
Во-вторых, сумма Working Set не равна уникальной физической памяти приложения. Рабочий набор включает разделяемые страницы, и при простом сложении процессов они могут учитываться повторно.
Поэтому 575 МБ мы оставили как диагностический сигнал: под нагрузкой WebView2-дерево заметно разрастается. Но в заголовок и основную таблицу вынесли сопоставимый пустой сценарий и частную память.
Позже у сборки 0.0.16 мы увидели около 29 МБ у основного процесса. Очень хотелось сразу объявить победу оптимизации, но полного дерева WebView2 тем же методом в том прогоне не было. Поэтому 29 МБ пока не результат, а напоминание о том, как легко выбрать приятную цифру и сравнить её не с тем показателем.
Значит, Win32 победил?
По памяти, количеству процессов и размеру Windows-папки — да, причём безоговорочно.
Win32-клиенту не нужно поднимать browser process, renderer, GPU helper и аудиосервис интерфейса. Для небольшой программы, которая постоянно живёт рядом с игрой, это серьёзное преимущество.
Но наш выбор фреймворка не состоял из одной строки «кто меньше ест».
На Tauri мы значительно быстрее собираем и меняем интерфейс. Можно повторно использовать TypeScript, CSS, SVG, часть веб-логики и одни и те же визуальные компоненты. Комнаты, настройки, радио и состояния подключения не приходится вручную раскладывать по координатам Win32 и обслуживать отдельной системой отрисовки.
Получился обычный инженерный обмен:
Win32 | Tauri |
|---|---|
минимальный расход памяти | заметная цена WebView2 |
один процесс | многопроцессный интерфейс |
прямой доступ к Windows API | удобный веб-интерфейс и Rust-bridge |
отличный вариант для PTT, трея и оверлея | быстрее развивать большие экраны и состояния |
дороже поддерживать современный сложный UI | проще повторно использовать веб-разработку |
Бенчмарк не заставил нас немедленно удалить Tauri-ветку. Он изменил критерий успеха.
Раньше вопрос звучал так:
Получится ли перенести новый интерфейс в Tauri?
Теперь он звучит иначе:
Сможем ли мы оставить удобство Tauri, но не держать лишние WebView и окна, когда пользователь просто играет?
Что дальше
Дальше будем экспериментировать со стримом. Пустое лобби показало базовую цену интерфейса, но настоящее приложение почти никогда не живёт только в таком состоянии. Нам интересно, как Tauri и WebView2 поведут себя при длительном непрерывном аудиопотоке: когда стрим запускается, играет часами, переподключается после обрыва, а само окно в это время открывается, закрывается и уходит в трей.
Для этого у нас уже есть живой поток БОЛТУН РАДИО. На нём можно проверить не демонстрационный звук на несколько секунд, а обычную долгую работу: не растёт ли память со временем, не остаются ли после переподключений старые аудиопроцессы и не начинает ли интерфейс влиять на воспроизведение.
Это будет отдельный эксперимент и отдельная история. Сначала хотим заставить стрим стабильно прожить рядом с игрой столько же, сколько обычно живёт сам БОЛТУН.
Главный вывод
До замера мы знали, что WebView тяжелее Win32. После замера мы узнали, насколько он тяжелее в нашем приложении и почему.
Старый БОЛТУН в пустом лобби занял около 2,2 МБ собственной памяти. БОЛТУН 2 на Tauri — около 128 МБ вместе со всем деревом процессов. При этом новый проект содержит меньше строк кода и даёт гораздо более удобную основу для развития интерфейса.
Значит ли это, что 128 МБ приемлемы? Пока нет. Для программы рядом с игрой нельзя решить за пользователя, что ему не жалко памяти. Сначала нужно убрать заранее созданный оверлей, проверить настоящий режим трея и повторить замеры по всем рабочим сценариям.
Если после этого Tauri останется слишком тяжёлым, у нас всё ещё есть смешанный вариант: новый основной интерфейс на Tauri, а PTT, трей, звук и оверлей — нативные. Или возврат к полностью нативной оболочке, если цифры не уложатся в разумный бюджет.
Фреймворк здесь не религия. Это инструмент со своей ценой. И лучше узнать её не после релиза, а на тестовой ветке.
Проект: БОЛТУН
Ещё раз спасибо всем, кто прочитал предыдущую статью и заставил нас перейти от рассуждений к цифрам.
Команда: PAPA DAN — разработчик; Alexme — главный тестировщик; Mihanz, San4o и A1ex — участники командных проверок и обратной связи.
