如何做彩票网站信息,奉化市住房和城乡建设局网站,公众号登录平台入口官网,网站设计需要什么软件简介#xff1a;「蚂蚁动态卡片」新品发布会全程回顾 在 iOS 和 Android 系统近期推送的更迭版本中#xff0c;系统环境已经逐渐发展出了将部分内容和服务前置化展示的趋势。
同时#xff0c;伴随着富媒体内容井喷式增长以及内容的多样化、年轻化#xff0c;一款移动应用…简介「蚂蚁动态卡片」新品发布会全程回顾 在 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 动画预览查看以后可以看到效果非常流畅。
蚂蚁动态卡片已经落地于支付宝钱包的诸多场景有了很多积累和沉淀实践也证明了它的性能和稳定性都能够经受住考验希望它能被更多开发者看见并使用。
原文链接
本文为阿里云原创内容未经允许不得转载。
