Шокирующее увеличение потребления памяти WhatsApp: 7‑кратный рост, почему это происходит и как избежать

Вступление

Мессенджеры стали неотъемлемой частью нашей повседневной жизни. Они заменяют телефонные звонки, электронную почту и даже часть офисных приложений. Поэтому любые изменения в их работе сразу попадают в поле зрения миллионов пользователей. Недавно команда WhatsApp объявила о полном переписывании Windows‑версии клиента на JavaScript. На первый взгляд – современный стек технологий, кроссплатформенность, быстрый выпуск обновлений. На практике же результат оказался неожиданным: потребление оперативной памяти выросло с 200 МБ до 1,4 ГБ, то есть более чем в семь раз.

Такой скачок ставит под вопрос не только техническую целесообразность выбранного подхода, но и общую стратегию разработки крупных кроссплатформенных приложений. В статье мы разберём, какие причины могут стоять за столь резким ростом, какие мнения высказали участники Reddit‑сообщества, и какие выводы можно сделать для будущих проектов.

И в завершение вступления – небольшое японское хокку, которое, на наш взгляд, отражает суть происходящего:

古池や
蛙飛び込む
水の音

Фуруйэка я — старый пруд,
Квака буйко́му — лягушка прыгает,
Мизу но о́то — звук воды.

Старый код, как пруд, тихо лежит. Переписывание – как лягушка, бросающаяся в воду, создаёт шум и волны.

Пересказ Reddit‑поста своими словами

Событие началось с короткого сообщения от пользователя CSMR250, который заметил, что WhatsApp переписал своё Windows‑приложение на JavaScript, и в результате потребление памяти выросло с 200 МБ до 1,4 ГБ. Это заявление сразу привлекло внимание сообщества, и в комментариях разгорелась бурная дискуссия.

Одним из первых откликов был jaredcheeda, который привёл цитату о том, что любой крупный рефакторинг кода неизбежно приводит к исправлению багов, независимо от того, зачем проводится переписывание. По его мнению, главное – внимание к улучшению кода, а не к добавлению новых функций.

Пользователь repeating_bears просто отметил «7‑кратное улучшение!», подразумевая рост потребления памяти.

С другой стороны, sad_cosmic_joke указал, что количество строк кода (LoC) – плохой показатель эффективности без контекста, и предположил, что часть кода могла быть вынесена в сторонние библиотеки.

Наконец, cyberbemon выразил личное недовольство: приложение «один из самых ужасных» продуктов, который, тем не менее, удобен для ответов на звонки с ПК, но «ужасно» тормозит.

Суть проблемы, хакерский подход и основные тенденции

Ключевая проблема – резкое увеличение потребления оперативной памяти после перехода на JavaScript. Это явление имеет несколько потенциальных причин:

• Тяжёлый рантайм‑движок. Electron‑подобные решения включают Chromium и Node.js, что добавляет десятки мегабайт к базовому процессу.
• Неоптимизированный код. При переписывании часто используют готовые библиотеки, не учитывая их «вес».
• Отсутствие строгой типизации. JavaScript допускает динамические структуры, которые могут «раздуваться» в памяти.
• Отсутствие профилирования. Быстрый релиз без глубокого анализа потребления ресурсов.

Тенденция к использованию кроссплатформенных стеков (Electron, React Native, Flutter) растёт, потому что позволяет поддерживать один код для разных ОС. Однако цена за эту гибкость – часто повышенное потребление памяти и более медленное время отклика.

Детальный разбор проблемы с разных сторон

Техническая сторона

Переписывание на JavaScript обычно подразумевает использование Electron – среды, объединяющей Chromium и Node.js. Сам по себе Chromium занимает около 150 МБ в «чистом» виде, а каждый открытый процесс добавляет ещё несколько десятков мегабайт. При этом приложение WhatsApp, будучи «мессенджером», постоянно держит открытыми соединения WebSocket, хранит кэш сообщений, медиа‑файлы и т.д. Всё это в совокупности легко достигает гигабайтных объёмов.

Пользовательская сторона

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

Экономическая сторона

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

Безопасность и поддержка

Большее количество кода и сторонних библиотек повышает поверхность атаки. Каждый подключённый модуль – потенциальный вектор уязвимости. Кроме того, поддержка «тяжёлого» стека требует более квалифицированных специалистов.

Практические примеры и кейсы

Рассмотрим два реальных кейса, где переход на JavaScript привёл к аналогичным проблемам:

• Microsoft Teams (Electron) – в начале 2020‑го года пользователи жаловались, что приложение потребляет более 1 ГБ ОЗУ, что делает его непригодным для старых ПК.
• Slack (Electron) – в 2019‑м году команда Slack выпустила обновление, после которого потребление памяти выросло в 2‑3 раза, вызвав массовый отток пользователей.

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

Экспертные мнения из комментариев

Среди участников Reddit‑дискуссии выделяются несколько ключевых точек зрения:

CSMR250 – фиксирует факт: переписали на JavaScript, потребление выросло с 200 МБ до 1,4 ГБ.

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

repeating_bears – лаконично фиксирует «7‑кратное улучшение», указывая на масштаб изменения.

sad_cosmic_joke – предостерегает от использования количества строк кода как метрики; без контекста такие цифры вводят в заблуждение.

cyberbemon – делится личным опытом: приложение удобно для звонков, но «ужасно» в плане производительности.

Эти мнения позволяют увидеть, что сообщество разделилось: одни видят в переписывании шанс улучшить код, другие – реальную проблему с ресурсами.

Возможные решения и рекомендации

Для разработки кроссплатформенных приложений с минимальными ресурсными затратами рекомендуется следующее:

1. Тщательное профилирование. Перед выпуском новой версии необходимо измерять потребление памяти, CPU и время отклика с помощью инструментов вроде Chrome DevTools, Node.js – --inspect, process.memoryUsage().
2. Оптимизация зависимостей. Удалять неиспользуемые библиотеки, заменять тяжёлые пакеты на лёгкие альтернативы.
3. Разделение процессов. Выделять тяжёлые задачи (например, обработку медиа) в отдельные процессы или сервисы, чтобы основной UI‑процесс оставался лёгким.
4. Использование WebAssembly. Для вычислительно‑тяжёлых модулей можно писать код на Rust или C++ и компилировать в WASM, что уменьшит нагрузку на JavaScript‑движок.
5. Внедрение статической типизации. TypeScript помогает избежать ошибок, связанных с динамической типизацией, и может снизить объём «раздувающихся» объектов.
6. Регулярный аудит безопасности. Проводить сканирование зависимостей на уязвимости (npm audit, Snyk) и обновлять их.

Для уже существующего WhatsApp‑клиента можно предложить следующие шаги:

• Выпустить «light‑mode» – облегчённую сборку без поддержки видеозвонков и фоновых синхронизаций.
• Ввести гибкую настройку кэширования, позволяющую пользователю ограничить объём хранимых медиа‑файлов.
• Оптимизировать работу с WebSocket, закрывая неактивные соединения.

Заключение с прогнозом развития

Переписывание крупных приложений на JavaScript – это двойственный меч. С одной стороны, он открывает двери к кроссплатформенной разработке, ускоренному выпуску новых функций и более лёгкой поддержке. С другой – повышает требования к ресурсам, усложняет профилирование и может ухудшить пользовательский опыт.

В ближайшие годы мы, скорее всего, увидим рост гибридных подходов: ядро приложения будет написано на «лёгком» языке (Rust, Go), а UI – на JavaScript/TypeScript. Это позволит сохранить производительность, одновременно используя преимущества веб‑технологий.

Для пользователей WhatsApp важнее всего стабильность и низкое потребление ресурсов. Поэтому команда разработчиков, вероятно, будет вынуждена вернуться к оптимизации, возможно, выпустив отдельные «мобильные» и «десктопные» версии, где каждая будет построена под свои задачи.

Практический пример (моделирование потребления памяти)

Ниже представлен простой скрипт на Python, который моделирует рост потребления памяти при добавлении объектов в список. Он демонстрирует, как даже небольшие «утечки» могут привести к значительному росту ОЗУ, если не проводить очистку.

import sys
import random
import time

class MemoryLeakSimulator:
    """Класс, имитирующий рост потребления памяти за счёт накопления объектов."""
    
    def __init__(self):
        # Хранилище для «утечек»
        self._leak_container = []
    
    def add_random_data(self, count: int):
        """
        Добавляет в контейнер случайные строки заданного количества.
        Каждый элемент – строка длиной от 1 до 1000 символов.
        """
        for _ in range(count):
            length = random.randint(1, 1000)
            # Генерируем случайную строку
            random_str = ''.join(random.choices('abcdefghijklmnopqrstuvwxyz', k=length))
            self._leak_container.append(random_str)
    
    def current_memory_usage(self) -> int:
        """
        Возвращает текущий объём памяти, занимаемый контейнером, в байтах.
        """
        return sys.getsizeof(self._leak_container) + sum(sys.getsizeof(item) for item in self._leak_container)
    
    def clear(self):
        """Очищает контейнер, освобождая память."""
        self._leak_container.clear()

# Создаём симулятор
sim = MemoryLeakSimulator()

print("Начальное потребление памяти:", sim.current_memory_usage(), "байт")

# Пошагово добавляем данные и измеряем рост
for step in range(1, 6):
    sim.add_random_data(5000)  # добавляем 5000 случайных строк
    usage = sim.current_memory_usage()
    print(f"Шаг {step}: потребление памяти = {usage // (1024)} КБ")
    time.sleep(0.5)  # небольшая пауза для наглядности

# Очистка и проверка освобождения памяти
sim.clear()
print("После очистки:", sim.current_memory_usage(), "байт")

Данный скрипт показывает, как без явного освобождения ресурсов (вызова clear()) объём используемой памяти будет расти линейно. Аналогично происходит в приложениях, где объекты кэша, соединения или медиа‑файлы не удаляются своевременно.