如标题所述，笔者将持续更新《Cub技术解读》系列文章。本文为Cub系列首篇文章，后续文章笔者会更侧重于技术详解，包括不限于：Cub卡片技术栈一篇，Cub小程序技术栈一篇，质量KITE工具ACT一篇，性能优化一篇等。
背景
支付宝客户端的动态化技术经历三个阶段。第一个阶段是nativ+wb的hybrid模式，以wbviw为基石。第二阶段是实体组件模式，把html描述的组件和css样式信息映射到实体组件，并且把实体组件的事件传递到js层进行处理。第三阶段是实体组件+部分光栅化的hybrid模式，Cub是第三阶段的产物。
Cub起源于nativ页面的动态化诉求，产品形态表现于Cub卡片。随着小程序概念的出现，Cub融入了支付宝小程序技术栈，产品形态为轻量级的支付宝小程序解决方案（相对于使用浏览作为核心的wb小程序）。这篇文章是一个综述，也是Cub系列的首篇文章。
技术选型
Cub的准确诞生时间很难确定，大致在16和17年之间，比RN（RactNativ）晚上一年。Cub诞生的主要原因是nativ页面的动态化诉求。钱包改版的频率高，给研发的压力很大，于是想到把高频改版的页面动态化。RN和Fluttr的出现，给了我们一个很好的观察视角，即业界优秀的科技公司是如何看待动态化这个话题以及它们的答案。起步阶段，我们达成以下共识：
独立研发，自主可控。我们没有选择基于RN的开源代码来实现我们的动态化解决方案，也没有Fluttr公布源码后，切换到Fluttr。这么做是考虑到两点，第一点，技术栈的演进要掌握在自己手里，不希望被牵着鼻子走；第二点，开源项目的产品化成本并不低，后期的维护成本也不低；服务业务，技术克制。首先，我们没有足够能力和资源来支撑一个通用技术产品，服务于钱包业务是第一位的，简单说就是贴着业务走。其次，我们拒绝只求花里胡哨的技术dmo，把核心能力做好，把产品成熟度做好，考虑拿到业务价值是第一位的。
基于上面两个共识，我们的技术选型如下：
选择Javascript作为逻辑语言；选择CSS的某个子集作为界面描述语言；自绘制（txt/img/div/scrollr）+原生组件（input,animation，map,audio,vido…）的混合渲染模式。
阿里在前端的积累比较多，Cub选择拥抱前端，采用javascript和css是自然的事情。默认js引擎是quickjs。没有选择v8，有两个判断：v8太重，内存开销和库加载速度都不理想；Cub的应用场景大概率不需要v8提供的jit能力。我们额外引入了第三方的wamr作为wbassmby引擎，且在编译构建工具上支持javacript和assmblyscript混合开发。Fluttr开源后受到很多人的追捧，在很多文章和ppt上都看到了“Fluttr完全独立于平台层的渲染管线的优势”表述，认为比RN映射实体组件的方式要高级很多。我们不认为Fluttr的渲染管线的性能优于操作系统的渲染管线，毕竟设备和操作系统可以垂直整合，利用一些设备特性。此外，是否自建渲染管线应该取决于业务诉求，而不应该盲目的追求技术。
Cub的自建渲染管线仅限于自绘制标签，如前所述包括txt/img/div/scrollr，使用平台层的canvasapi直接绘制在系统的viw上；如果某颗子树的标签都是自绘制标签，这颗子树会被“拍平”绘制在一个viw上。自绘制标签以外的标签都是用映射原生组件的方式，并且封装了统一的实体组件映射这些协议，提供给开发人员。目前Cub的业务场景主要集中在移动端，也简单尝试过往linux/rtos平台移植。如果后续业务逐渐扩展到linux/rtos，我们会考虑进一步完善自绘制，一个是把平台层的canvasapi收敛到skia，另一个是内置layr