Cube 技术解读 | 支付宝新一代动态化技术架构与选型综述

‍‍

支付宝客户端的动态化技术经历三个阶段。第一个阶段是native+web的hybrid模式，以webview为基石。第二阶段是实体组件模式，把html描述的组件和css样式信息映射到实体组件，并且把实体组件的事件传递到js层进行处理。第三阶段是实体组件+部分光栅化的hybrid模式，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/bytecodealliance/wasm-micro-runtime ) 作为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卡片的作用是给native页面赋予区域化的动态能力，提高业务迭代和运营效率。钱包接入的卡片也分为两类，一类是没有js能力的简单卡片，支持表达式和vif&vshow这类构建时控制DOM树的操作，追求近似native的速度；另一类是具备js能力的复杂卡片，用来支持一些复杂的业务。Cube卡片在钱包已经大规模应用，pv超过100亿，接入的场景参考截图，包括不限于首页、理财、我的等tab页，以及卡包、出行、支付结果页等二级页面。

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

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

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

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

回顾过去5年，Cube一路跌跌撞撞，中途差点夭折，能走到今天实属不易。从个人视角，Cube能活下来依赖“上下坚持”。一方面，上面的决策者坚持投入（19年及以前几乎没有像样的业务价值）；另一方面，一线的同学坚持做一件事，没有技术追求是不可能挺过途中的各种坎坷。我们期待能Cube未来应用到物联网操作系统，毕竟应用开发技术栈是操作系统的核心技术之一。

Cube未来的规划继续坚持“紧贴业务”和“技术克制”，把产品做好，把开发者服务好，把技术打磨好。重点的发展方向如下：

1. 鉴于Cube卡片可以运行在32MB内存/400Mhz的RTOS设备上，进一步探索在物联网设备上的落地；

咱们下篇文章再见。