潍坊网站制作价格,上海人才引进网,win8建立网站,wordpress美观简介#xff1a; 支付宝客户端的动态化技术经历三个阶段#xff1a;现阶段也就是第三阶段是实体组件部分光栅化的hybrid模式#xff0c;Cube 就是该模式下的产物。 如标题所述#xff0c;笔者将持续更新《Cube 技术解读》系列文章。本文为Cube系列首篇文章#xff0c;后续…简介 支付宝客户端的动态化技术经历三个阶段现阶段也就是第三阶段是实体组件部分光栅化的hybrid模式Cube 就是该模式下的产物。 如标题所述笔者将持续更新《Cube 技术解读》系列文章。本文为Cube系列首篇文章后续文章笔者会更侧重于技术详解包括不限于Cube卡片技术栈一篇Cube小程序技术栈一篇质量KITE工具ACT一篇性能优化一篇等。背景
支付宝客户端的动态化技术经历三个阶段。第一个阶段是nativeweb的hybrid模式以webview为基石。第二阶段是实体组件模式把html描述的组件和css样式信息映射到实体组件并且把实体组件的事件传递到js层进行处理。第三阶段是实体组件部分光栅化的hybrid模式Cube是第三阶段的产物。
Cube起源于native页面的动态化诉求产品形态表现于Cube卡片。随着小程序概念的出现Cube融入了支付宝小程序技术栈产品形态为轻量级的支付宝小程序解决方案相对于使用浏览作为核心的web小程序。这篇文章是一个综述也是Cube系列的首篇文章。
技术选型
Cube的准确诞生时间很难确定大致在16和17年之间比RNReactNative晚上一年。Cube诞生的主要原因是native页面的动态化诉求。钱包改版的频率高给研发的压力很大于是想到把高频改版的页面动态化。RN和Flutter的出现给了我们一个很好的观察视角即业界优秀的科技公司是如何看待动态化这个话题以及它们的答案。起步阶段我们达成以下共识
独立研发自主可控。我们没有选择基于RN的开源代码来实现我们的动态化解决方案也没有Flutter公布源码后切换到Flutter。这么做是考虑到两点第一点技术栈的演进要掌握在自己手里不希望被牵着鼻子走第二点开源项目的产品化成本并不低后期的维护成本也不低服务业务技术克制。首先我们没有足够能力和资源来支撑一个通用技术产品服务于钱包业务是第一位的简单说就是贴着业务走。其次我们拒绝只求花里胡哨的技术demo把核心能力做好把产品成熟度做好考虑拿到业务价值是第一位的。
基于上面两个共识我们的技术选型如下
选择Javascript作为逻辑语言选择CSS的某个子集作为界面描述语言自绘制text/img/div/scroller 原生组件 input, animationmap, audio, video …的混合渲染模式。
阿里在前端的积累比较多Cube选择拥抱前端采用javascript和css是自然的事情。默认js引擎是quickjs。没有选择v8有两个判断v8太重内存开销和库加载速度都不理想Cube的应用场景大概率不需要v8提供的jit能力。我们额外引入了第三方的 wamr 作为webassemby引擎且在编译构建工具上支持javacript和assemblyscript混合开发。Flutter开源后受到很多人的追捧在很多文章和ppt上都看到了“Flutter完全独立于平台层的渲染管线的优势”表述认为比RN映射实体组件的方式要高级很多。我们不认为Flutter的渲染管线的性能优于操作系统的渲染管线毕竟设备和操作系统可以垂直整合利用一些设备特性。此外是否自建渲染管线应该取决于业务诉求而不应该盲目的追求技术。
Cube的自建渲染管线仅限于自绘制标签如前所述包括text/img/div/scroller使用平台层的canvas api直接绘制在系统的view上如果某颗子树的标签都是自绘制标签这颗子树会被“拍平”绘制在一个view上。自绘制标签以外的标签都是用映射原生组件的方式并且封装了统一的实体组件映射这些协议提供给开发人员。目前Cube的业务场景主要集中在移动端也简单尝试过往linux/rtos平台移植。如果后续业务逐渐扩展到linux/rtos我们会考虑进一步完善自绘制一个是把平台层的canvas api收敛到skia另一个是内置layer compositor。
当前状态
在承接业务的过程中Cube大致沉淀了2种业务形态分别是Cube卡片和Cube小程序。
Cube卡片的作用是给native页面赋予区域化的动态能力提高业务迭代和运营效率。钱包接入的卡片也分为两类一类是没有js能力的简单卡片支持表达式和vifvshow这类构建时控制DOM树的操作追求近似native的速度另一类是具备js能力的复杂卡片用来支持一些复杂的业务。Cube卡片在钱包已经大规模应用pv超过100亿接入的场景参考截图包括不限于首页、理财、我的等tab页以及卡包、出行、支付结果页等二级页面。
Cube卡片的定位也是优先服务于钱包内的一二方业务如果要想提供给三方开发者区域动态化的能力我们推荐小程序widget。此外我们正在着手把Cube卡片能力输出给中小型金融机构以及互联网公司。 Cube 是作为渲染引擎来引入小程序技术栈。小程序基础设施包括容器前端框架渲染引擎脚本引擎。容器可以理解成Appx/渲染引擎/脚本引擎之间的聚合层代码提供包管理/JSAPI/安全管控/钱包核心服务等功能。移动端上小程序默认的渲染引擎是UCCube小程序应用很有限。相对于UC来说Cube在包大小/启动速度/列表滑动流畅性/内存消耗上有一些优势但是劣势也非常明显——Cube支持的css能力不足且Cube的开发工具不完善。基于此从19年开始Cube投入了巨大的人力来扩充css能力。Cube 是除浏览器内核外支持 CSS 较完善的渲染引擎支持flex/inline/block等布局方式伪类和伪元素z-index以及相对和绝对定位层级管理。我们也投入大量的精力试图建立类似devtools功能的工具。
这些努力一定程度上改进了开发效能但仍然无法满足前端同学的诉求。我们逐渐意识到在浏览器性能不是主要瓶颈的场景下前端开发者不大会接受浏览器的一个子集。于是Cube小程序开始转向IoT场景面向浏览器跑不起来或者体验极差的场景。Cube小程序作为某种应用开发栈对试图建立三方开发者生态的客户是有一定的吸引力。目前我们主要的精力在电视大屏端感兴趣的同学可以在天猫魔盒上体验Cube小程序也可以在别的盒子以及智能电视上下载[酷喵影视](酷喵官网。 在卡片和小程序之间实际上还有一个中间地带即单页。这个页面可以是全屏也可以是漂浮在空中的半屏。Cube早期尝试过h5单页面向高频率营销场景。它的技术栈和小程序几乎完全一样不同的是h5单页没有容器的概念从服务端下载到端上的不是小程序包而是嵌入了Cube构建产物的h5页面。h5单页接入过红包码业务和蚂蚁森林的二级页面因为维护成本陆续下线。h5单页不成功并不意味着单页的需求不存在。近期探索的小程序widget其实就属于单页的范畴——我们希望widget能够让服务前置承载一定的交互逻辑同时也限制它的能力便于管控适合三方开发者。 技术架构
Cube的内部有两个大的模块一个是CubeKit负责对接js引擎且封装平台差异也包括了开发调试工具。另一个是CubeCore是用c代码实现的渲染核心逻辑。
对于Cube小程序支持tinyApp-dsl子集移动端上使用jscore/v8作为js代码的执行引擎IoT设备上使用quickjs对于Cube卡片支持基于精简vue的card-dsl。简单的卡片直接解析AST来渲染页面复杂卡片支持用户用js写一些简单逻辑并且通过quckjs来驱动dom树的更新。
移动端上Cube和Web小程序共用一个容器代码。在IoT设备上我们持续投入人力到Appx和容器的垂直整合中。从目前的数据来看IoT上的Cube小程序相对移动端的Cube小程序有不小的基础性能优势。在电视端上Cube小程序的基础性能数据是包体积5.5mb内存消耗32mb淘宝特价板小程序为例冷启动耗时34s。随着垂直整合的深入未来Cube小程序的基础性能会进一步的改善。 质量体系这个话题我放在技术架构里讲原因是它本身是技术架构的一部分。做业务开发测试人员可以遍历用户场景有bug修bug。基础软件所承载的业务场景只是无限样本中很小的一部分业务场景的回归没有问题不能够保证引擎没有问题——最坏的情况是问题持续累积直到某一天突然爆发出来。这个时候再想解决问题已经积重难返。所以基础软件的研发迫切需要某种提前暴露潜在问题的手段这个手段不可能借助某个测试资源而是研发团队自己建设。
浏览器的WPT测试用例集合给了一个很好的参考Cube也建设了这样一套基础能力样本集合以及配套的样本自动化执行框架KITE投入到版本迭代代码提交中。截止目前我们基本能做到单日粒度的自动巡检支撑我们在已有大量的业务场景的情况下对引擎做升级和重构下图是引擎基础能力巡检工具的截图。 开发工具链这个话题我也放在这里讲。Cube的直接客户不是用户而是业务方的开发同学。在项目初期就要考虑到工具这块比如调试器的设计、预览容器、日志设计、低代码搭建平台等等。在扩展业务过程中工具链某种程度上比Cube本身还要重要毕竟它是客户的第一印象。我们遇到过前期技术调研时客户因为工具的不完善而拒绝使用。业务接入后除了能力上业务方也会对工具提供各种要求在协助排查问题时也会发现新的工具需求贯穿产品的整个生命周期也是维系客户粘性的重要工作。随着Cube大规模应用于业务后我们在工具上投入的精力逐渐超过了功能技术迭代本身。
回顾未来规划
回顾过去5年Cube一路跌跌撞撞中途差点夭折能走到今天实属不易。从个人视角Cube能活下来依赖“上下坚持”。一方面上面的决策者坚持投入19年及以前几乎没有像样的业务价值另一方面一线的同学坚持做一件事没有技术追求是不可能挺过途中的各种坎坷。我们期待能Cube未来应用到物联网操作系统毕竟应用开发技术栈是操作系统的核心技术之一。
Cube未来的规划继续坚持“紧贴业务”和“技术克制”把产品做好把开发者服务好把技术打磨好。重点的发展方向如下
鉴于Cube卡片可以运行在32MB内存/400Mhz的RTOS设备上进一步探索在物联网设备上的落地推广Cube小程序在电视大屏端的应用和落地探索商业模式。
如前所述后续更新文章我会更侧重技术详解针对卡片技术栈、小程序技术栈、质量KITE工具ACT、性能优化等进行深入解读与畅聊。
原文链接 本文为阿里云原创内容未经允许不得转载。
