![]()
作者：曾维宏(恒实)
本文为《Cube 技术解读》系列第三篇文章，之前上线的《支付宝新一代动态化技术架构与选型综述》《Cube卡片技术栈解读》欢迎大家回顾。
小程序作为动态化或者跨端开发的一种技术栈，在业界成为事实标准。Cube 作为一种轻量级小程序技术栈，具有体积小、启动快、内存占用低等特点，也比较适合“即用即走”的小程序场景。以下将重点介绍 Cube 小程序技术栈与技术演进实践（若无特殊说明，所有的数据和图表都是针对小程序）。
Cube 渲染小程序
模块组成
小程序视角，Cube 渲染引擎主要由以下模块组成：
![]()
- Components：主要是小程序规范里的组件；
- Layout：支持 Inline，Block，Flex，Inline-Block，Inline-Flex 等多种布局方式，还包括文本分词，断行等计算；
- Style：支持样式解析，样式匹配，样式继承，伪类和伪元素等多种选择器；
- Rendering：管理渲染相关 Render Tree，图片资源请求调度等；
- Animation： JS 和 CSS 动画实现；
- JS Bridge：和 JS 引擎桥接；
- JS Engine：目前支持 V8，JSC，QuickJS；其中 Android 下支持 V8，QuickJS；
- Compositor：用于动画和图层的合成器（开发中）。
线程模型
Cube 小程序技术栈内部有这么几个线程：Bridge，Layout，Render，Paint，UI 等。
![]()
- Bridge 线程：执行 JS；与 AppX 桥接的类 DOM 的 JSAPI；处理 JS 相关事件；
- Layout 线程：布局计算；样式计算与匹配；维护 Layout Tree；
- Render 线程：维护 Render Tree；绑定数据；分层；
- Paint 线程：生成绘制命令；
- UI 线程：平台事件分发；UI 布局。
小结：
- 并行布局，异步绘制：这里的并行是指 JS 执行，Layout 布局 以及 Render 三者完全并行处理。由于 Layout 和 Render，Paint 等不在一个线程，因此是异步绘制；
- 多个线程协同工作，有点像 CPU 的 5 级流水线。
值得注意得是：Web 渲染引擎有个特点就是和 Node 相关的 DOM 操作必须和 JS 在一个线程。这就导致解析 HTML，布局，样式计算，DOM，JS （包括垃圾回收）都在一个线程里。带来的后果就是只有解析完文档才能看到 UI 效果，这也是 Web 渲染小程序白屏时间较长的一个原因。
Cube小程序技术栈，将“DOM操作” 和 JS 执行解耦。因此 JS 的 GC 不会影响 UI 呈现。这种实现对于加快小程序启动非常有帮助。由于布局计算和 JS 执行也解开耦合，因此一般不会由于 JS 执行阻塞 UI 交互。
Cube 小程序技术栈的特点
- 体积小，启动快：主 so 只有 2.8 MB（如果包括 Ariver，AppX，InsideSDK，整体小程序技术栈最小是 5.7MB）。另外可以享受到 OS 的红利（包括 UI 的初始化和缓存）；
- 高性能：接近于原生体验；
- 内存占用小：小程序技术栈初始化后（包括 Inside SDK，Cube，AppX），大约只需要 7.5 MB；
- 支持 Android，iOS 双端。
与 Web 引擎对比
下面仅仅针对小程序场景与 Web 引擎对比：
![image.png]()
技术演进
让小程序业务低成本适配 Cube 渲染小程序，需要做三方面的工作：
- 拥抱 Web 技术，补齐前端开发常用的能力：包括 CSS，小程序组件等；
- 完善相关工具：包括开发，调试，Profile，发布，打包等；
- 针对 Cube 的架构特点，深入优化，并拉开和 Web 渲染的差异。提供更好的用户体验。
新的流式布局（Flow Layout）
最初 Cube 小程序使用只支持 Flex 布局 Yoga 用于布局计算。后面升级成支持 Block，Flex，Inline-Block等多种布局方式的 Flow Layout。从而解决开发者只能使用 Flex 布局的困扰。目前两个布局引擎 Cube 内部都支持。其中 Flow Layout 主要用在小程序，Yoga 用在卡片。两者能力差异如下：
![image.png]()
支持 CSS 样式表
老版本的 Cube 只支持内联样式和简单的 CSS 选择器；然而小程序并没有约束 CSS，因此 Cube 扩充支持 CSS 样式表，样式继承，多种选择器等。从而使得 Web 渲染切换到 Cube 渲染，适配成本大大降低。甚至部分小程序可以做到在小程序 IDE 里基于 Web 渲染开发，然后打包成 Cube 渲染产物在真机上预览。前端同学无需进行过多的修改和适配。
新老 Cube 版本，选择器支持上的差异如下：
![]()
注：
- [1] 老版本 Cube 是指：钱包 10.2.0 以前版本；
- 新样式能力基本上对标 Web 引擎的样式能力；
- 新样式能力支持像这种复杂选择器。
div > div.jartto p span.yellow a#t1 {}
.pixel-ratio-2 .web1px::before {}
div:nth-child(2n+1) {}
input[type="button"] {}
#blue,div > div.jartto p span.yellow a#t1 {}
支持自动分词，断行（Inline Text）
最初 Cube 用的是 Android 和 iOS 提供的文本计算和绘制能力。这种技术方案（以下称为平台层 Text）存在3个问题：
- 性能问题：特别是 Android 下，利用 Android 平台层的接口实现文本布局计算，导致在文本较多的情况下，布局耗时在渲染整体耗时里占比较高；
- 富文本特性：富文本以及许多文本特性支持较麻烦；
- 各平台上实现文本效果存在细节差异或者兼容性问题。
针对上述问题，在 Flow Layout 基础上增强支持 Inline Text 布局计算文本。基于 Inline Text 可以较轻松实现以下富文本，图文混排，分词，自动换行等。
![]()
1.富文本
![]()
2.自动换行和分词
Inline Text 实现前后的文本样式对比如下：
![image.png]()
注：
- 假设原有 Cube 采用平台层接口实现的文本特性称为：平台层 Text；
- 表示实现细节上不完善或者不完全支持；
- 在 Inline Text 基础上可以实现功能丰富的富文本组件；
- 值得一提的是：该实现非常精巧，对于 Cube 包体积只增加了 170KB。具体细节后续文章详细探讨。
文本布局计算耗时对比（文本节点较多场景）：
![image.png]()
采用 QuickJS 替代 V8
V8 虽然是性能最高的 JS 引擎，但是存在内存占用大，初始化较慢等不足。在 IoT 或者低端设备上这些不足会被放大。因此在这些设备上，Cube 采用 QuickJS 取代 V8。一方面降低内存占用，另外一方面提升初始化性能。
Cube 内部目前适配了多个 JS 引擎，具体如下：
- 在 Android 移动端上使用 V8 和 JSI
- iOS 上使用 JSC
- IoT 等低端设备上使用 QuickJS
另外我们在开源 QuickJS 基础上做了些优化工作。优化的结果大致如下（后续文章将详细介绍）：
![image.png]()
支持动画和多媒体组件
除了上述基础组件和能力之外，动画和多媒体也是部分小程序不可缺少的。因此我们扩展支持了 Video，Canvas、Lottie，Live Player 等组件支持。并应用于 TV 大屏小程序、小游戏以及直播场景上。
在低端设备上，如何提高动画帧率并且降低内存占用也做了深度的优化。以下是 Video 和 Canvas 组件在小程序中的效果图：
![image.png]()
支持多种模式的小程序产物
目前 Cube 支持多种模式的小程序产物：Native，Cube，Shared。
- Native 模式：对应的是旧的 Cube 渲染小程序模式，不支持 CSS 样式表，只能支持内联样式和有限的几种 CSS 选择器。性能最高，兼容性较低；
- Cube 模式：在 Native 模式进化而来，支持 CSS 样式表和多种 CSS 选择器。性能良好，支持常用的 CSS 样式和特性（包括样式继承，多种 CSS 选择器）；
- Shared 模式：为了降低 Web 渲染的小程序迁移或者过渡到 Cube 渲染而开发。在同一个小程序产物里既支持 Web 渲染一部分页面又支持 Cube 渲染一部分页面。而且 Cube 渲染的页面支持样式表。这样在性能和兼容性平衡。小程序产物相对于 Web 渲染的小程序，产物体积增加不会超过 10%。
![image.png]()
注：如果需要 Web 产物兜底，则 Native 模式 和 Cube 模式的小程序产物，比 Shared 模式大。
当前工作
Cube 小程序在 TV 和 POS 机上和相关团队，一起打磨小程序技术栈（包括渲染引擎，JS 引擎，AppX，Ariver 容器）等。
在 TV 上面临的问题：
- 内存少：有的设备只有 512MB 内存，长列表滚动容易卡；
- 需要支持焦点切换；
- CPU 主频较低：有的只有 1GHz。
短中期目标是用小程序技术栈替代 WeeX 单页。当前进展如下：
- 小程序启动性能上超过 WeeX 单页（低端设备上优势更明显）；
- 内存占用上，小程序初始化后内存占用小于 10MB，典型小程序整体内存占用在 32MB 左右。
具体细节后续文章详细总结。
在 POS 机上面临的问题：
在 POS 机上跑点餐小程序，主要有面临以下问题：
- 内存少：部分设备只有 512MB 内存，容易出现卡死和 OOM；
- CPU 核心少：部分 CPU 只有双核（硬件性能大约是主流手机的 1/5）；
- 长列表滚动卡。
短中期目标是用小程序技术栈替代 Flutter 开发的 App。当前进展如下：
- 小程序首屏启动性能提升了 30%+；
- 小程序重点的交互场景的页面，比如：购物车，商品详情页等，都已接近 Flutter App；
- 首页滚动帧率达到 50，用户已经难以感知和 Flutter 的差异（Flutter 帧率是 60）；
- 小程序内存占用下降了 30%（本地测试已无卡死和 OOM）。
该场景主要是文本节点较多的长列表。采用了非常多的优化方法，后续文章详细总结介绍。
总结
为了适配小程序，Cube 渲染引擎在布局计算、样式能力、组件支持，还有开发工具等在小伙伴一起努力下取得了较大的进展。同时在低端设备（比如：IoT 设备）或者性能敏感场景，Cube 小程序性能优化，降低内存占用也取得了不错的效果。而未来面对多种多样的 IoT 设备，还需要加速技术演进以支持更多的场景。欢迎大家一起来交流讨论。
关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！
