Evolution of Web Container Architecture: From AEF to CEF and Future Enhancements

Browsers are familiar to everyone. This article introduces how our application integrates browser capabilities through three aspects: container architecture evolution, functional enhancements and stability guarantees, and future evolution.

Background: Web containers have become an essential part of client applications, providing rich pages and interactions. In the QianNiu client, the Web container hosts the open container (evolving from H5 plugins to mini‑programs) and core features such as chat and message center.

Container Architecture Evolution

Initially, different operating systems used different engines (IE on Windows, WKWebView on macOS). With Chromium’s rise, many teams customized Chromium. QianNiu built its own Application Embedded Framework (AEF) based on Chromium source.

Application Embedded Framework (AEF)

AEF encapsulates control interfaces (navigate, refresh, etc.), event responses (load success/failure, crashes, redirects), JS‑C++ interaction via render delegate, and extensions such as custom protocols.

Chromium Embedded Framework (CEF)

CEF, an open‑source BSD‑licensed project, provides most of AEF’s functionality. Switching to CEF reduces duplicated work and improves security.

Container Framework Switch

We migrated from AEF to CEF, isolating the Browser process from the main client to improve stability. The new multi‑process model separates UI (Browser) and rendering (Render) processes.

Remote Components

Inspired by COM, we introduced remote components that expose services via RPC, allowing flexible architecture adjustments without changing the caller.

New JS Injection Method

A unified interface now injects JS nodes without DLL injection, simplifying development.

Render Group Optimization

We assign a RenderID to each WebView, grouping pages (chat, third‑party, mini‑programs) into dedicated render processes to reduce memory overhead and improve stability.

Network Interception & Security

To mitigate security risks, we intercept all network requests (including WebSocket) and apply whitelist mechanisms, supporting iframe‑level control.

White‑Screen Detection

Client‑side detection monitors render frames to identify white‑screen issues more accurately than front‑end DOM checks.

Future Evolution

Plans include better memory reclamation (tab‑sleeping), enhanced white‑screen detection, and continued security hardening.

Team Introduction

The article is authored by the Taobao Tech cross‑terminal team responsible for the QianNiu desktop client.