Leveraging Mini‑Program Stack & Flutter for High‑Performance Mobile Cross‑Platform Development

Preface

Since its inception, the mini‑program has become a vital part of the WeChat developer ecosystem, opening new possibilities for external developers. Beyond its impact on WeChat, the mini‑program stack also influences the development of the WeChat client itself.

Cross‑Platform Practice in WeChat Client

Since 2012, the WeChat client team has used cross‑platform technologies to address inconsistencies across platforms. The earliest component, mmnet, was built in C99 in October 2012 to solve network inconsistencies and later evolved into the open‑source project mars, gaining wide industry recognition. Similar open‑source components include wcdb and mmkv.

After establishing basic cross‑platform components, the team sought a unified UI development approach to quickly iterate on internal business innovations. Mini‑programs, with their rapid development cycle, became the focus.

The team identified four goals for an effective cross‑platform development model:

Reduce platform differences : Minimize platform‑specific development burdens.

Improve development efficiency : Enhance productivity across coding, debugging, running, and testing.

Native performance and experience : Deliver performance and user experience indistinguishable from native.

Easy‑to‑learn, controllable tech stack : Ensure a gentle learning curve, safety, and controllability.

Can the mini‑program stack meet these requirements?

Mini‑Programs and the WeChat Client

WeChat mini‑programs use a front‑end‑centric stack that smooths platform differences, allows dynamic deployment, and offers performance close to native. However, detailed examination reveals issues such as font inconsistency on Android due to WebView rendering and frame drops in image‑heavy scenarios.

Examples include a restaurant feature built with a mini‑program that runs on both iOS and Android, where Android suffers from font mismatches and occasional lag during image scrolling.

Cross‑Platform Development Based on Mini‑Program Stack

The mini‑program architecture consists of two parts:

View layer: Transforms UI described in WXML/WXSS into H5 elements rendered by WebView.

App Service layer: Executes JavaScript logic and accesses WeChat JSAPI, separating logic from view.

To address performance limitations, the team explored native rendering. By dumping the Virtual DOM and CSS from the mini‑program framework and mapping them to native components in Java, they achieved a 27.5% frame‑rate increase and 14‑23% memory reduction on Pixel 2 XL.

However, maintaining native implementations across platforms proved costly, prompting the search for a unified cross‑platform rendering solution.

1. Native Rendering Optimization

The UI description is converted to native components, inspired by ReactNative. The LV‑CPP module, written in C++, handles DOM and CSS parsing, layout calculation, and delegates JavaScript execution to V8 or JavaScriptCore.

When WXML/WXSS changes, the front‑end library computes a Virtual DOM diff, sends operation commands to LV‑CPP, which updates nodes, matches CSS, performs layout, and invokes native view rendering.

LV‑CPP supports various CSS selectors (ID, tag, class, combinators) using a reverse‑order parsing strategy from WebKit.

2. LV‑CPP

LV‑CPP abstracts layout processing, allowing different rendering modules to be swapped. It converts colors to decimal values for consistent rendering.

3. Flutter

Initially dismissed due to Dart learning costs, Flutter was later reconsidered for its high‑performance rendering. Benchmarks showed Dart outperforming JavaScript and approaching Java performance.

Flutter’s advantages include rapid development with hot reload, expressive UI, reactive framework, native SDK access, and near‑native performance.

4. Flutter Rendering Optimization

The rendering layer was replaced with Flutter widgets, still supporting a simplified subset of WXML/WXSS.

LV‑CPP processes layout and passes it to Flutter via a custom dart2cpp bridge, enabling direct memory‑level communication without message encoding, achieving over 300,000 calls per second compared to ~4,000 with Platform Channels.

5. Communication Challenges

Mini‑programs run JavaScript in a JS engine, while the layout layer is C++. Bridging JS and C++ required a JS Binding approach that moves platform‑specific code to C++ for better performance.

Flutter communication originally uses Platform Channels, which are inefficient. The team introduced dart2cpp, exposing C++ interfaces to Dart, allowing direct calls in AOT mode.

// Dart example
bool systemSrand(int seed) native "SystemSrand";

// C++ example
void SystemSrand(Dart_NativeArguments arguments) {
  Dart_EnterScope();
  bool success = false;
  Dart_Handle seed_object = HandleError(Dart_GetNativeArgument(arguments, 0));
  if (Dart_IsInteger(seed_object)) {
    bool fits;
    HandleError(Dart_IntegerFitsIntoInt64(seed_object, &fits));
    if (fits) {
      int64_t seed;
      HandleError(Dart_IntegerToInt64(seed_object, &seed));
      srand(static_cast<unsigned>(seed));
      success = true;
    }
  }
  Dart_SetReturnValue(arguments, HandleError(Dart_NewBoolean(success)));
  Dart_ExitScope();
}

Additional bridges (cpp2dart, js2dart) enable bidirectional calls between C++ and Dart, and indirectly between JavaScript and Dart.

Conclusion and Outlook

The WeChat client’s cross‑platform journey evolved from early open‑source components to a modern mini‑program‑centric stack enhanced by native rendering, LV‑CPP, and Flutter. This approach improves UI consistency, performance, and reduces maintenance overhead, while keeping the developer experience unchanged.

Future work includes further performance tuning, expanding CSS support, and exploring new front‑end technologies.

Q & A

Q1. Will mini‑programs abandon WebView for Flutter?

A1. No. WebView remains flexible for external developers; the Flutter experiment is limited to internal client scenarios.

Q2. How does Flutter handle complex CSS?

A2. Only a lightweight subset (WXSS‑LITE) is supported; complex CSS is intentionally omitted for performance.

Q3. Is js2dart open‑source?

A3. The team is considering open‑sourcing the solution.

Q4. What about iOS package size and hot‑patching?

A4. iOS integration is being studied to balance package size, dynamic updates, and developer tooling.