How We Revamped a Live‑Streaming PC Client with Electron for Stability and Performance

Background

The company’s live‑class business was iterating quickly, but the PC student client suffered from an outdated tech stack, complex module dependencies, frequent stability issues, and high maintenance costs, making it unable to keep up with business demands.

Electron, an open‑source framework that enables cross‑platform desktop applications using front‑end technologies, was chosen as the foundation (used by VSCode, Notion, Postman, etc.).

Problems & Goals

The student client integrates pre‑class device checks, course selection, sign‑in, media live/recorded playback, Cocos questions, gestures, voice, tabs, and post‑class quizzes. The existing implementation was simple but lacked stability, extensibility, and configurability, leading to high costs for multiple live rooms and poor online quality.

Key goals:

Introduce a configuration‑driven component system to serve multiple live rooms at lower cost.

Use process isolation, layered architecture, and encapsulation to improve stability and reduce iteration risk.

Reduce CPU and memory consumption for low‑end devices.

Establish comprehensive logging and data pipelines for monitoring, debugging, and performance metrics.

Analysis & New Architecture

The new PC client architecture is divided into three layers: Electron layer, business container layer, and front‑end application layer. A smooth transition plan was defined, iterating modules by priority.

Module Design

1. Signalling Module

Role: Handles data exchange between presenter, server, and student client.

Design: Previously tightly coupled with business logic; now encapsulated with event registration, reducing development cost and risk.

Implementation: Replaced PPAPI long‑link with a Node‑based long‑link for better control and stability.

2. Logging & Data Pipeline

Role: Provides essential data for debugging, online issue tracing, and monitoring.

Design: Client classifies logs by level and applies different persistence and upload strategies; failed uploads are retried to avoid loss.

Data pipeline integrates rlog (real‑time alerts) and nlog (heavy‑weight data processing) to satisfy both monitoring and analytical needs. Custom “Hubble” platform was built for live‑class specific case tracking.

3. BVManager Module

Role: Manages the lifecycle of Electron’s BrowserView (BV) containers, including creation, updates, destruction, JS/CSS injection, layering, and pooling.

Design: Chose BV over BrowserWindow, iframe, or for better isolation, performance, and API completeness. Implemented fine‑grained environment initialization and a BV pool to improve user experience.

Comparison of web‑container options:

Option

Isolation

Startup Performance

Development Cost

Feature Completeness

BrowserWindow

High

Poor

Poor

Good

BrowserView

Medium

Medium

Medium

Excellent

iframe

Poor

Excellent

Excellent

Medium

<webview>

Medium

Good

Good

Poor

4. Player Module

Role: Integrates a media SDK to handle streaming, pulling, and video frame rendering.

Design: Replaced the early PPAPI wrapper with a Node module that performs transcoding, slicing, and rendering, improving performance and stability. Video frames are now actively pulled by the consumer side to avoid backlog and memory overflow on low‑end devices.

Encountered Issues

During iteration, several problems arose:

Compatibility: Antivirus restrictions on process creation/file access and Electron version crashes on Windows 7.

Performance: Low‑end devices (≤4 GB RAM) experienced stuttering; profiling identified bottlenecks in logging I/O and third‑party Electron modules.

Security: Adjusted to avoid executing CLI files, writing to non‑user directories, and modifying the registry.

Standards & Process: Established device‑grade guidelines (unsupported, not recommended, recommended) and SOPs for antivirus‑related issues.

Targeted optimizations (flame‑graph analysis, log I/O tuning, custom Electron modules, media degradation on low‑end machines) resolved the majority of these issues.

Results & Benefits

Business Impact

Configurable product and modular technology enable low‑cost support for multiple live rooms and easy integration for other business lines.

Improved online stability enhances user experience.

Performance Gains

CPU usage dropped from 15.1% to 11.1% (≈26.4% reduction) and memory consumption fell from 1278 MB to 980 MB (≈23.3% reduction) when comparing the new architecture to the old one.

Stability

Crash rate decreased to 0.08 % (8 per 10,000), far below the previous 0.6 %.

Memory reclamation during live sessions became observable, indicating better resource control.

Iteration Efficiency

Clear separation of the Electron layer, business container layer, and front‑end application layer reduced coupling, improved maintainability, and mitigated regression risk.

Conclusion

The project involved a complex business flow and technology stack. The redesign using Electron, modular components, and systematic logging delivered noticeable stability, performance, and maintainability improvements, and the team welcomes further discussion from interested peers.