跨端框架

技术揭秘与趋势分析

大纲

跨端框架的技术目标
跨端框架的技术方向
跨端框架的技术揭秘
跨端框架的技术要点
跨端框架的发展趋势

跨端框架的技术目标

Why there is a cross-end framework?

理想：六边形战士

只要写一遍，

哪里都能跑；

不仅写的快，

而且性能好；

生态能复用，

上线Bug少。

现实：软件设计中没有银弹

跨端框架的技术目标

提升人效
抹平差异

跨端框架的技术方向

What are the technical directions of the cross-end framework?

方向 1：偏前端（→客户端）

基于 WebView 的增强

ionic
CORDOVA
SONIC
小程序（WebView）
离线包方案

方向 2：偏客户端（→前端）

基于 DSL 的 Native 增强

DinamicX
Tangram(七巧板)
Jasonette
DreamBox
MTFlexbox

方向 3: KMM

Kotlin Multiplatform Mobile 代码共享

KMM: K2 编译器

前端: .kt 源码 →[解析器]→AST→[语义分析器]→ FIR

后端: 输入 FIR

JVM IR 后端: → [生成器/优化器] → .class
JS IR 后端: → [生成器/优化器] → .js
LLVM 后端: → [生成器/优化器] → .bc

KMM: 工程结构

跨端代码(Shared module)+壳工程(Android/iOS App)

方向 4：大终端

基于 GPL 的 Native 增强

Native Widget
React Native / Hippy / Weex
Flutter
基于 Flutter 的自绘框架
WebF，Kraken，Kun，Skyline
基于 Skia / OpenGL 的自绘框架
TDF，Hippy 3.0，Weex 2.0，MagicBrash，Waft

框架抽象

跨端框架的技术揭秘

The solution of cross-end framework

Kun

Kun 的架构图

JS: QuickJS
CSS: Yoga + Kraken + FFI
Debugger: CDP
Test: Golden test

Kun 的构成

脚本引擎：QuickJS
渲染引擎：Flutter Engine

Kun 的特点

不支持完备的 W3C 标准，只支持各标准子集，包括：HTML 标签、CSS 样式集、WebAPI 标准
提供了一些定制的 Element 组件
组件的实现上采用 Widget 拼接的方式

WebF

WebF 的构成

脚本引擎：QuickJS + 轻量优化
渲染引擎：Flutter Engine

特点：

Dart 层实现 CSS，C++ 层实现 WebAPI，对标 W3C 标准。

思考 🤔

CSS 应该如何实现？

Kun / Hippy 的问题

一条渲染链路存在两次 Layout，更新频率过大
内联样式的开发体验不好，且信息密度太高

FFI 瓶颈问题，不足以支撑。

CSS 样式实现的最优解

解法 1: CSS 在 Dart 层实现，样式更新依靠 RenderObject 的 Layout，无需走 FFI
解法 2: DOM 与 CSS 全使用 C++ 实现，剥离 Dart 层

问题：引入 CSS 导致 RenderObject Tree 难以维护

思考 🤔

RenderObject Tree 应该如何管理？

思路

把 RenderObject 做薄：原子级渲染组件，上层通过组合 RenderObject 来实现复杂功能。
把 RenderObject 做厚：集成大量的布局渲染能力于一身，上层通过样式表驱动 RenderObject 渲染。

思路 1: 把 RenderObject 做薄

复杂度太高，每个样式规则的计算都需要一层一层检查推断，导致维护效率下降。

思路 2: 把 RenderObject 做厚

Diff 的复杂度也会大幅下降。

思考 🤔

如何保证实现效果对标浏览器标准？

解决方案

堆测试用例，截图对比
WPT

Weex 2.0

Weex 的演进过程

架构分析

WeexAbility：容器和能力扩展，URL 拦截、缓存、基础 API、三方扩展等。

WeexFramework：通用基础框架。封装页面实例，实现 DOM、CSSOM、WebAPI 标准，解耦脚本引擎和渲染引擎。

QKing：脚本引擎，基于 QuickJS 的魔改。

Unicorn：自绘渲染引擎。实现 CSS 能力，包括完整的节点构建、动画、手势、布局、绘制、合成、光栅化渲染管线，可跨平台。

WeexUIKit：原生 UI 渲染引擎，封装了原生组件。

TDF

Tencent Dynamic Framework

涉密，已屏蔽

Waft

WebAssembly Framework for Things

AIoT 的尝试

Android App：运存太低，性能受限
云应用：成本太高
Waft

Waft 的构成

脚本引擎：WebAssembly
渲染引擎：Skia 封装

脚本引擎选型：WebAssembly

选型用例存疑：

用例太简单，无法发挥 JS 引擎的优势
AOT 对比解释执行，不公平
QuickJS 还有很大的优化空间
没有对比其他有 JIT 模式的引擎
不同 wasm 的实现，性能不同

fib(40)	安卓(1+5t)	iOS(iPhone11)
js	4000ms	13000ms
wasm	2048ms	4224ms
Native	963ms	395ms

涉密可以进一步优化 wasm 性能。

Waft 的问题

CSS 仅支持部分子集
W3C 标准（DOM Elememt、WebAPI）实现欠缺

决定了应用场景 👉🏻 简单的 IoT 页面

MiniX

MiniX 的构成

脚本引擎：QuickJS / JerryScript / V8+JSCore
渲染引擎：Flutter Engine

跨端框架的技术要点

The Essentials of Cross-end Framework

应用场景

动态化
IoT
Desktop
车机
一核多生态

方案要点

脚本引擎
渲染引擎
Debugger
工程化

应用场景: 动态化

没有动态化能力的跨端技术

是没有灵魂的

动态化思路

基于 WebView 的增强
基于 DSL 的 Native 增强
基于 GPL 的 Native 增强
插件化（Android）
利用 OC 运行时动态化特性（iOS）

核心：在 Runtime 期间加载可执行代码，并调用。

应用场景: Desktop

Desktop 的优势：

内存占用略高于 Qt，但优于 CEF、Electron
包体积小，流畅性、CPU 占用媲美 Qt
多端复用，Mobile App 可以快速适配

Desktop 的不足：

组件支持程度不及移动端
引擎成熟度有待提升，32 位、PlotformView 不支持

应用场景：车机

技术选型

操作系统：Android / Linux
2D 渲染：Flutter + 动态化 / Qt
3D 渲染：Unity / Unreal Engine

脚本引擎

脚本引擎选型思路

JS 引擎：仅作为胶水语言
Dart VM：利用 Flutter Engine
WARM: 需要设计 DSL 和实现渲染引擎

JS 引擎选型思路

双引擎：JSCore + V8
单引擎：Hermes
单引擎：QuickJS
单引擎：自研 JS 引擎

QuickJS 的问题

没有 JIT
手动 GC，难以管理和维护，可优化
缺失行号记录
缺失 Debugger
缺少 code cache
缺少 inline cache
缺少内存泄露检测能力
Bytecode 有优化空间 (如 SSA)

JSBinding 优化

方案1: 使用 JSExport 和 JSExportAS

方案2: 使用 C Export 将方法和属性用 JSStaticFunction 和 JSStaticValue 进行绑定

	耗时(ms/百万次)
JSExport	1278
C Export	452

自制 JS 引擎的优缺点

优点：

及时支持最新的标准
不需要 polyfill
保证多端一致性

缺点：iOS 无法开启 JIT

JIT 的问题：

需可写可执行的内存页
引擎冷启动预热耗时增加
内存占用变大
包体积偏大

渲染引擎

渲染引擎选型思路

Flutter Engine
Skia
OpenGL / Vulkun / Metal

整体思路：精简管线，同步光栅化

Debugger 方案

Debugger

一种可以让 JavaScript Runtime 进行中断，并可以实时查看内部运行状态的应用。

调试协议

CDP: Chrome DevTools Protocol
DAP: Debug Adapter Protocol
自建协议

举例: Weex 2.0 中的 Debugger 实现

举例: JS Debugger for QuickJS

DAP

举例: Debugger 运行流程

涉密，已屏蔽

跨端框架的工程化方案

工程化方案

资源加载方案
降级处理
版本管理
研发模式

举例：Weex，Kant

大纲

跨端框架的技术目标
跨端框架的技术方向
跨端框架的技术揭秘
跨端框架的技术要点
跨端框架的发展趋势

理想：六边形战士

只要写一遍，

哪里都能跑；

不仅写的快，

而且性能好；

生态能复用，

上线Bug少。

跨端框架的技术目标

提升人效
抹平差异

基于 DSL 的 Native 增强

DinamicX
Tangram(七巧板)
Jasonette
DreamBox
MTFlexbox

方向 4：大终端

基于 GPL 的 Native 增强

跨端框架的技术揭秘

The solution of cross-end framework

Kun 的架构图

JS: QuickJS
CSS: Yoga + Kraken + FFI
Debugger: CDP
Test: Golden test

问题：引入 CSS 导致 RenderObject Tree 难以维护

思路 2: 把 RenderObject 做厚

Diff 的复杂度也会大幅下降。

架构分析

WeexAbility：容器和能力扩展，URL 拦截、缓存、基础 API、三方扩展等。

WeexFramework：通用基础框架。封装页面实例，实现 DOM、CSSOM、WebAPI 标准，解耦脚本引擎和渲染引擎。

QKing：脚本引擎，基于 QuickJS 的魔改。

Unicorn：自绘渲染引擎。实现 CSS 能力，包括完整的节点构建、动画、手势、布局、绘制、合成、光栅化渲染管线，可跨平台。