跪拜 Guibai
← All articles
Frontend · IoT · JavaScript

Running Hikvision's IoT Frontend: Video Streams, 50K Devices, and 24/7 Stability

By miss ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

IoT dashboards are a stress test for browser limits: GPU memory, WebRTC connection caps, and garbage collection pauses all surface as real crashes on 24/7 screens. The patterns here — batched state, shallow reactivity, shared WebSocket in micro-frontends — apply to any dashboard that must stay alive under a firehose of real-time data.

Summary

A Hikvision IoT platform frontend must render 16 simultaneous low-latency video feeds, track real-time status for up to 50,000 devices, and run continuously without memory leaks. Video playback relies on WebRTC for sub-second preview and HLS for recorded playback, with IntersectionObserver pausing off-screen streams to conserve GPU memory. Device state arrives over a single WebSocket and is buffered into requestAnimationFrame batches; a shallow-reactive Map ensures a status change re-renders only the affected list item, not the entire virtual list.

Real-time sensor charts use ECharts with animation disabled, a rolling 300-point window, and incremental setOption calls. On maps, marker clustering and CSS-only status updates prevent DOM churn when hundreds of cameras change state. A unified resource manager tracks all intervals, WebSocket connections, and AbortControllers, cleaning them up on component unmount. Memory monitoring triggers an automatic page refresh when JS heap usage exceeds 85%.

Micro-frontends split video, access control, alarms, and analytics into separate repos, but a shared WebSocket in the shell app prevents connection multiplication. Security measures include short-lived stream tokens, Canvas-based employee-ID watermarks, and field-level data masking per user role.

Takeaways
— WebRTC delivers sub-second video preview; HLS handles recorded playback where latency can be higher.
— Browsers cap simultaneous PeerConnections. Reusing tracks or switching to software decoding plus Canvas rendering avoids hitting the limit.
— Sixteen 1080p video elements consume roughly 1.5 GB of GPU memory; pausing off-screen streams via IntersectionObserver reclaims it.
— Device status arrives over a single WebSocket, gets buffered, and flushes once per animation frame to prevent UI jank from hundreds of messages per second.
— A shallow-reactive Map lets each virtual-list item subscribe to its own device key, so one status update re-renders only that row.
— Real-time ECharts charts disable animation, cap data points at 300, and use incremental setOption to avoid full redraws.
— Map markers for dense device clusters use CSS class swaps instead of DOM rebuilds when status changes.
— A resource manager registers all intervals, WebSockets, and AbortControllers and cleans them up on component unmount.
— JS heap usage above 85% triggers an automatic page reload, buying time on long-running kiosk screens.
— Micro-frontend sub-apps share one WebSocket connection through the shell app, preventing connection multiplication across repos.
— Video streams carry short-lived tokens; Canvas overlays stamp employee IDs onto every frame as a watermark.
Conclusions

GPU memory is the hard ceiling for multi-camera dashboards, not JavaScript performance. A 16-up view can exhaust 1.5 GB of VRAM on integrated graphics before any CPU bottleneck appears.

The shallow-reactive Map pattern is a useful alternative to state-management libraries for high-frequency updates: it sidesteps deep-proxy overhead and keeps re-render scope to a single list cell.

Auto-refreshing the page when memory hits 85% is a pragmatic admission that browser GC is unpredictable. It trades a brief interruption for avoiding a hard crash on an unattended screen.

Sharing one WebSocket across micro-frontends via a global event bus solves a real architectural cost: without it, each sub-app opens its own connection, and a 4-sub-app dashboard burns through browser connection limits fast.

Concepts & terms
WebRTC
A browser API for real-time, peer-to-peer communication of audio, video, and data. In IoT, it enables sub-second video streaming from cameras to the browser without plugins.
HLS (HTTP Live Streaming)
Apple's adaptive streaming protocol that breaks video into small HTTP-based file segments. It is widely used for recorded playback and live streams where a few seconds of latency is acceptable.
IntersectionObserver
A browser API that asynchronously observes when an element enters or leaves the viewport. Used here to pause video decoding for off-screen streams, freeing GPU and CPU resources.
Shallow reactivity
A Vue 3 reactivity mode (shallowReactive) that only tracks top-level property access. When combined with a Map, it allows fine-grained updates where changing one key triggers only the component reading that key.
Virtual list
A rendering technique that only mounts DOM nodes for visible rows in a long list, recycling them as the user scrolls. Essential for rendering tens of thousands of device rows without layout thrashing.
Micro-frontends
An architectural style where a web application is composed of independently deployable frontend modules, each owned by different teams. Here it splits video, access control, alarms, and analytics into separate repos under a shared shell.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗