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

“ 如标题所述，笔者将持续更新《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）+ 原生组件