Baidu Open-source Mini-program Framework Architecture Evolution and Performance Optimization Practices

This presentation covers two main parts: the overall framework and evolution of Baidu Smart Mini Programs, and performance optimization practices for the mini-program framework.

Part 1: Baidu Smart Mini Program Overall Framework and Evolution

The mobile internet has been seeking balance between NA (Native App) and H5, where NA offers better performance and capabilities while H5 provides higher flexibility. Rendering approaches are divided into two camps: NA rendering (e.g., RN, Flutter) and Web rendering (e.g., Baidu's Light Apps and Mini Programs).

Baidi's three representative products in the Web rendering camp are Light Apps, Direct Access, and Mini Programs. Light Apps are standard H5 with some native APIs like location. Direct Access is technically similar to Light Apps. Mini Programs are essentially constrained H5 with 300+ APIs and 30+ UI components including video and maps.

Mini Programs are constrained for two reasons: maintaining consistent user experience (H5 is too flexible with JS changing interfaces anytime) and security considerations (since powerful APIs like phone numbers and accounts cannot be easily exposed).

Constraints include: using custom language 'swan' instead of direct HTML, and having two physically isolated stacks in the runtime layer - rendering stack and JS execution stack - to ensure security.

The SWAN framework architecture consists of: developer base library (swan-js) that converts swan code to HTML and encapsulates client capabilities; swan-native layer with API and component implementations including dual-stack management and Extension mechanism for host customization; Porting Layer for open-source interface with host; and host base capability layer.

From the frontend perspective, the dual-stack structure allows one host client to run multiple mini-programs. Each mini-program has a master executing framework JS and developer JS, with one master corresponding to multiple slaves (user-visible interfaces). From the client perspective, master can use WebView or JS engine (V8/jscore) for higher efficiency, while slaves use WebView with cache for faster creation.

NA elements integrate with H5 in two ways: overlay relationship (NA floats above H5, requiring scroll synchronization) and same-layer relationship (NA is in the same layer as H5, allowing H5 elements to overlay NA elements).

For multi-host support, Baidu Smart Mini Program is an open system running on multiple hosts. Hosts must pass CTS testing before distributing mini-programs. Optional capabilities like AI and push can be implemented selectively. Extension mechanism allows hosts to customize capabilities by implementing interfaces at both JS layer and Porting Layer.

Part 2: Performance Optimization Practices

Mini-program loading stages: Loading (title and tab appear), FP (First Paint), FCP (First Contentful Paint - initial data rendered), FMP (First Meaningful Paint - real-time content loaded), and TTI (Time to Interactive - all elements displayed).

Baidu established FMP metric at end of 2019, showing 1.9s at 80th percentile. FP framework layer was optimized from nearly 3s to about 1.1s. The goal is to make mini-programs approach native app experience.

Developer performance optimization focuses on: package size and business data.

Package Size Optimization: Recommended to keep under 1MB because downloading package accounts for 60% of startup time. At 80th percentile, 1MB takes 1s+ to download. Techniques include: sub-package and independent sub-package technology (separating low-PV pages from main package), and resource compression (moving images to servers, converting PNG to JPEG for 90% reduction, removing unused resources). Target: single package under 1MB with under 200 files.

Data Fetching Optimization: Purpose is to quickly show content and reduce white screen time. Framework skeleton screen (loaded in parallel during master appjs execution) is recommended over business skeleton screen (which causes ~300ms delay). For request optimization: 'early' (send requests in onLaunch event, not blocking with unnecessary permissions like GPS) and 'less' (defer non-critical requests, fetch only one screen of data).

Rendering Optimization: setData is expensive (even 1K data takes ~20ms). Best practices: merge multiple setData calls into one, reduce data volume in setData, update only changed variables rather than entire objects.

Performance self-check has three phases: development (tool ratings, performance panel, logging), testing (screen recording, high-speed camera), and post-launch (developer platform).