How to Slash Live‑Streaming App Memory & CPU Usage on Mobile Devices

Live‑Room Structure

In online education, live rooms differ from generic entertainment streams: they involve higher business complexity, a wide range of devices (including many low‑end phones), and long session durations (~1.5 hours), which cause noticeable heating and power consumption, making performance a critical bottleneck.

The UI is landscape and consists of a persistent slide area (WebView), a lecturer’s pull‑stream area, the user’s push‑stream area, a peer‑group area, and a chat area. The slide area hosts H5 slides, interactive questions, and a transparent canvas‑based drawing board, all of which are resource‑intensive.

Behind the scenes, live‑stream pull/push, codec processing, image rendering, and signaling (parsing, de‑duplication, compensation) also consume substantial resources, especially the media pipeline.

Performance Measurement (APM)

After understanding the structure, we quantify performance using Application Performance Monitoring (APM). APM collects CPU, memory, and FPS metrics at a configurable sampling rate, generates reports, and feeds back into business decisions. In our case, memory usage grows from ~200 MB at entry to >800 MB, low‑end devices sustain 80‑90% CPU load, and FPS frequently drops below 10.

Customer‑support data (user feedback, sentiment, community reports) complements technical metrics to form a comprehensive performance view.

User issue feedback rate (image, audio, interaction problems) should stay below per‑thousand level.

Performance indicators: stable CPU, memory, FPS with timely release.

Business indicators: video stall rate, signaling latency, interaction success rate ≥ 99.9%.

Identified Problems

Stutter & crashes caused by memory exhaustion (<10 MB left) and CPU near 100% on low‑end devices.

Slide performance issues: incomplete or frozen slides, drawing artifacts.

Black/white screens due to GPU OOM in WebGL rendering (white on iOS, black on Android).

Interaction failures caused by delayed, lost, or out‑of‑order signaling.

Optimization Solutions

Independent Process (Android)

Run the live‑room in a separate process with its own resource scheduler. The main app hosts the process, communicates via AIDL, shares data via MMKV (with file‑lock consistency), and a Service Manager oversees all binder services.

Containerization

Treat each functional component (e.g., WebView) as a container with a lifecycle: create → load → update → reset → close → destroy. This explicit management enables timely resource release.

Dedicated Signaling Channel

Replace the SEI‑based signaling (tied to the video stream and unreliable over UDP) with a long‑connection channel, decoupling signaling from media pull‑stream and improving reliability.

Rendering Optimizations

Native UI : Relies on the OS, generally efficient if memory leaks are avoided.

Media Rendering : Video pipeline (decode → post‑process → render) benefits from hardware decoding and platform‑specific APIs (OpenGL, Metal, Vulkan). Hard‑decode reduces CPU load and saves power, but low‑end GPUs may need fallback paths.

WebView : Reduce image/GIF load, DOM calculations, and consider Cocos runtime as a lightweight alternative.

Thread Optimization : Profile threads (ADB/Android Studio, Instruments/iOS), consolidate noisy log threads, and use a unified thread‑pool to limit CPU contention.

Results

Memory

Average memory usage dropped from ~800 MB to ~200 MB, with independent processes freeing ~300 MB on Android and containerization ensuring timely reclamation.

CPU & FPS

Low‑end devices show markedly fewer low‑FPS frames; overall stutter feedback reduced by ~80% thanks to rendering, thread, and business‑level optimizations.

Black/White Screen

WebView black/white screen rate fell by ~83% initially and approached zero after iterative upgrades; Cocos runtime achieved a 0% rate.

Conclusion

Performance optimization of a live‑streaming classroom is an ongoing engineering effort that requires continuous monitoring (APM), disciplined development practices, and iterative resource‑management strategies. Future work will explore deeper CPU scheduling, GPU rendering tricks, and simplified technical solutions to further close performance gaps.