Inside GMTC 2021 Mini‑Program Talks: Cross‑Platform Tricks & Performance Secrets

Summary of GMTC 2021 Mini‑Program Sessions

Preface

In early July I attended the GMTC Beijing 2021 mini‑program development track and listened to four talks covering cross‑platform development, cloud‑based code generation, the Mpx framework used by Didi, and the rendering framework of Douyin.

Jingxi Cross‑Platform Mini‑Program Practice

Project Background

Package size 20 MB

100+ developers across multiple teams

Peak traffic of hundreds of millions of requests

Multiple platforms: several mini‑programs and H5 containers

Cross‑Platform Implementation

The project is built on JD’s internal Taro framework. Each page lives in its own repository, allowing independent compilation, debugging and later merging into the full app, effectively a second‑stage build. The codebase contains several technology stacks.

Taro provides built‑in environment variables, conditional compilation and platform‑specific file extensions (see Taro docs).

Home‑Page Performance Optimisation

Virtual List

The product list is long and complex, causing jank after scrolling two screens. A virtual list was introduced, with structural refactoring and custom height calculation because DOM queries are slow in mini‑programs. Rpx‑to‑px conversion differences were handled to align calculated and rendered heights.

Low‑End Device Degradation

Device classification was refined to a 2/3 high‑end, 1/3 low‑end split. For low‑end devices the team replaced carousel with a single image, switched animated GIFs to static images, reduced image sizes, and simplified modal logic.

Experience Score

The built‑in mini‑program IDE score was maximised to 100 by controlling first‑screen DOM count, image size, and setData frequency.

Code‑Size Optimisation

Package size limits forced aggressive reduction. Strategies included splitting packages, removing unused dependencies, avoiding local assets, compressing all file types, and cleaning comments.

CSS was refined by removing duplicated @font‑face definitions (231 duplicates reduced to none) and by using CSS Modules to bind class names to JavaScript, saving another ~50 KB.

Overall the bundle shrank from 631 KB to 465 KB.

Intelligent Cloud‑Integrated Code Generation (DCloud)

Evolution of Front‑Back‑End Collaboration

1990‑2005: Server‑side templates (ASP/JSP/PHP) + JS + CSS

2005‑2018: AJAX and mobile web led to “big front‑end” with ReactNative, Weex, Taro, uni‑app, Flutter.

2018‑present: Serverless shifts logic to the front‑end, making the front‑end “heavy”.

Limitations of Current Mini‑Program Cloud Development

Table‑level permissions are coarse.

Parameter validation is weak at write‑time.

Data is fragmented across different cloud providers.

uniCloud Improvements

Cross‑cloud, cross‑platform SDK.

JSON‑Schema‑driven permission and field validation DSL.

ClientDB: unified front‑end DB SDK with data components.

Schema‑2‑Code Low‑Code Generation

A visual schema can be transformed into runnable mini‑program code (details omitted).

Didi Travel’s Mpx Complex Mini‑Program Solution

Complexity Overview

Rich business logic, many scenarios, heavy map usage.

20 MB total package, >10 teams.

Multi‑platform deployment (WeChat, Alipay, QQ, ByteDance, Web).

Internationalisation support.

Mpx Architecture

Mpx extends native mini‑program syntax with Vue‑like features, using a compile‑time transformation and a runtime that handles platform differences, reactive data, mock utilities, etc.

Data Reactivity

Implemented with Object.defineProperty to trigger setData on the mini‑program side. Future versions may switch to Proxy when host support improves.

SetData Optimisation Strategies

Full data set (worst performance).

Deep diff (better but still sends unused data).

Only send changed data used by the template (Mpx’s approach, best performance).

Build and Package Optimisation

Webpack‑based compilation, split‑package analysis that accounts for JS and non‑JS assets, per‑entry size reporting, and visual dashboards.

Douyin Mini‑Program Rendering Framework

Rendering Stack

Native host app → Native runtime (Android/iOS/IoT) → Cross‑platform channel → JSSDK providing components, APIs and rendering.

Design Rationale

Internal components use Polymer‑based web components for performance; external components use a VDOM approach. Maintaining two parallel stacks caused maintenance overhead, leading to a unified component model.

Optimization Techniques

ChildFlag: static nodes receive flags to avoid runtime type checks, reducing diff cost by ~70%.

VNode Immutability: mark unchanged sub‑trees as immutable to skip diff.

Benchmarking shows the “yaw” framework (yet another web‑component) achieves top performance.

Performance Tools and Debugging

Three categories of tools are used: client‑side performance panels (CPU, memory), IDE trace tools for fine‑grained timing, and IDE scoring tools for quick health checks.

Final Thoughts

The talks highlighted practical solutions for large‑scale mini‑program development, including cross‑platform frameworks, cloud‑native code generation, aggressive bundle optimisation, and custom rendering engines. The shared experiences provide concrete guidance for teams building high‑performance, multi‑platform mini‑programs.

References

https://taro-docs.jd.com/taro/docs/envs

https://zhaomenghuan.js.org/blog/wechat-miniprogram-principle-analysis.html

https://www.zhihu.com/question/332293687/answer/738922582

https://link.zhihu.com/?target=https://www.youtube.com/watch?v=AdNJ3fydeao

https://img.w3ctech.com/VueConf2019SH_Evan.pdf