How Huajiao Enables Server‑Driven Dynamic Voice‑Chat Layouts with Zero Client Code

Background

Since 2019 the voice market in China grew rapidly with platforms such as Yingke, Momo, Douyu and NOW, offering many interaction modes (radio, 1‑to‑2, 6+1, 8+1, audio‑video, matchmaking, PK, etc.). To keep Huajiao’s voice service competitive, a dynamic layout architecture was created that lets new multi‑person live‑room features be deployed using only server‑side code and an H5 front‑end, without any client‑side binary updates.

Technical Overview

The Android and iOS clients act as thin OS layers that expose a layout rendering engine and a set of basic UI controls (label, button, image, etc.) to the server and to the H5 page. All business logic, activity flow and data binding are implemented on the server or in the H5 page; the client merely receives layout definitions and renders them.

Key Benefits

Simplified development – only server and H5 need to be modified for a new activity.

Reduced iOS/Android resource consumption – the client provides only the rendering runtime.

Eliminated client‑side release cycles, shortening time‑to‑market.

Full compatibility with existing client versions; new layouts work on any installed client.

Operators can switch between many layout configurations instantly, delivering smooth user experiences.

Layout description is JSON‑based and resembles HTML/CSS, so front‑end developers can adopt it quickly.

Live‑Room Architecture

The live‑room UI consists of several stacked layers: small‑gift layer, big‑gift layer, layout layer, and an H5 interaction layer. The layout layer’s rendering rights are delegated to the H5 page and the server, which can instantiate native controls and invoke business‑specific functions such as stream pull/push.

Control Model – Example with a Label

Every complex UI is assembled from simple controls. The server/H5 can create a label control, set its attributes (position, text, textColor, backgroundColor, etc.) and bind its content to a data expression. For instance, the text of a label can be bound to sync:p_user.user[seat=0].user.nickname, which reads the nickname of the user occupying seat 0 from the synchronized data store. When the underlying data changes, the label updates automatically.

Core Concepts

Basic Attributes – Each control exposes a set of properties (e.g., t, l for top/left, text, textColor, backgroundColor). The client creates the control based on its name and applies the supplied attributes.

Hierarchy – Layout definitions are JSON objects that follow a tree structure, similar to native layout XML. Nested objects represent child views, allowing arbitrarily deep view hierarchies.

Data Interaction – Dynamic data binding uses expressions prefixed with sync:. The expression is evaluated against the data payload delivered by the server; any change triggers a UI refresh.

Mechanisms for Layout Delivery

Sync Mechanism – The server pushes a complete layout JSON and the associated data payload through a sync API. The client caches the payload and renders the UI.

Message Mechanism – Layout switches (e.g., from a normal room to a matchmaking mode) are triggered by server‑sent messages. Upon receipt, the client replaces the current layout tree with the new definition.

JS Bridge – The H5 page communicates with the native client via a JavaScript bridge. Through this bridge the H5 layer can overlay additional interactive components above the layout layer and execute custom gameplay logic.

Interaction Flow Between Client, Server, and H5

To guarantee layout consistency, the H5 page never fetches layout data directly from the server. Instead, the client receives layout updates via the sync or message channels and exposes them to H5 through the JS bridge. All three channels (sync, message, JS bridge) are available to both server and H5, providing flexibility while preserving data integrity.

Development Process

Because the client only renders UI, the entire activity lifecycle can be developed, tested, and released without touching native code. This yields three practical advantages:

The client can be excluded from feature development.

The client does not need to participate in testing or version releases for new activities.

Version‑upgrade time is eliminated, dramatically shortening overall launch cycles.

Resulting Product

The architecture has been validated with a forthcoming “group‑battle” mode, demonstrating seamless layout switching and real‑time data binding across all installed clients.