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.
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).
360 Tech Engineering
Official tech channel of 360, building the most professional technology aggregation platform for the brand.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.