Frontend Development 8 min read

Dynamic Layout Solution for Multi‑Party Voice Chat on the Huajiao Platform

The article describes a server‑driven, H5‑based dynamic layout architecture for Huajiao's multi‑party voice chat, detailing its design principles, benefits such as reduced client development, flexible layout switching, and the interaction mechanisms among server, H5 front‑end, and client.

360 Tech Engineering
360 Tech Engineering
360 Tech Engineering
Dynamic Layout Solution for Multi‑Party Voice Chat on the Huajiao Platform

Background – Since 2019 the voice market has exploded with platforms like Inke, Momo, Douyu, and NOW offering various modes (radio, 1‑to‑2, 6+1, 8+1, audio‑video, matchmaking, PK, etc.). To accelerate Huajiao’s voice business and keep it industry‑leading, a dynamic layout solution for multi‑party voice rooms was designed.

Existing layouts – Screenshots of Huajiao and competitor layouts are shown below:

Technical introduction – The solution treats the Android/iOS client as an “OS” where layout and data capabilities are exposed to the server and H5 front‑end. All business and activity logic resides on the server and H5, which drive the client to render the UI.

Benefits

Simplifies development: only server and H5 are needed, eliminating the need for client‑side activity development.

Saves iOS/Android resources: the client only provides basic capabilities.

Reduces time‑to‑market and version‑compatibility concerns.

Enables seamless switching between multiple layout‑based play‑styles.

Layout is HTML/CSS‑like, allowing rapid onboarding and minimal code.

Client live‑room design – The live‑room consists of multiple layers (gift layers, layout layer, H5 interaction layer, etc.). The layout layer’s rendering authority is handed to H5 and the server.

By exposing basic widget creation (label, button, image, etc.) and business‑specific abilities (e.g., push‑pull stream for co‑hosting), the server and H5 can compose any layout on a canvas.

Example: label widget

Each widget exposes basic attributes (layout positions, text, colors, etc.) and follows a hierarchical layering model similar to HTML/CSS.

Three mechanisms

Sync mechanism : Server pushes layout data and associated content via a sync interface; the client caches it for rendering.

Message mechanism : Layout or data source changes are triggered by messages (e.g., switching from a normal layout to a matchmaking layout).

JS interface : H5 interacts with the client through a JavaScript bridge to implement interactive layers above the layout.

Interaction among three ends

H5 does not fetch layout directly from the server; instead, the client forwards layout messages to H5 via the JS bridge, ensuring consistency.

Development process – With this design, all activity logic lives on the server and H5, while the client only displays the UI, dramatically simplifying development, testing, and release cycles.

Green‑highlighted parts in the diagram indicate resources that can be eliminated, leading to faster launches and reduced client involvement.

Final product effect

Upcoming group‑battle gameplay for the live‑room is shown below (preview).

H5Real-time Communicationdynamic layoutserver‑driven UIVoice Chat
360 Tech Engineering
Written by

360 Tech Engineering

Official tech channel of 360, building the most professional technology aggregation platform for the brand.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.