Расход памяти Electron-софтом: почему растет нагрузка на ПК

При одновременной работе нескольких таких приложений нагрузка на ОЗУ складывается почти линейно.

Причина не в одном неудачном кэше и не в «прожорливом JavaScript» как таковом. Electron — это встраиваемая копия Chromium вместе с Node.js и собственной многопроцессной архитектурой. Каждый продукт приносит на компьютер собственный набор процессов, библиотек и кэшей. Общая память между независимыми приложениями почти не используется.

На ПК с 8 ГБ ОЗУ это быстро превращается в прикладную проблему. Windows начинает активнее перемещать данные в файл подкачки. Переключение между окнами замедляется. Диск получает дополнительную нагрузку. На системах с 16 ГБ запас выше, но несколько браузероподобных клиентов все равно способны занять значительную часть доступной памяти.

Архитектурная ловушка: Chromium внутри каждого приложения

Electron не является легкой оболочкой над уже работающим браузером. Каждая программа обычно запускает собственный экземпляр Chromium. Внутри него работают главный процесс, процессы рендеринга, GPU-процесс, сетевые и служебные компоненты. Конкретный набор зависит от версии Electron, настроек приложения и числа открытых окон.

Главный процесс управляет жизненным циклом приложения и взаимодействует с операционной системой. Renderer process отвечает за интерфейс конкретного окна или веб-содержимое. Если приложение открывает несколько окон, для них могут создаваться отдельные процессы рендеринга. Chromium распределяет задачи между процессами намеренно: сбой одного интерфейсного компонента не должен автоматически обрушить весь клиент.

Для безопасности это рациональная модель. Для памяти — дорогая.

Каждый процесс имеет собственную адресную область и собственные структуры управления. Часть страниц памяти может разделяться операционной системой, например общие динамические библиотеки. Но основная масса данных интерфейса, JavaScript-кучи, DOM-объектов и кэшей остается привязанной к конкретному процессу.

Схематично расход выглядит так:

• базовый набор Chromium и Node.js;
• отдельный renderer process для окна или группы страниц;
• память под JavaScript и DOM;
• графические буферы и данные GPU;
• сетевые кэши, изображения, шрифты и локальные базы;
• служебные структуры приложения;
• фоновые модули, трекеры событий и плагины.

Отсюда возникает неверное бытовое сравнение. Если браузер уже запущен, кажется логичным, что новый Electron-клиент должен «подключиться» к существующему Chromium и почти ничего не добавлять. На практике приложения не используют память другого продукта как общий пул. Slack, Discord и отдельный клиент на Electron не договариваются между собой о совместном рендерере.

Electron экономит время разработки за счет повторного использования Chromium, но не экономит оперативную память за счет общего Chromium между приложениями.

Сам Chromium также не держит все данные в одном процессе. Это принципиальный механизм изоляции. Сайт, расширение или интерфейсный модуль не должны иметь бесконтрольный доступ к памяти другого компонента. В Electron добавляется Node.js, который дает доступ к файловой системе, процессам и системным API. Такой доступ требует дополнительного разделения между главным процессом и рендерингом.

Почему новое окно действительно увеличивает нагрузку

Новое окно не всегда означает полный запуск еще одной копии приложения. Основной процесс обычно остается общим. Часть библиотек и исполняемого кода может быть разделена средствами операционной системы. Но содержимое окна требует отдельного контекста рендеринга. В нем размещаются DOM-дерево, JavaScript-объекты, обработчики событий и данные интерфейса.

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

Проблема усиливается, когда приложение открывает отдельные окна для:

• чатов и каналов;
• звонков и демонстрации экрана;
• настроек;
• документов и встроенных веб-сервисов;
• уведомлений;
• рабочих пространств с собственным состоянием интерфейса.

Каждый такой контекст может иметь собственную кучу V8 и набор объектов Chromium. Закрытие окна должно освобождать ресурсы, но при наличии ссылок на обработчики или глобальные объекты память может оставаться занятой.

Изоляция ресурсов: почему Discord и Slack не делят память

Потребление памяти Electron-приложениями на ПК особенно заметно при параллельной работе нескольких коммуникационных клиентов. Discord, Slack, старые или отдельные сборки Teams, корпоративные мессенджеры и таск-трекеры часто используют схожий стек: Chromium, V8, Node.js и набор веб-технологий.

Внешне интерфейсы отличаются. На уровне операционной системы картина похожа: несколько независимых групп процессов с повторяющимися компонентами.

Среда исполнения JVM в некоторых конфигурациях позволяет нескольким приложениям работать с общими системными механизмами, хотя полное объединение памяти между независимыми процессами также не является автоматическим. Electron-софт устроен иначе: каждый дистрибутив приносит собственный runtime. Унификация библиотек на диске не означает унификацию объектов в RAM.

Именно поэтому два клиента по 200–300 МБ не превращаются в один клиент на 250 МБ. Сумма будет ближе к удвоенной базовой нагрузке, а затем к ней добавятся окна, кэши, видеопотоки и фоновые задачи.

Почему оперативная память не освобождается сразу

В диспетчере задач Windows видны несколько разных величин, которые часто смешиваются:

• память отдельного процесса;
• рабочий набор — страницы, находящиеся в физической RAM;
• частная память процесса;
• разделяемая память;
• общий расход приложения вместе с дочерними процессами;
• занятые GPU-буферы и отображаемые в памяти файлы.

После закрытия вкладки или окна Chromium может не возвращать все выделенные страницы операционной системе. Освобожденные блоки остаются внутри процесса для повторного использования. Это не обязательно утечка. Такой кэш снижает стоимость следующего открытия интерфейса, но в диспетчере задач программа продолжает выглядеть крупной.

Настоящая утечка проявляется иначе. Объем памяти растет после повторяющихся операций и не возвращается даже после закрытия соответствующего интерфейса. В Electron типовые причины связаны с жизненным циклом объектов:

1. Обработчик события продолжает ссылаться на закрытое окно.

2. IPC-слушатель регистрируется при каждом обновлении компонента и не снимается.

3. Глобальный массив удерживает старые сообщения, изображения или результаты запросов.

4. DOM-элементы удаляются визуально, но остаются достижимыми из JavaScript.

5. Кэш бесконтрольно накапливает данные без ограничения размера или срока жизни.

6. Таймеры и фоновые задачи продолжают работать после уничтожения страницы.

В таких случаях перезапуск приложения временно возвращает память системе. Но это не исправление. После повторной рабочей сессии рост начинается заново.

Лимиты V8: почему большое приложение может упасть задолго до нехватки всей RAM

Операционная система видит память процесса в масштабе всей машины. V8 дополнительно ограничивает размер собственной кучи. В этой куче хранятся JavaScript-объекты, строки, массивы, структуры интерфейса и данные, которые не вынесены в другие подсистемы.

С 2022 года в V8 используется механизм Memory Cage и сжатие указателей. Pointer compression уменьшает размер кучи V8 до 40% в подходящих сценариях и может дать прирост производительности CPU и сборщика мусора на уровне 5–10%. Цена — ограничение адресного пространства сжатой кучи примерно до 4 ГБ.

Это не означает, что весь Electron-процесс физически ограничен 4 ГБ. Вне кучи V8 остаются нативные буферы, изображения, видеоданные, память Chromium, сетевые структуры и другие области. Но JavaScript-часть приложения получает жесткую архитектурную границу.

В версиях Electron после 14 для процесса действует лимит порядка 8 ГБ. При превышении процесс может завершиться с ошибкой нехватки памяти. В Electron 12–13 ориентир составлял около 16 ГБ. Electron 11 и более ранние версии не имели такого же жесткого ограничения на уровне процесса.

С точки зрения обычного рабочего ПК это не означает, что приложение будет занимать 8 ГБ при каждом запуске. Лимит находится далеко за пределами типичного потребления Slack или Discord. Он становится значимым для крупных рабочих пространств, длительных сессий, редакторов, встроенных веб-приложений, сложных визуализаций и сценариев с утечкой памяти.

Проблема состоит в другом: увеличение доступного объема RAM не отменяет внутренние ограничения V8 и Chromium. Машина может иметь 32 или 64 ГБ памяти, а отдельный renderer process все равно завершится при достижении своего порога. Если приложение неправильно распределяет нагрузку между процессами, суммарная свободная RAM не спасает.

Свободная память компьютера и доступный размер кучи V8 — разные параметры. Увеличение первого не отменяет ограничений второго.

Что именно показывает ошибка OOM

OOM в Electron не всегда означает, что Windows полностью исчерпала физическую память. Ошибка может возникнуть из-за:

• достижения лимита кучи V8;
• невозможности выделить непрерывный блок памяти;
• разрастания нативных буферов;
• ограничения конкретного процесса;
• утечки в renderer process;
• конфликта между большим кэшем и рабочими структурами приложения.

Поэтому анализировать только общий процент загрузки ОЗУ недостаточно. Нужна динамика по процессам. Если растет один renderer process, вероятен дефект конкретного интерфейса или страницы. Если одновременно увеличиваются GPU, сетевой и главный процессы, причина может быть связана с видео, синхронизацией или фоновой обработкой.

Source maps и режим разработки: скрытый множитель

Одна из наиболее грубых ошибок — запускать рабочую сборку в режиме разработки. При незаданном NODE_ENV=production приложение может сохранять исходные карты, отладочную информацию и расширенные структуры, предназначенные для разработчика.

В режиме development размер кода в отдельных сценариях увеличивается до 20 раз. Это влияет не только на размер файлов на диске. V8 должен разбирать и удерживать больше структур. Парсинг занимает CPU и память. Исходные карты связывают исполняемый код с исходниками и добавляют дополнительные данные, которые в боевой сборке не нужны.

Для пользователя это выглядит как странная аномалия: визуально приложение работает, функции доступны, но потребление памяти непропорционально высокое. Перезапуск не меняет ситуацию. Вкладки закрываются, но базовый объем остается завышенным.

Корректная production-сборка должна:

• отключать отладочные source maps там, где они не нужны конечному клиенту;
• удалять development-проверки и диагностические модули;
• минимизировать JavaScript и CSS;
• разделять код по маршрутам и рабочим областям;
• загружать тяжелые компоненты только при обращении к ним;
• ограничивать объем встроенных ресурсов;
• не включать тестовые панели и отладочные веб-серверы.

Это задача разработчика, а не пользователя Windows. Настройка файла подкачки не исправляет раздутую сборку. Очистка кэша убирает следствие, но не меняет структуру процесса.

Кэш Chromium: память против скорости

Chromium хранит изображения, шрифты, ответы сетевых запросов и другие ресурсы, чтобы не загружать их повторно. Кэш ускоряет работу, но в Electron каждый продукт ведет собственное хранилище. При нескольких клиентах одни и те же библиотеки и изображения могут физически существовать в нескольких каталогах.

Кэш бывает дисковым и оперативным. Удаление дискового кэша не означает мгновенного освобождения всей RAM. Уже загруженные ресурсы остаются в памяти до тех пор, пока их не вытеснит другой контент или процесс не освободит соответствующие структуры.

Слишком агрессивная очистка также не является универсальным решением. После нее приложение начнет заново скачивать ресурсы, распаковывать изображения и строить внутренние индексы. В краткосрочном периоде нагрузка на CPU и сеть может вырасти.

Рабочая диагностика должна смотреть на повторяемость:

• память растет только после открытия конкретного канала;
• рост появляется при прокрутке длинной истории;
• утечка возникает после подключения и отключения звонка;
• расход увеличивается при смене рабочих пространств;
• память не возвращается после закрытия окна;
• после полного перезапуска базовый объем остается выше прежнего.

Каждый сценарий указывает на разный участок цепочки. Универсальная кнопка «очистить RAM» здесь отсутствует.

IPC, DOM и события: где возникают реальные утечки

Electron разделяет главный процесс и рендеринг через IPC — межпроцессное взаимодействие. Рендерер отправляет сообщения главному процессу, а тот выполняет операции с файлами, окнами, системными API или сетевыми модулями. Если слушатели IPC регистрируются повторно и не удаляются, каждое новое действие начинает обрабатываться несколькими экземплярами обработчика.

Память при этом удерживается ссылками. Старый компонент уже не виден пользователю, но его функции, замыкания и данные остаются достижимыми. Сборщик мусора V8 не может удалить объект, на который все еще существует ссылка.

Похожая ситуация возникает с DOM. Интерфейс удаляет элемент из дерева, но внешний массив продолжает хранить его объект. Лента сообщений может сохранять всю историю вместо виртуализации видимой области. Превью изображений могут оставаться в кэше без ограничения. Видео и демонстрация экрана добавляют нативные буферы, которые не всегда отражаются в простой оценке JavaScript-кучи.

На практике наиболее подозрительны четыре класса функций:

1. Слушатели событий.

Каждый повторный монтаж интерфейса добавляет новый обработчик. Событие начинает запускать несколько одинаковых функций. Вместе с ними удерживаются старые состояния компонентов.

2. Долгоживущие глобальные объекты.

Глобальный кэш удобен, но без политики вытеснения он становится контейнером для всей рабочей сессии. История сообщений и миниатюры постепенно превращаются в постоянный расход RAM.

3. Таймеры и фоновые запросы.

Интервалы продолжают обновлять уничтоженный интерфейс. Они не только расходуют CPU, но и удерживают контекст рендеринга.

4. Тяжелые DOM-деревья.

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

Сборщик мусора V8 не является механизмом автоматического уменьшения процесса. Он удаляет недостижимые объекты. Если приложение сохраняет ссылки, сборщик не может определить, что данные больше не нужны. Если же память освобождена внутри кучи, процесс может не вернуть ее Windows сразу.

Что можно сделать на стороне пользователя

Пользователь не может изменить архитектуру чужого клиента, но способен убрать наиболее дорогие сценарии. Оптимизация оперативной памяти Windows в случае Electron начинается не с «ускорителей», а с сокращения числа постоянно работающих экземпляров Chromium.

Практический порядок действий выглядит так:

1. Собрать базовый замер после запуска.

Нужно зафиксировать общий расход приложения вместе со всеми дочерними процессами. Одна строка Discord или Slack в диспетчере задач часто не показывает полный объем.

2. Сравнить состояние без активных окон и после рабочей сессии.

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

3. Отключить ненужный автозапуск.

Фоновый клиент, который запускается вместе с Windows и постоянно держит Chromium, расходует память еще до начала работы. Автозапуск особенно дорог при нескольких мессенджерах.

4. Закрыть отдельные окна, а не только свернуть их.

Сворачивание убирает интерфейс с экрана, но не обязательно уничтожает renderer process. Системный трей также часто оставляет главный процесс активным.

5. Проверить встроенные функции звонков и демонстрации экрана.

Видео, захват экрана и аппаратное ускорение используют дополнительные буферы. После завершения звонка расход должен стабилизироваться, а не продолжать расти.

6. Обновить клиент и саму систему без установки случайных сборок.

Electron обновляется вместе с приложением. Исправления Chromium и V8 могут менять поведение памяти. Неофициальный установщик добавляет отдельный риск цепочки поставки.

7. Не запускать рабочий клиент с отладочными параметрами.

Флаги разработчика, тестовые расширения и режимы диагностики увеличивают объем данных и меняют поведение рендеринга.

8. Не держать несколько клиентов с одинаковой функцией без необходимости.

Одновременные Discord, Slack, Teams и веб-версии тех же сервисов создают дублирующие процессы. Браузерная вкладка не всегда дешевле Electron-клиента, но итог нужно измерять, а не угадывать.

На системах с 8 ГБ ОЗУ разница между двумя и пятью постоянно работающими Electron-программами заметна сразу. На 16 ГБ и выше узким местом может стать не общий объем памяти, а конкретная утечка, из-за которой один процесс постепенно приближается к внутреннему лимиту.

Когда веб-версия не решает проблему

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

Если одновременно открыт браузер с десятками вкладок и Electron-клиент, замена одного на другое может не дать выигрыша. При этом веб-версия иногда теряет системные функции: уведомления, интеграцию с файлами, запуск при старте системы или полноценную работу в фоне.

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

Что должны делать разработчики Electron-приложений

Основная часть проблемы находится не в Windows и не в пользователе. Она находится в жизненном цикле объектов приложения.

Первое требование — разделять процессы по ответственности, а не создавать новые окна без контроля. Renderer process должен уничтожаться после закрытия интерфейса, если он больше не нужен. Главный процесс не должен удерживать ссылки на все созданные окна и связанные с ними обработчики.

Второе — контролировать IPC. Регистрация слушателя должна иметь симметричное снятие. Повторный монтаж компонента не должен умножать количество обработчиков. Для каналов с большими данными нужен лимит размера сообщений и явное управление временем жизни буферов.

Третье — ограничивать кэши. История чата, изображения, превью и результаты поиска должны храниться по политике вытеснения. Бесконечный кэш — это не оптимизация, а отложенная утечка.

Четвертое — использовать виртуализацию списков. Пользователь видит небольшую область экрана. Нет технической необходимости держать тысячи строк DOM активными одновременно. Виртуализация сокращает число узлов, обработчиков и перерисовок.

Пятое — собирать профиль памяти в реальном сценарии. Тест «открыл окно, закрыл окно» недостаточен. Нужен цикл: открыть рабочее пространство, загрузить историю, сменить канал, запустить звонок, закрыть окно, повторить операцию несколько раз. Если после каждого цикла память растет, причина обычно находится в удерживаемых ссылках или нативных ресурсах.

Сжатие указателей V8 помогает, но не заменяет эту работу. Снижение размера кучи до 40% относится к определенному уровню исполнения и не превращает все приложение в легковесный процесс. Кэш Chromium, изображения, GPU-буферы и нативные модули остаются за пределами простой оценки JavaScript-кучи.

Почему обещания «низкого потребления» требуют проверки

Сравнение Electron с альтернативными фреймворками часто строится на одной цифре из диспетчера задач. Такой замер малоинформативен. Один runtime может использовать системный WebView, другой — собственную копию Chromium. Один клиент загружает интерфейс полностью, другой делает это по требованию. Один держит историю в памяти, другой постоянно обращается к локальной базе.

Даже переход на другой стек не гарантирует резкого снижения расхода. Если интерфейс построен вокруг тяжелого веб-приложения, большая часть памяти уйдет на DOM, JavaScript, изображения и кэш независимо от упаковщика. Если новый клиент использует Chromium-совместимый системный движок, архитектурная стоимость частично сохраняется.

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

• объем памяти после холодного запуска;
• расход после загрузки рабочего пространства;
• число открытых окон;
• поведение после двух-трех часов работы;
• расход при звонке и демонстрации экрана;
• количество дочерних процессов;
• использование CPU при простое;
• возврат памяти после закрытия интерфейса;
• наличие роста после повторения одного и того же действия.

Наиболее информативна не пиковая цифра, а график. Стабильный расход в 500 МБ может быть приемлемее, чем стартовые 250 МБ с постоянным ростом до нескольких гигабайт. Во втором случае программа создает операционный риск: в любой момент Windows начнет активно использовать файл подкачки, а клиент завершится из-за OOM.

Жесткий вывод: Electron не является дефектом сам по себе

Electron выбирают из-за единого кода, быстрого выпуска функций и доступа к экосистеме веб-разработки. Эти преимущества имеют цену. В каждый клиент встроены Chromium и Node.js. Процессы изолированы. Окна требуют собственных контекстов. Кэши дублируются. Утечки в JavaScript и IPC долго остаются незаметными.

Нагрузка на ОЗУ от настольного софта определяется не только названием фреймворка. На нее влияют версия Electron, режим сборки, число renderer process, размер DOM, политика кэширования, видеопотоки и качество управления жизненным циклом объектов.

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

Если клиент стабильно расходует 130–250 МБ и не увеличивает объем после длительной работы, это ожидаемая стоимость архитектуры. Если память растет после каждого открытия канала, окна или звонка, перед системой находится дефект. Перезапуск только сбрасывает счетчик. Исправляет проблему исключительно контроль жизненного цикла процессов и объектов.