Design and Evolution of the Container Communication Layer in NetEase Yanxuan Mobile App

Mobile client development has progressed from a traditional single‑client model to a "big front‑end" approach, extending the technical boundary with containers such as H5, React‑Native, Flutter and mini‑programs. The NetEase Yanxuan app continuously evolves its container solutions to better serve business and development needs.

This article concentrates on the communication layer of the containers, presenting the shortcomings of the early architecture and the overall solution adopted for the multi‑container communication design.

1. Limitations of the early communication architecture

High development and maintenance cost: each new container required a separate adaptation of JSBridge, FlutterPlugin, etc., leading to duplicated work.

Coupling and migration difficulty: container communication was tightly coupled with business logic, making reuse across different apps hard.

High learning and collaboration cost: lack of unified naming, design and review standards caused inconsistencies and steep onboarding.

2. Goals of the redesign

Support multiple containers (H5, Flutter, future containers) with a single adaptation layer.

Business‑agnostic design that can be introduced to new projects without re‑implementing logic.

Maintain backward compatibility with existing logic while minimizing refactor cost.

Provide a clear process for design, development, testing and release.

3. Unified communication protocol – NativeBridge

A unified protocol called NativeBridge was created to standardize communication between native and any front‑end container. It is platform‑independent and can be extended to Web, Flutter, RN, etc.

The protocol defines request and response fields such as handlerName , data , _header , code , and message . Example request/response formats are shown below.

// 读取剪切板内容消息的NativeBridge协议格式

// 请求消息格式
{
    "_header"  : {
        "protocol": "message"
    },
    "handlerName" : "readClipboard",
    "data" : {}
}

// 成功回调格式
{
    "code"      : 200,
    "message"   : "",
    "data"      : {"result":"something in clipboard"}
}

// 失败回调格式
{
    "code": 404,
    "message": "Not Found"
}

Login event notification example:

// 登录事件通知NativeBridge协议格式

// 事件消息（event）
{
    "_header"  : {
        "protocol": "event"
    },
    "handlerName" : "onUserLogin",
    "data": {}
}

// 监听消息
{
    "handlerName" : "_addEventListener",
    "data" : {
        "event" : "onUserLogin"
    }
}

// 移除监听消息
{
    "handlerName" : "_removeEventListener",
    "data" : {
        "event" : "onUserLogin"
    }
}

Support‑query example:

// 查询原生端是否支持读取剪切板的NativeBridge协议格式

// 请求格式
{
    "_header"  : {
        "protocol" : "support"
    },
    "handlerName" : "readClipboard"
}

// 回调格式
{
    "_header"  : {
        "protocol" : "support"
    },
    "code": 200 // 200 支持，404 不支持
}

4. Core module design

NativeModule : base class for all native modules (clipboard, calendar, routing, sharing, …).

NativeBridge : bridge that adapts container‑specific protocols (JSBridge, FlutterPlugin, RCTModule) to the unified NativeBridge format.

NativeBridgeService : parses and packages messages, forwarding them to NativeModuleManager and converting responses back.

NativeModuleManager : creates, loads and dispatches messages to the appropriate native modules.

5. Communication flow

Container formats the request according to its own bridge (JSBridge, FlutterPlugin, etc.).

The bridge sends the message to the native side.

Native adapters (NativeBridgeJS, NativeBridgeFlutter, NativeBridgeRN) convert the bridge message to the unified NativeBridge format.

NativeBridgeService parses the unified message and extracts handlerName and parameters.

NativeModuleManager routes the request to the corresponding NativeModule .

The native module executes the business logic and returns data.

NativeBridgeService wraps the result into a NativeBridge response.

The response is converted back to the container‑specific format and delivered.

6. Componentization and standards

The communication layer was split into independent components: protocol layer, adaptation layer, business‑agnostic base components, and weak‑business components. This enables one‑click integration, clear boundaries, and easier maintenance.

Naming conventions were enforced (camelCase, clear verbs, event names prefixed with on ), and design rules such as atomic interfaces and separation of concerns were introduced.

Testing was improved by adding QR‑code‑driven test pages for each interface, allowing isolated verification without relying on full business flows.

7. Outcomes

Standardized, consistent communication across multiple containers.

Expanded capabilities (message, event, support queries) and reduced version‑checking overhead.

Significant reduction in development effort – from hundreds of container‑specific implementations to a single set of native modules plus adapters.

Lower maintenance cost and higher code readability.

Enhanced business agility, with the new layer being adopted in other B‑side products.

8. Future work

Continue to promote the solution to more applications, refine the interface management platform, and further evolve the container architecture to meet emerging business and technical requirements.