在 iOS 和 Android 零碎近期推送的更迭版本中，零碎环境曾经逐步倒退出了将局部内容和服务前置化展现的趋势。
同时，随同着富媒体内容井喷式增长以及内容的多样化、年轻化，一款挪动利用如何能无效晋升动态化经营效率，也成为了各行业产研与经营的重要课题。
在上述技术能力和行业需要的双重背景下，「蚂蚁动静卡片」孕育而生。
「蚂蚁动静卡片」现正式上线 mPaaS，欢送宽广开发者登录阿里云账号返回 mPaaS 控制台开明试用。
以下内容为「蚂蚁动静卡片」新品发布会全程回顾。
点击这里观看全程回放
蚂蚁动静卡片，实现 App 首页的麻利更新
<u>via 青葶 - 蚂蚁团体 mPaaS 产品经理 </u>
蚂蚁动静卡片是基于支付宝的全新卡片技术栈，实现 App 首页的麻利更新。
蚂蚁动静卡片 Cube 是蚂蚁团体外部自研的一套跨平台、动态化的卡片解决方案，是服务于利用页面内的区域动态化技术，面向内容经营，帮忙产品技术晋升开发效率和经营效率。
每一个动静卡片独立嵌于原生页面内的一个区域，区域内容通过卡片模板进行展现。在支付宝的首页，疫情服务助手、蚂蚁森林或领取页面，都是通过卡片的形式实现的。
卡片具备以下几方面的劣势：
① 跨平台的一致性：一套代码实现多端成果对齐。
② 动态化：卡片内能够进行页面构造款式以及业务逻辑的动态化更新。
③ 高性能：卡片的更新以卡片包的模式公布，它的包体积十分小，具备极致的性能和内存。
动静卡片是通过支付宝 App 业务深度打磨的技术栈，它包含客户端和云端，具备稳定性和可靠性（低于十万分之一的 crash 率）。同时，它有欠缺的开发调试工具，比方编译、预览、调试、公布等。
蚂蚁动静卡片的利用场景次要围绕内容经营，它能够实现新一代挪动端动静研发的模式。随同着富媒体内容井喷式增长以及内容的多样化、年轻化，为晋升用户转化率、留存率，互联网以及传统行业都对挪动利用的内容经营有着日益减少加强的诉求。如何晋升内容的动态化经营效率，成为了各行业产研以及经营的重要课题。
而他们的诉求，都能够通过卡片来实现。
为什么挪动端 App 须要动静卡片？
上图为蚂蚁动静卡片与原生 native 页面、web 页面、Flutter、RN 的比照。在跨平台、开发效率、性能、包体积大小、接入革新老本、公布粒度等方面，动静卡片都具备较大的劣势。尤其在公布粒度上，卡片能够实现在部分页面或某一个小程序或子利用层面上进行公布，且公布效率极高，公布即可见。同时卡片的包体积十分小，革新的接入老本也很低，并且具备多端的跨平台一致性。
Cube 通过长达四年的研发周期，通过类前端的开发语言，有着比较完善的研发体系。通过了支付宝钱包等大规模的利用，在首页、财产 Tab 和生存 Tab 都实现了良好的落地成果。
动静卡片对业务的价值在于可能帮忙研发人员疾速响应经营诉求，它的技术指标是兼顾用户体验和研发效率。
在客户端，卡片出现的成果如上图右侧所示，它由两局部组成，别离是卡片模板和卡片数据。客户端通过获取卡片模板，再获取卡片数据，最终渲染出终端的款式。
卡片模版蕴含了卡片布局、卡片逻辑和卡片款式。其中逻辑蕴含埋点信息，以及比方在什么状况下卡片要展现何种款式等业务逻辑。
蚂蚁动静卡片的产品价值能够从三个维度来阐释：
① 面向开发：领有高效开发的个性。通过精简的 VUE 语言、欠缺的调试工具等，缩小发版，晋升开发效率。
② 面向产品 / 经营：领有实时更新的能力。每一次发版或有内容更新的时候，通过预置好的卡片模板将经营内容进行更新并推送即可。这也意味着大多数状况下，产品更新只须要公布一个卡片，而不须要进行整个 App、整个小程序或整个界面的更新公布。从而使得经营效率和产品的需要落地效率很高，能够反对多个业务场景进行一个落地，也能够满足差异化和个性化的经营诉求。
③ 面向终端用户：提供了晦涩体验。卡片能够媲美于原生体验，晦涩度甚至优于原生。同时得益于包体积较小、性能好、占用内存少，面向重大用户时会有更晦涩的体验。
蚂蚁动静卡片的产品架构分为四层：
① 技术层：通过 Cube 的内核衍生出了两个模块，别离是 Cube 卡片和将来将公布的轻量级小程序技术栈。
② 产品层：基于 Cube 卡片衍生出的产品有蚂蚁动静卡片 Cube 和蚂蚁动静卡片的智能版面；基于小程序衍生出的有 Cube 高性能小程序以及 Cube 高性能小程序 - 智能搭建。
③ 设施层：反对挪动端和 IoT 端。在卡片层面上更宽泛实用于挪动端，而高性能小程序可能兼顾挪动端的低端设施、IoT 设施或大屏一体机等。
④ 场景层：实用于富媒体的数字化经营场景，蕴含金融、泛娱乐、互联网、交通、物联网等。
对于器重内容经营的行业，蚂蚁动静卡片可能提供高性能、高效率的内容经营，实用于千人千面的实时内容经营、舆情应急治理、运维应急治理，或产品的 AB 测试、最小化性能的更新等。须要紧急更新内容或动态化更新的场景下，不须要公布版本，只需更新卡片内容即可。
卡片反对的组件包含腰封、feed 流、视频、浮窗、广告等原生反对的组件。相比于 Flutter 与 H5 无奈反对腰封，且只能反对整个页面的公布，Cube 提供了原生以及局部动态化能力，可能反对的场景更为宽泛。
场景 1：经营场景下的动静卡片公布和智能版面千人千面。
上图左下角出现了两个不同模板的动静卡片，它们的数据也不同。能够通过公布不同的卡片模板以及调用后端的不同数据，实现卡片的动态化更新以及千人千面的按需展现。整个首页即版面，能够针对不同人群设置不同的版面。
场景 2：支付宝联合 mPaaS 新一代挪动端动静研发。
上图右下角出现的支付宝首页，其中蓝色局部是原生开发为主，体验最佳、性能最优；两头局部是外部一些动静的子利用，采纳 cube 小程序开发，兼顾体验和动态性；最下方大盘晴雨表以及其余 Tab 详情页采纳 cube 开发，具备部分动态化或单页动态化的高性能。
Cube 智能版面是基于动静卡片、智能引擎实现页面整体布局的千人千面。页面由若干个能够动静渲染的卡片模板组成，动静卡片的模板与业务数据进行对接，针对不同的人群定向推送。智能引擎能够通过版面的配置实现不同人群、不同内容的版面调整。
版面也能够与现有的一些 mPaaS 其余产品联合，比方短视频直播、终端智能、低代码搭建、LBS、可视化埋点等，实现整体解决方案的输入。
以支付宝首页动态化智能版面为例，能够看到沉闷和不沉闷两种人群的版面是有差别的。针对不沉闷的人群，首页以优惠和公益为主；针对沉闷用户，首页会显示其深度关联的业务，比方大盘晴雨表、理财热点等。此外，同样的用户，开市和闭市后理财卡片的款式和内容会不同，以及早晨会呈现蚂蚁森林、步数兑换能量等卡片疏导提醒。
Cube 高性能小程序是基于大屏或 IoT 场景实现的新一代开发需要，它是基于 Cube 渲染引擎进行的页面级或子利用级的解决方案，是一种高性能、动态化的小程序解决方案，具备跨平台一致性、动态性、高性。同时在开发侧复用小程序 DSL 子集，上手更简略。
Cube 高性能小程序的实用场景多为大屏的 IOT 场景或一些低端设施的小程序，也适宜 App 动静单页、惯例 App 里的小程序。它在低端设施上的性能更佳，相比于内部的小程序，Cube 高性能小程序能够媲美原生的体验，因而在低端设施上更节俭内存，且晦涩度更好。
它的外围劣势次要在于以下两个方面：
① 高效开发：复用小程序的开发语言，缩小发版，提高效率。
② 流程体验：针对大屏 IoT 或机顶盒等比拟老旧的设施，能够达到原生 native 的体验，也能够实现动静公布，流畅性也远高于传统的内部小程序。
上图为蚂蚁动静卡片与 H5 的成果比照。
左侧为冷启动、有缓存状况，卡片的启动速度更疾速；右侧为滑动、有缓存状况下，卡片的渲染成果更晦涩，速度也更快。
上图为蚂蚁动静卡片与原生的成果比照，整体差别并不大，卡片的性能能够媲美于原生。
动静，高效，蚂蚁动静卡片的内核逻辑
<u>via 京君 - 蚂蚁团体高级技术专家 </u>
蚂蚁动静卡片封装了独立的 SDK，并在 SDK 外部实现了卡片的渲染能力和 JS 相干的逻辑能力，利用能够非常简单不便地接入 SDK。同时为了进步卡片的渲染性，在外部实现了卡片间的复用以及卡片内组件的复用。
另外，动静卡片还实现了以下扩大能力：
① 扩大组件协定：卡片外部提供了内置组件，比方文本、图片、div 等。通过对内置组件进行组合，可能实现大部分业务场景的诉求。然而有一些非凡场景心愿可能扩大本人的组件能力。举个例子，比方业务在客户端曾经实现了一些视频组件、直播组件定制化的能力，但仍然心愿这些组件可能在卡片上实现混渲染并达到动静下发的能力。提供了扩大组件协定后，只须要在现有组件上实现扩大的组件协定，用注册的自定义扩大组件标签来写模板，即可达到组件在模版内实现混合渲染的目标。
② 扩大 JSAPI：针对一些客户端有的能力，能够在卡片内通过 JSAPI 来调用。通过实现 JSAPI 协定，扩大 JSAPI，即可在卡片外部写 GS 逻辑的时候间接调用端上的公共能力。
利用接入动静卡片后，次要工作是创立卡片来实现内容的动态化。SDK 提供了创立卡片的接口，创立的卡片即为 card 实例。页面里的一个 view 对应一个 card。能够通过 view 实现内容和逻辑，并生成 card，通过 card 实现内容的动态化。每一个 card 都有卡片模板，由对立的 DSL 负责写卡片模板的布局、款式以及卡片内的 JS 逻辑。DSL 内置的组件标签以及扩大组件都能够在模板里应用。
卡片的零碎架构分为以下四层：
- 应用层：次要负责数据加工解决、卡片模板的版本治理以及对外负责 API 的协定封装。
其中模板治理次要依据不同的客户端版本下发不同的模板，依据高版本的模板实现动静降级，保障客户端的卡片能实时更新，达到动静渲染的目标。能够用不同的版本治理卡片的款式和布局，而在模板外部，因为反对 JS 逻辑的编写，也能够反对逻辑渲染的能力。在单个模板外部也能够依据不同的服务端下发数据条件来实现不同的款式渲染，然而这会导致模板的业务逻辑特地多，难以保护。
因而，通过不同的模板的版本来治理更不便，也比拟适宜大部分动态化场景。
- 逻辑层：包含 JS 框架和模板引擎，通过模板引擎实现模板款式的解析、属性数据的绑定以及逻辑渲染、指令构建。指令构建是指依据模板的布局、款式属性，构建出不同节点的指令来散发到渲染层做节点渲染。此外，逻辑层还实现了比拟小的 JS 框架，用于辅助模板的动静计算能力。
- 渲染层：次要负责渲染模型的计算，包含布局、分层计算、渲染工作的构建以及光栅化。渲染层蕴含了两类不同的 UI，别离是实体 UI 和虚构 UI。实体 UI 指一些简单组件，比方输入框、列表以及自定义的扩大组件；虚构 UI 指通过 Canvas CPI 绘制的组件，包含内置的文本组件、图片组件、DIY 的容器组件等。
- 平台层：封装了 Canvas CPI 和平台 UI 接口。实体 UI 的布局通过平台层的接口来实现。
在 JSFramework 层实现了很小的 JS 显示式框架，设计初衷是为了实现高性能，因而只是实现了响应式的能力，而没有过多裁减 JS 框架的能力。咱们抉择了 QuickJS 引擎作为卡片的 JS 引擎, 它的体积比拟小，而且性能比拟高，非常适合动静卡片场景。此外，这一层也扩大了 JSApi 和 Timer 异步工作的能力。
Card Engine 层次要包含了卡片的 Module 治理、组件治理、简略模板的表达式、形象语法树的解析以及 DOM 的 diff 计算。
RenderEngine 层是整个渲染的外围的模块，包含布局、动画能力 (2D、3D)、Render、Layer、手势和其余通用事件。Render 次要负责计算一些渲染相干的数据，Layer 次要负责分层的计算。
动静卡片的高效得益于线程模型的设计。运行时的常驻线程次要有以下几个：
① Bridge 线程：负责 Js 指令、Node 树构建、以及相干节点的款式解析和布局的计算。
② Render 线程：负责 Render 树和 Layer 树的构建以及分层绘制树、手势相干的数据计算和渲染数据的计算。其中 Render 即渲染的起始数，Layer 即分层绘制数。
③ Paint 线程：负责绘制指令的构建以及最终的光栅化。Paint 线程是多线程，可能反对多任务做渲染绘制，进步渲染性能。
④ 主线程：次要包含手势辨认以及 UI 治理。
除了以上四个次要线程，在初始化阶段，还有 worker 线程以及 IO 相干的线程。
数据模型次要蕴含以下四棵树：
① NodeTree：原始的节点树，布局的计算以及数据的变更都依赖于它。
② RenderTree：渲染的变形的数。它的层级可能会发生变化，比方模板里 zIndex 波及到一些层级变动，做 render 树计算后最终的层级会与理论的 zIndex 能力统一，因而 render 树它会产生节点层级的调整。
③ LayerTree：它次要的作用是分层解决。不同的节点组件可能在同一层进行渲染绘制，而每一个 Layer 节点都是独立的渲染容器，其中蕴含了很多虚构节点，都在同一层里进行渲染。因而每一个 Layer 节点之间都是独立的，能够实现并发渲染。
④ PaintTree：在每一个 Layer 的节点外部会有虚构节点树，它们在一层内渲染，但同时也有本人的层级关系。
从最开始的原始数据，通过加工，到 NodeTree、RenderTree，最终到 LayerTree，最终是以 LayerTree 为渲染容器。每一个 Layer 节点对应一个独立的渲染工作，它们相互之间没有任何关系，能够实现并发渲染。上面那个就是一卡片的，它整个在初始化到最终上屏的这么过程。
上图下方的 AB 两张卡片的上屏全过程。首先从 UI 线程触发上屏，在 worker 线程里进行初始化，实现后进入 Render 进行分层计算、手势绘制工作计算，再到 paint 线程进行多线程并发渲染，最终回到 UI 上屏。
上图能够看到 A 卡片的外部实现了多线程的渲染，卡片之间是互相独立的，可能反对异步渲染，且可能保障较低的白屏概率。
卡片的生产 / 工作流程如下：研发期次要负责卡片的编译、调试和预览。卡片实现编译调试后，再通过卡片关联后盾实现卡片的上传和公布。公布实现之后，在端上通过 CardSDKName 获取到最新公布的卡片，即可在设施上实现动态化渲染卡片内容。依据不同的卡片模板能够渲染不同的卡片款式、布局。
ACK 工具提供了卡片的调试、编译性能。通过 ACK 工具能够疾速迁徙新工程，并编译调试代码，最终通过 playground 预览。客户端 playground 集成 到 debug 包里，可能通过 ACK 工具在本地做编译并预览。DSL 应用了 VUE 的子集语法，能够用前端的任何 ID 来编写，最终应用 ACK 工具做编译、预览即可。
接下来为卡片从新建到最终预览的全流程演示。
首先，通过 ack-h 查看其中波及的命令。
其中有卡片初始化的命令、简略的脚手架、工具名以及预览。
接下来，通过 act init 命令初始化新建卡片工程。
上图为根底的卡片信息包，蕴含了卡片的门路、名字等信息。
用 VSCode 将卡片关上。
上图左侧即卡片的工程文件，包含工程配置文件、main.vue（卡片款式、逻辑文件）、manifest.json（卡片的配置文件、模版本号、卡片名称）、mock.json（本地 mock 文件）。
关上 main.vue，其中 template 字段蕴含了卡片次要的节点款式、布局等，script 蕴含了 JS 的变量申明、生命周期、JS 逻辑等。methods 外面能够定义 JS 办法，template 里绑定的 click 事件内定义了 onClick 办法，能够在其中写一些本人的逻辑。
style 内能够自定义节点的款式。
新建完模板后，须要通过“act prepare && act server”指令生成二维码，用以与调试工具的连贯。
只须要用 debug 调试工具扫描二维码，客户端就可能与工具的本地模板建设连贯了，即可进行调试和预览。
应用“act build”命令编译本地模板。编译实现后，左侧新增了 dist 目录，它是模板的编译产物。
输出“act preview”预览指令，设施显示如下图：
对代码进行如下批改。
编译，预览后，设施显示如下：
ACT 提供了 alive 指令，批改模板之后只需保留，不须要手动编译、预览，即可查看最终成果。
接下来为绝对简单的模板演示。
在新建性能后，须要从新扫码建设连贯。通过 build 指令预览，成果如下：
在代码内退出 key frame 动画，预览查看当前能够看到成果十分晦涩。
蚂蚁动静卡片曾经落地于支付宝钱包的诸多场景，有了很多积攒和积淀，实际也证实了它的性能和稳定性都可能禁受住考验，心愿它能被更多开发者看见并应用。
END