乐趣区

关于cube:Cube-技术解读-Cube-小程序技术详解

jiezi

本文为《Cube 技术解读》系列第三篇文章，之前上线的《支付宝新一代动态化技术架构与选型综述》与《Cube 卡片技术栈解读》欢送大家回顾。

魔方卡片（Cube）已在「支付宝」App 中被广泛应用，同时，现已反对在 mPaaS 侧对外商业化输入，欢送宽广开发者登录 mPaaS 控制台体验及应用。

而 Cube 小程序则是 Cube 技术除了魔方卡片（Cube）外的另外一种状态，将次要利用与智能电视、POS 机以及其余 IoT 畛域，目前还在研发打磨中，欢送宽广开发者交换探讨。

小程序作为动态化或者跨端开发的一种技术栈，在业界成为事实标准。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 引擎比照：

技术演进

  • 让小程序业务低成本适配 Cube 渲染小程序，须要做三方面的工作：
  • 拥抱 Web 技术，补齐前端开发罕用的能力：包含 CSS，小程序组件等；
  • 欠缺相干工具：包含开发，调试，Profile，公布，打包等；
  • 针对 Cube 的架构特点，深刻优化，并拉开和 Web 渲染的差别。提供更好的用户体验。

新的流式布局（Flow Layout）

最后 Cube 小程序应用只反对 Flex 布局 Yoga 用于布局计算。前面升级成反对 Block，Flex，Inline-Block 等多种布局形式的 Flow Layout。从而解决开发者只能应用 Flex 布局的困扰。目前两个布局引擎 Cube 外部都反对。其中 Flow Layout 次要用在小程序，Yoga 用在卡片。两者能力差异如下：

反对 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 个问题：

  1. 性能问题：特地是 Android 下，利用 Android 平台层的接口实现文本布局计算，导致在文本较多的状况下，布局耗时在渲染整体耗时里占比拟高；
  2. 富文本个性：富文本以及许多文本个性反对较麻烦；
  3. 各平台上实现文本成果存在细节差别或者兼容性问题。

针对上述问题，在 Flow Layout 根底上加强反对 Inline Text 布局计算文本。基于 Inline Text 能够较轻松实现以下富文本，图文混排，分词，主动换行等。

1. 富文本

2. 主动换行和分词

Inline Text 实现前后的文本款式比照如下：

注：

  • 假如原有 Cube 采纳平台层接口实现的文本个性称为：平台层 Text；
  • √示意实现细节上不欠缺或者不齐全反对；
  • 在 Inline Text 根底上能够实现功能丰富的富文本组件；
  • 值得一提的是：该实现十分精美，对于 Cube 包体积只减少了 170KB。具体细节后续文章具体探讨。

文本布局计算耗时比照（文本节点较多场景）：

采纳 QuickJS 代替 V8

V8 尽管是性能最高的 JS 引擎，然而存在内存占用大，初始化较慢等有余。在 IoT 或者低端设施上这些有余会被放大。因而在这些设施上，Cube 采纳 QuickJS 取代 V8。一方面升高内存占用，另外一方面晋升初始化性能。

Cube 外部目前适配了多个 JS 引擎，具体如下：

  • 在 Android 挪动端上应用 V8 和 JSI
  • iOS 上应用 JSC
  • IoT 等低端设施上应用 QuickJS

另外咱们在开源 QuickJS 根底上做了些优化工作。优化的后果大抵如下（后续文章将具体介绍）：

反对动画和多媒体组件

除了上述根底组件和能力之外，动画和多媒体也是局部小程序不可短少的。因而咱们扩大反对了 Video，Canvas、Lottie，Live Player 等组件反对。并利用于 TV 大屏小程序、小游戏以及直播场景上。

在低端设施上，如何进步动画帧率并且升高内存占用也做了深度的优化。以下是 Video 和 Canvas 组件在小程序中的效果图：

反对多种模式的小程序产物

目前 Cube 反对多种模式的小程序产物：Native，Cube，Shared。

  • Native 模式：对应的是旧的 Cube 渲染小程序模式，不反对 CSS 样式表，只能反对内联款式和无限的几种 CSS 选择器。性能最高，兼容性较低；
  • Cube 模式：在 Native 模式进化而来，反对 CSS 样式表和多种 CSS 选择器。性能良好，反对罕用的 CSS 款式和个性（包含款式继承，多种 CSS 选择器）；
  • Shared 模式：为了升高 Web 渲染的小程序迁徙或者过渡到 Cube 渲染而开发。在同一个小程序产物里既反对 Web 渲染一部分页面又反对 Cube 渲染一部分页面。而且 Cube 渲染的页面反对样式表。这样在性能和兼容性均衡。小程序产物绝对于 Web 渲染的小程序，产物体积减少不会超过 10%。

注：如果须要 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 设施，还须要减速技术演进以反对更多的场景。欢送大家一起来交换探讨。

本文转自公众号「阿里巴巴挪动技术」，作者：曾维宏 (恒实)

退出移动版