作者：入弦

“  如题目所述，笔者将继续更新《Cube 技术解读》系列文章。本文为 Cube 系列首篇文章，后续文章笔者会更侧重于技术详解，包含不限于：Cube 卡片技术栈一篇，Cube 小程序技术栈一篇，品质 KITE& 工具 ACT 一篇，性能优化一篇等，感激大家关注【阿里巴巴挪动技术】。”

背景

支付宝客户端的动态化技术经验三个阶段。第一个阶段是 native+web 的 hybrid 模式，以 webview 为基石。第二阶段是实体组件模式，把 html 形容的组件和 css 款式信息映射到实体组件，并且把实体组件的事件传递到 js 层进行解决。第三阶段是实体组件 + 局部光栅化的 hybrid 模式，Cube 是第三阶段的产物。

Cube 起源于 native 页面的动态化诉求，产品状态体现于 Cube 卡片。随着小程序概念的呈现，Cube 融入了支付宝小程序技术栈，产品状态为轻量级的支付宝小程序解决方案（绝对于应用浏览作为外围的 web 小程序）。这篇文章是一个综述，也是 Cube 系列的首篇文章。

技术选型 & 演进

Cube 的精确诞生工夫很难确定，大抵在 16 和 17 年之间，比 RN（ReactNative）早晨一年。Cube 诞生的次要起因是 native 页面的动态化诉求。钱包改版的频率高，给研发的压力很大，于是想到把高频改版的页面动态化。RN 和 Flutter 的呈现，给了咱们一个很好的察看视角，即业界优良的科技公司是如何对待动态化这个话题以及它们的答案。起步阶段，咱们达成以下共识：

1、 独立研发，自主可控。 咱们没有抉择基于 RN 的开源代码来实现咱们的动态化解决方案，也没有 Flutter 颁布源码后，切换到 Flutter。这么做是思考到两点，第一点，技术栈的演进要把握在本人手里，不心愿被牵着鼻子走；第二点，开源我的项目的产品化老本并不低，前期的保护老本也不低；

2、 服务业务，技术克服 。首先，咱们没有足够能力和资源来撑持一个通用技术产品，服务于钱包业务是第一位的，简略说就是贴着业务走。其次，咱们回绝只求花里胡哨的技术 demo，把外围能力做好，把产品成熟度做好，思考拿到业务价值是第一位的。

基于下面两个共识，咱们的技术选型如下：

1. 抉择 Javascript 作为逻辑语言；
2. 抉择 CSS 的某个子集作为界面描述语言；
3. 自绘制（text/img/div/scroller）+ 原生组件（input, animation，map, audio, video …）的混合渲染模式。

阿里在前端的积攒比拟多，Cube 抉择拥抱前端，采纳 javascript 和 css 是天然的事件。没有抉择 v8，有两个判断：v8 太重，内存速度和初始化速度都不现实；Cube 的利用场景大概率不须要 v8 提供的 jit 能力。咱们额定引入了第三方的 wamr (https://github.com/bytecodeal…) 作为 webassemby 引擎，且在编译构建工具上反对 javacript 和 assemblyscript 混合开发。Flutter 开源后受到很多人的追捧，在很多文章和 ppt 上都看到了“Flutter 齐全独立于平台层的渲染管线的劣势”表述，认为比 RN 映射实体组件的形式要高级很多。咱们不认为 Flutter 的渲染管线的性能优于操作系统的渲染管线，毕竟设施和操作系统能够垂直整合，利用一些设施个性。此外，是否自建渲染管线应该取决于业务诉求，而不应该自觉的谋求技术。

Cube 的自建渲染管线仅限于自绘制标签，如前所述包含 text/img/div/scroller，应用平台层的 canvas api 间接绘制在零碎的 view 上；如果某颗子树的标签都是自绘制标签，这颗子树会被“拍平”绘制在一个 view 上。自绘制标签以外的标签都是用映射原生组件的形式，并且封装了对立的实体组件映射些协定，提供给开发人员。目前 Cube 的业务场景次要集中在挪动端，也简略尝试过往 linux/rtos 平台移植。如果后续业务逐步扩大到 linux/rtos，咱们会思考进一步欠缺自绘制，一个是把平台层的 canvas api 收敛到 skia，另一个是内置 layer compositor。

以后状态

在承接业务的过程中，Cube 大抵积淀了 2 种业务状态，别离是 Cube 卡片和 Cube 小程序。

Cube 卡片的作用是给 native 页面赋予区域化的动静能力，进步业务迭代和经营效率。钱包接入的卡片也分为两类，一类是没有 js 能力的简略卡片，反对表达式和 vif&vshow 这类构建时管制 DOM 树的操作，谋求近似 native 的速度；另一类是具备 js 能力的简单卡片，用来反对一些简单的业务。Cube 卡片在钱包曾经大规模利用，pv 超过 100 亿，接入的场景参考截图，包含不限于首页、理财、我的等 tab 页，以及卡包、出行、领取后果页等二级页面。

Cube 卡片的定位也是优先服务于钱包内的一二方业务，如果要想提供给三方开发者区域动态化的能力，咱们举荐小程序 widget。此外，咱们正在着手把 Cube 卡片能力输入给中小型金融机构以及互联网公司。

Cube 是作为渲染引擎来引入小程序技术栈。小程序基础设施包含：容器，前端框架，渲染引擎，脚本引擎。容器能够了解成 Appx/ 渲染引擎 / 脚本引擎之间的聚合层代码，提供包治理 /JSAPI/ 平安管控 / 钱包外围服务等性能。挪动端上小程序默认的渲染引擎是 UC，Cube 小程序利用很无限。绝对于 UC 来说，Cube 在包大小 / 启动速度 / 列表滑动流畅性 / 内存耗费上有一些劣势，然而劣势也非常明显——Cube 反对的 css 能力有余，且 Cube 的开发工具不欠缺。基于此，从 19 年开始 Cube 投入了微小的人力来裁减 css 能力。Cube 是除浏览器内核外反对 CSS 较欠缺的渲染引擎，反对 flex/inline/block 等布局形式，伪类和伪元素，z-index 以及绝对和相对定位层级治理。咱们也投入大量的精力试图建设相似 devtools 性能的工具。

这些致力肯定水平上改良了开发效力，但依然无奈满足前端同学的诉求。咱们逐步意识到，在浏览器性能不是次要瓶颈的场景下，前端开发者不大会承受浏览器的一个子集。于是，Cube 小程序开始转向 IoT 场景，面向浏览器跑不起来，或者，体验极差的场景。Cube 小程序作为某种利用开发栈，对试图建设三方开发者生态的客户是有肯定的吸引力。目前咱们次要的精力在电视大屏端，感兴趣的同学能够在天猫魔盒上体验 Cube 小程序，也能够在别的盒子以及智能电视上下载酷喵影视（https://acz.youku.com/wow/tva…!2~3~P~A）。

在卡片和小程序之间，实际上还有一个两头地带，即单页。这个页面能够是全屏，也能够是沉没在地面的半屏。Cube 晚期尝试过 h5 单页，面向高频率营销场景。它的技术栈和小程序简直齐全一样，不同的是，h5 单页没有容器的概念，从服务端下载到端上的不是小程序包而是嵌入了 Cube 构建产物的 h5 页面。h5 单页接入过红包码业务和蚂蚁森林的二级页面，因为保护老本陆续下线。h5 单页不胜利，并不意味着单页的需要不存在。近期摸索的小程序 widget 其实就属于单页的领域——咱们心愿 widget 可能让服务前置，承载肯定的交互逻辑，同时也限度它的能力，便于管控，适宜三方开发者。

技术架构

Cube 的外部有两个大的模块，一个是 CubeKit，负责对接 js 引擎且封装平台差别，也包含了开发调试工具。另一个是 CubeCore，是用 c ++ 代码实现的渲染外围逻辑。

对于 Cube 小程序，反对 tinyApp-dsl 子集，挪动端上应用 jscore/v8 作为 js 代码的执行引擎，IoT 设施上应用 quickjs；对于 Cube 卡片，反对基于精简 vue 的 card-dsl。简略的卡片间接解析 AST 来渲染页面，简单卡片反对用户用 js 写一些简略逻辑，并且通过 quckjs 来驱动 dom 树的更新。

挪动端上，Cube 和 Web 小程序共用一个容器代码。在 IoT 设施上，咱们继续投入人力到 Appx 和容器的垂直整合中。从目前的数据来看，IoT 上的 Cube 小程序绝对挪动端的 Cube 小程序有不小的根底性能劣势。在电视端上 Cube 小程序的根底性能数据是：包体积 5.5mb，内存耗费 32mb（淘宝特价板小程序为例），冷启动耗时 3～4s。随着垂直整合的深刻，将来 Cube 小程序的根底性能会进一步的改善。

质量体系这个话题，我放在技术架构里讲，起因是它自身是技术架构的一部分。做业务开发，测试人员能够遍历用户场景，有 bug 修 bug。根底软件所承载的业务场景只是有限样本中很小的一部分，业务场景的回归没有问题，不可能保障引擎没有问题——最坏的状况是问题继续累积，直到某一天忽然暴发进去。这个时候再想解决问题，曾经积重难返。所以，根底软件的研发迫切需要某种提前裸露潜在问题的伎俩，这个伎俩不可能借助某个测试资源而是研发团队本人建设。

浏览器的 WPT 测试用例汇合给了一个很好的参考，Cube 也建设了这样一套根底能力样本汇合以及配套的样本自动化执行框架 KITE，投入到版本迭代 & 代码提交中。截止目前，咱们根本能做到单日粒度的主动巡检，撑持咱们在已有大量的业务场景的状况下对引擎做降级和重构，下图是引擎根底能力巡检工具的截图。

开发工具链这个话题，我也放在这里讲。Cube 的间接客户不是用户，而是业务方的开发同学。在我的项目初期就要思考到工具这块，比方调试器的设计、预览容器、日志设计、低代码搭建平台等等。在扩大业务过程中，工具链某种程度上比 Cube 自身还要重要，毕竟它是客户的第一印象。咱们遇到过后期技术调研时，客户因为工具的不欠缺而回绝应用。业务接入后，除了能力上，业务方也会对工具提供各种要求（在帮助排查问题时也会发现新的工具需要），贯通产品的整个生命周期，也是维系客户粘性的重要工作。随着 Cube 大规模利用于业务后，咱们在工具上投入的精力逐步超过了性能 & 技术迭代自身。

回顾 & 将来布局

回顾过去 5 年，Cube 一路趔趔趄趄，中途差点夭折，能走到明天实属不易。从集体视角，Cube 能活下来依赖“高低保持”。一方面，下面的决策者保持投入（19 年及以前简直没有像样的业务价值）；另一方面，一线的同学保持做一件事，没有技术谋求是不可能挺过途中的各种崎岖。咱们期待能 Cube 将来利用到物联网操作系统，毕竟利用开发技术栈是操作系统的核心技术之一。

Cube 将来的布局持续保持“紧贴业务”和“技术克服”，把产品做好，把开发者服务好，把技术打磨好。重点的倒退方向如下：

1. 鉴于 Cube 卡片能够运行在 32MB 内存 /400Mhz 的 RTOS 设施上，进一步摸索在物联网设施上的落地；
2. 推广 Cube 小程序在电视大屏端的利用和落地，摸索商业模式。

如前所述，后续更新文章我会更偏重技术详解，针对卡片技术栈、小程序技术栈、品质 KITE& 工具 ACT、性能优化等进行深刻解读与畅聊。如你对该系列文章感兴趣，亦或是对 Cube 感兴趣，你也能够继续关注咱们。

咱们下篇文章再见。

关注咱们，每周 3 篇挪动干货 & 实际给你思考！