Memory Optimization of Desktop QQ: A Stage Summary

Desktop QQ, built on the Electron framework, faces significant memory‑usage challenges because users may stay logged in for weeks, causing the application’s memory footprint to grow and potentially lead to slow UI response or crashes.

The team set two optimization targets: (1) keep the memory of a single process under 300 MB; (2) after further refinement, keep each process under 100 MB and the total memory of all six processes under 300 MB before the Windows release.

Initial profiling using Windows Task Manager showed a baseline "Hello World" Electron app consumes about 68 MB, but real‑world QQ usage (main, GPU, and renderer processes) can exceed 600 MB, leaving more than 50 % of the target space for improvement.

Key optimization areas :

Tool‑based analysis – combined V8, Chromium, and native C++ diagnostics to locate memory hot spots.

Code & static‑resource slimming – removed unused third‑party code, applied custom builds, and introduced on‑demand loading and fine‑grained code splitting for windows.

Image handling – generated thumbnails instead of full‑resolution images, reducing memory by 30‑50 MB per chat image batch.

DOM reduction – adopted a "visible‑only" rendering strategy, replaced large paginated lists with virtual scrolling, and trimmed DOM element counts from ~13 000 to ~4 000, saving ~20 MB.

Render‑layer optimization – eliminated unnecessary compositor layers, merging layers where possible, saving ~9 MB.

Lottie animation tuning – reduced cached frame size (120 → 240 px) and cache ratio (9/10 → 3/4), cutting animation memory from 144 MB to 35 MB.

Electron API usage – cached NativeImage objects for tray icons and avoided repeated image creation that caused leaks.

Memory‑leak prevention – removed stale listeners, timers, detached DOM nodes, and performance‑mark objects; applied code‑review and static checks.

After the series of optimizations, the application’s memory usage on test devices stabilized below 300 MB, with typical values around 228 MB (average), 211 MB (median) and 350 MB for the 90th percentile of users.

To ensure long‑term stability, the team built an online monitoring pipeline using Electron’s getMetrics / getMemoryInfo APIs (patched to expose task‑manager‑style metrics) and reported data to Prometheus‑Grafana dashboards. An anti‑degradation platform runs automated end‑to‑end tests on each build, captures performance metrics (memory, CPU, response time), and pushes alerts via WeChat bots for rapid issue triage.

The article also explains why Electron was chosen: low development cost for web engineers, mature ecosystem, and the ability to keep the final binary size (~150 MB) and memory footprint comparable to the native client while delivering faster feature iteration.