在 iOS 和 Android 体系近期推送的更迭版别中,体系环境现已逐步发展出了将部分内容和服务前置化展现的趋势。
一起,伴随着富媒体内容井喷式添加以及内容的多样化、年轻化,一款移动运用怎么能有用进步动态化运营功率,也成为了各职业产研与运营的重要课题。
在上述技能才能和职业需求的双重背景下,「蚂蚁动态卡片」孕育而生。
「蚂蚁动态卡片」现正式上线 mPaaS,欢迎广阔开发者登录阿里云账号前往 mPaaS 控制台注册试用。
以下内容为「蚂蚁动态卡片」新品发布会全程回顾,
点击这里观看全程回放
蚂蚁动态卡片,完结App主页的灵敏更新
via 青葶-蚂蚁集团 mPaaS 产品经理
蚂蚁动态卡片是依据付出宝的全新卡片技能栈,完结 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 的作用比照。
左边为冷启动、有缓存状况,卡片的启动速度更快速;右侧为滑动、有缓存状况下,卡片的烘托作用更流通,速度也更快。
上图为蚂蚁动态卡片与原生的作用比照,全体差异并不大,卡片的功用能够比美于原生。
动态,高效,蚂蚁动态卡片的内核逻辑
via 京君-蚂蚁集团高档技能专家
蚂蚁动态卡片封装了独立的 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