В предыдущей статье мы рассказали, почему для тестовой ветки БОЛТУНа выбрали 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 больше интерфейсных состояний, графики и веб-логики. Зато результат отвечает на практический вопрос пользователя: сколько занимает не абстрактный фреймворк, а программа, которую он действительно запускает рядом с игрой.

Тестовый компьютер

Замер проходил на нашем обычном рабочем ноутбуке, а не на специально подготовленном стенде.

Точную версию Evergreen WebView2 во время первого прогона мы не записали. Это наш недочёт и одна из причин, почему результат нельзя переносить на все компьютеры. Версия системного WebView обновляется отдельно от приложения и тоже должна попадать в протокол следующего замера.

Как мы выровняли условия

Обе версии запускались по очереди. Состояние было одинаковым:

• открыто основное окно;

• загружено пустое лобби;

• пользователь не находится в комнате;

• голос не передаётся;

• радио выключено;

• после запуска клиенту дали несколько секунд успокоиться.

Для старого БОЛТУНа этого достаточно: у него один основной процесс.

С Tauri сложнее. Если посмотреть только на БОЛТУН 2.exe, получится красивая, но неправильная цифра. Интерфейс живёт в дочерних msedgewebview2.exe, поэтому мы собирали всё дерево процессов от корневого EXE и суммировали его показатели.

Основной показатель в нашей таблице — сумма частной памяти процессов. Отдельно мы смотрели рабочие наборы. Это важно, потому что Working Set включает и частные, и разделяемые страницы. Если без пояснения сложить рабочие наборы нескольких процессов, часть общих страниц можно посчитать больше одного раза.

Результат

Самое забавное обнаружилось в первой строке. Новый проект оказался меньше по количеству кода, но значительно больше по количеству процессов и памяти.

То есть формула «больше строк — тяжелее программа» здесь не работает вообще.

Откуда взялись 20 тысяч строк

Пользователь видит один клиент, но БОЛТУН 2 уже состоит из нескольких частей. Мы посчитали весь исполняемый код проекта, при этом общий код веба и Desktop учитывали один раз.

В подсчёт не входили картинки, шрифты, музыка, документация, готовые 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:

1. Главное окно приложения.

2. Скрытое окно игрового оверлея.

Пользователь ещё даже не вошёл в комнату, оверлей ему не нужен, а второй интерфейсный контур уже существует и участвует в замере.

Именно поэтому бенчмарк оказался полезен не только для статьи. Он дал конкретную задачу: не создавать оверлей при запуске.

Было:

запуск → главное окно + скрытый оверлей → пустое лобби

Должно быть:

запуск → только главное окно
                    ↓
               вход в комнату
                    ↓
              создание оверлея
                    ↓
               выход из комнаты
                    ↓
              закрытие оверлея

Возможно, оверлей вообще не должен быть 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 и обслуживать отдельной системой отрисовки.

Получился обычный инженерный обмен:

Бенчмарк не заставил нас немедленно удалить Tauri-ветку. Он изменил критерий успеха.

Раньше вопрос звучал так:

Получится ли перенести новый интерфейс в Tauri?

Теперь он звучит иначе:

Сможем ли мы оставить удобство Tauri, но не держать лишние WebView и окна, когда пользователь просто играет?

Что дальше

Дальше будем экспериментировать со стримом. Пустое лобби показало базовую цену интерфейса, но настоящее приложение почти никогда не живёт только в таком состоянии. Нам интересно, как Tauri и WebView2 поведут себя при длительном непрерывном аудиопотоке: когда стрим запускается, играет часами, переподключается после обрыва, а само окно в это время открывается, закрывается и уходит в трей.

Для этого у нас уже есть живой поток БОЛТУН РАДИО. На нём можно проверить не демонстрационный звук на несколько секунд, а обычную долгую работу: не растёт ли память со временем, не остаются ли после переподключений старые аудиопроцессы и не начинает ли интерфейс влиять на воспроизведение.

Это будет отдельный эксперимент и отдельная история. Сначала хотим заставить стрим стабильно прожить рядом с игрой столько же, сколько обычно живёт сам БОЛТУН.

Главный вывод

До замера мы знали, что WebView тяжелее Win32. После замера мы узнали, насколько он тяжелее в нашем приложении и почему.

Старый БОЛТУН в пустом лобби занял около 2,2 МБ собственной памяти. БОЛТУН 2 на Tauri — около 128 МБ вместе со всем деревом процессов. При этом новый проект содержит меньше строк кода и даёт гораздо более удобную основу для развития интерфейса.

Значит ли это, что 128 МБ приемлемы? Пока нет. Для программы рядом с игрой нельзя решить за пользователя, что ему не жалко памяти. Сначала нужно убрать заранее созданный оверлей, проверить настоящий режим трея и повторить замеры по всем рабочим сценариям.

Если после этого Tauri останется слишком тяжёлым, у нас всё ещё есть смешанный вариант: новый основной интерфейс на Tauri, а PTT, трей, звук и оверлей — нативные. Или возврат к полностью нативной оболочке, если цифры не уложатся в разумный бюджет.

Фреймворк здесь не религия. Это инструмент со своей ценой. И лучше узнать её не после релиза, а на тестовой ветке.

Проект: БОЛТУН

Ещё раз спасибо всем, кто прочитал предыдущую статью и заставил нас перейти от рассуждений к цифрам.

Команда: PAPA DAN — разработчик; Alexme — главный тестировщик; Mihanz, San4o и A1ex — участники командных проверок и обратной связи.