⽀付宝App架构的原理与实战
reactnative开发根据公开的 2018 年移动互联⽹⾏业分析报告,⽬前⽀付宝的⽉活跃⽤户已经超过 QQ ,成为国内第⼆⼤ App。
⽀付宝⼀开始仅仅只是⼀个单体应⽤的⼯具型 App,让⽤户可以在⼿机完成⽀付宝相关的业务查询和操作。2013 年后,⽀付宝逐步转型为平台型 App,平台型 App 具有服务化、模块化、⼯具组件化的特点。这个时候⽀付宝的业务不仅仅是⽀付,还需要给客户提供很多⽣活相关的服务,例如余额宝、缴电费等。2015 年后⽀付宝成长为超级 App,此时⽀付宝⾥⾯需要⽀持⼤量复杂的业务,同时开放⾃⼰的商业能⼒,⽤⾃⼰流量助⼒合作伙伴,因此整个 App ⾯临开放、动态化、⾼可⽤的挑战,⾯对这些挑战,我们把它总结为以下三点:
1.如何应对复杂的业务协同?
2.如何满⾜业务快速迭代的需求?
3.如何构建⾯向未来的开放⽣态?
利⽤ Hybrid App 架构,应对复杂的业务协同
App 的业务越来越复杂,不仅仅是内部业务,还包含了⼤量外部的合作伙伴。如果采⽤传统的 App 开发⽅式很难应对⽇趋复杂的业务场景。
1.1 Hybrid 技术⽅案选型
在 Hybrid 技术⽅案选型⽅⾯,我们通过“开发成本、⽤户体验、动态性、复杂业务⽀持能⼒、研发难度”五个⽅⾯综合考量。我们筛选出 HTML5、ReactNative/Weex、Flutter 作为备选,并将原⽣开发作为基准线完成对⽐。(考虑到近期Flutter 的热度持续⾛⾼,因此我们纳⼊ Flutter ⼀并分析。)
⾸先我们从业务开发成本⾓度来看:
•原⽣作为最基础的开发模式,需要双端都进⾏开发,⽆疑成本是最⾼的;
•其次是 ReactNative/Weex,即使是⼀次开发,同时运⾏在双端,但由于是 JS 转成 Native 组件渲染,实际运⾏起来仍然存在些许差异,导致开发者在写业务界⾯时,部分差异需要通过 Native 端定制开发来解决。整体⽽
⾔,ReactNative/Weex 已帮助业务⽅⼤幅降低开发成本;
•接下来是 Flutter,从业务开发的⾓度来说,Flutter 针对双端对齐真的下了⼤功夫。在⼤多数场景下,
Android 端开发完毕之后能⽆缝跑在 iOS 端,当然这和它⾃研的引擎有关。只不过 Flutter 需基于 Dart 语⾔开发,因此对于开发者⽽⾔,部分⽼业务移植的⼯作量需考虑在内;
•最后是 HTML5,带着成熟的语⾔,成熟的开发模式,双端⼏乎⼀样的表现等特性表明 HTML5 仍然是⽬前我们能落地的开发成本最低的⽅案。
接下来我们讨论⽤户体验:
•⾸先,原⽣的体验⽏庸置疑是最好的;
•其次是⾃有渲染引擎的 Flutter,⽆论是性能还是控件的展现形式,可以说是不亚于原⽣的体验;
•接下来便是 ReactNative/Weex ⽅案,通过将前端代码渲染成本地 Natvie 控件。在早期版本中,由于部分控件优化不到位导致 App 卡顿,因此⽤户体验的表现不⾜;
•最后是 HTML5,完全通过浏览器内核进⾏渲染,借助预置资源、内核优化等技术,HTML5 可以做到接近原⽣的体验,但总体性能仍有差异。
接着是动态性的⽀持:
在本⽂第⼆章节“离线包机制+发布平台”,我们会从快速迭代的⾓度深度分析动态性在⽀撑⾼并发业务场景下的重要性。
⾸先,动态性最优的就是 HTML5 ⽅案:可以访问在线页⾯,服务端即时⽣效,也可以通过下发资源的⽅式,进⾏动态更新;
其次是 ReactNative/Weex ⽅案,通过⼀定的定制,开发者可以将前端包热部署、热更新。不过相较于 HTML5 具备
的“在线+离线”的动态性,该⽅案仍然存在⼀定差距;
的“在线+离线”的动态性,该⽅案仍然存在⼀定差距;
接下来是原⽣,Android/iOS 双端均可以通过⼀些⿊科技⼿段,进⾏动态更新,不过由于 iOS 政策禁⽌,因此在动态性上,原⽣⽅案暂时不推荐;
最后是 Flutter,虽然有很强⼤的热重载机制,不过由于 Google 的限制,线上版本 iOS ⽆法做到热更新,因此在动态性评估中将 Flutter 排在最后。
最后我们聊下各个⽅案的实现起来的研发难度:
•这⾥我们暂时将 HTML5 放在第⼀位,因为做 HTML5 Hybrid ⽅案,离不开内核优化,内核优化就需要有⼀定内核研发能⼒,因此在开发者视⾓下 HTML5 研发难度最⾼。如果只是单纯的 HTML5 容器,研发难度就会⼤幅降低;•其次是 Flutter,⽬前在实际业务应⽤案例⽅⾯,国内较⼤体量的 App 暂时只有闲鱼团队引⽤了 Flutter;同时在Flutter 的 GitHub 中仍然存在⼤量的 Open Issues 等待解决。⽽在实战开发运⽤过程中,Flutter 的⽣命周期管理,视图栈管理,原⽣页⾯切换等问题都需要开发者在前期选型过程中便要重视;
•接下来是 ReactNative/Weex,由于这两个⽅案开源,且有⼤量成熟的技术社区⽀持,⽅案的研发难度对于开发者⽽⾔并不⾼,同时开源代码⽅便修改,更容易上⼿;
•最后是原⽣⽅案,如果不考虑做热修复的话,原⽣⽅案⽆需做任何改动,直接使⽤即可;若考虑热修复⽅案,⽬前市⾯也有⼀些成熟的开源热修复⽅案可以直接使⽤。
综上所述,我们再考虑了各⽅的优劣之后,决定采⽤“HTML5 容器+内核优化”的⽅式来应对复杂业务的开发问题。接下来我们就介绍下容器的架构。
1.2 容器架构
最上层是原⽣的 HTML5 代码,这块就是⼤家常见的 Web 开发环境,包括 HTML、CSS、Java等。
下⾯⼀层即离线包管理,这个我们在第⼆章节内进⾏详细介绍。
再往下是 HTML5 容器层,HTML5 容器作为中间层,将浏览器和⽀付宝底层框架有机结合起来,同时还提供各种⽣命周期机制、事件机制、扩展插件等内容。
在 HTML5 容器⾥⾯有个⾮常重要的概念:JSBridge。通过 JSBridge,HTML5 容器将⽀付宝框架底层以及中间件层提供的各种能⼒和 HTML5 前端代码进⾏联通,其中包括 RPC(远程过程调⽤,⽤来实现 App 和服务器通信)、⽀付、扫⼀扫等。
最下⾯是⽀付宝底层框架,提供微应⽤,微服务等概念。⼀个 HTML5 应⽤,也会被框架模拟成⼀个微应⽤,通过应⽤ID 进⾏解耦。
1.2.1 JSBridge 介绍
JSBridge 是 HTML5 容器的基⽯,桥接了 JS 环境与 Native,实现了 Native 代码和浏览器环境的双向通信,Native 代码可以通过调⽤浏览器提供的接⼝运⾏JS,从⽽实现调⽤ JS 函数、传递参数到 JS 环境等;⽽浏览器到JS环境的通信是通过 Native 拦截浏览器的请求来实现,请求可以是⽹络请求或者是⼀些内部函数的调⽤。
1.2.2 H5 容器定制化扩展
HTML5 容器提供了 2 种扩展⽅式:
•JSAPI
JSAPI ⽅式给 HTML5 页⾯增加了 Native 功能调⽤接⼝,通过实现⾃定义 JSAPI 类中的 Handler ⽅式,可以以 Native 的形式实现特定功能,例如调⽤ Native 加密函数。
•事件
•事件
HTML5 容器在状态变化时会发送事件,通过监听 HTML5 容器特定事件,可以实现对 HTML5 容器⽣命周期的处理,⽐如修改加载进度条颜⾊、修改页⾯导航栏等。事件提供了更强的定制性,完全可以满⾜对 HTML5 容器的各种⾃定义需求
1.3 容器稳定性
上⾯在研发难度中,我们提及到了,HTML5 ⽅式的研发难度是最⾼的,因为需要定制化内核进⾏性能及稳定性优化。⽬前⽀付宝采⽤的是阿⾥集团的 UC ⾃研内核,并针对⽀付宝的 HTML5 容器进⾏了深度优化和定制。如图所⽰,UC 内核和系统内核的卡顿卡死率的数据对⽐效果⾮常显著,我们可以直观地看到 Webview 稳定性的提升。
离线包机制+发布平台,满⾜业务即时更新
⽬前⽀付宝业务的另外⼀个特点就是需要快速迭代,变化的政策、突发事件都需要我们可以快速把新的业务需求触达给⽤户。但是对于 App 开发者有⼀个不容忽视的问题,就是应⽤商店审核。由于审核的存在,App 上开发的业务会有⼀个统⼀排期,⽐如说⽉底会有新版本,那么所有的业务进度都得考虑 App 的排期计划。
2.1 离线包机制
为了做到良好的⽤户体验,我们在容器中引⼊了离线包机制。通过离线包机制,我们将原有从线上加载的 HTML5 应⽤,提前下发到本地,通过读取 IO,或者是内存,进⾏页⾯的渲染,达到接近原⽣的⽤户体验。
通过发布平台,我们可以将不同的 HTML5 离线包,以单独应⽤的形式,进⾏不同维度的下发,使原来 all in 的 Native 发布模式,改为各业务线⾃⾏定制发布计划,⾃⾏制定发布标准,⾃⾏发布的并⾏发布形式,来满⾜业务的快速迭代。
2.1.1 加载机制
通过内存提前加载,定时更新,启动预加载内存等⼿段,我们将⼀个业务包需要⽤到的资源加载到内
存,从⽽使启动过程尽量⽆感知,页⾯秒开⽆⽩屏。同时,我们还有 Fallback ⼿段,保证在包损坏或者是未下载完成时,可以通过在线页⾯的形式,保证业务的 100% 可⽤性。
2.1.2 公共资源包机制
所谓公共资源包,即所有 HTML5 离线包都可能会⽤到的公共资源的集合。公共资源包解决多个 HTML5 应⽤使⽤同⼀资源产⽣的冗余问题。如 React 应⽤使⽤ ReactJS 框架代码。您可以将公共资源放⼊全局资源包,以降低 HTML5 应⽤体积。
通过公共资源包机制,可有效降低各 HTML5 应⽤的包体积,从⽽使更新率提⾼,页⾯开启速度加快。
2.2 发布平台
为了满⾜快速迭代的需求,⼀个强⼤的发布平台也是必不可少的。发布平台的核⼼指标,就是将发布内容⾼效、精准的投放到指定的设备上,为了实现这个⽬标,我们做了如下的努⼒。
2.2.1 离线包⼤⼩管控及差量包机制
HTML5 容器离线包提供了更新机制,以单个离线包作为更新维度。因为单个离线包业务很简单,所以
离线包的⼤⼩是可控的,通常⼩于 500KB。我们通过⼤量的实践,总结出来“500KB”这个值,既可以满⾜单个业务的内容,也可以更⾼效地发布到设备上。500KB,在 4G 的时代,⼏乎可以做到⽤户⽆感知更新,即便是 2G/3G 也可以保证⼀个⾼的到达率。
上⾯说的是⼀个 HTML5 应⽤的⼤⼩。实际上,我们更新的包会更⼩,发布平台会通过 diff 算法,计算出相同 HTML5应⽤两个不同的版本的差量包,差量包通常也就在⼏ KB ⾄⼏⼗ KB 不等,可以做到更⾼的下载成功率,下载成功率⼀
应⽤两个不同的版本的差量包,差量包通常也就在⼏ KB ⾄⼏⼗ KB 不等,可以做到更⾼的下载成功率,下载成功率⼀定程度就意味着实际到达率。
2.2.2 Fallback 机制
在⼀些极端⽹络场景下,新的业务资源包更新失败,⽽我们⼜期望⽤户使⽤的是最新的业务,这个时候 Fallback 访问机制就会发挥作⽤。每个离线包资源都会在发布服平台上存放⼀份,在刚刚说到的极端场景下,⽤户会访问服务器的Fallback 地址获取资源,从⽽保障页⾯可⽤。
2.2.3 多维发布
另外,针对刚开发好的应⽤,我们可以通过发布平台的灰度发布进⾏发放,通过外部灰度的形式,对
业务指标进⾏验证,达到标准后,⽅可正式发布,做到可灰度,可回滚。
更优越的 Hybrid ⽅案:⼩程序差异化解析
作为超级 App,⼀个最主要的特征就是开放。开放就是共享 App 的流量,让外部伙伴的业务可以通过⽀付宝触达⽤户,这就⾯临⼀个质量管控的问题。⽀付宝需要保证这些业务是合法合规的,保障⽤户的财产安全。
3.1 离线包 VS ⼩程序
如果开发⼀⽅业务,离线包肯定是⾮常好的选择。不过,要是开放给第三⽅合作伙伴构建⽣态的话,纯 HTML5 页⾯就有⼀些劣势。
上图是 HTML5 离线包和⼩程序的细节对⽐。总结来说,对于开放给第三⽅的⽣态,从应⽤体验来讲,⼩程序更加统⼀,质量有保障;从应⽤安全⾓度来讲,⼩程序是访问我⽅发布服务器,不会直接访问第三⽅链接,安全可控;从研发门槛上来说,⼩程序是更简单的前端开发⽅式,同时也提供了⾮常丰富的组件。
3.2 ⼩程序解析
⼩程序其实和离线包本质是类似的,都是⼀种 Hybrid 应⽤,但⼩程序是基于⼀个定制的 DSL 语⾔,不是前端的标准,但是类似。在 DSL 规则下业务进⾏⼩程序的开发,不⽀持直接操作 DOM,这种 DSL 规则下的⾃由可以有效的进⾏质量管控。
⼩程序作为⼀个应⽤,他拥有完整的⽣命周期。从开发到关闭,开发者都可以感受到,这点也是 HTML5 所不具备的。另外,每个⼩程序之间从运⾏时和持久化上,都是完全隔离的,⽽且⼩程序运⾏在特定进程中,所以和⽀付宝也是隔离开的。
在渲染性能上,⼩程序采⽤双线程模式将页⾯渲染和业务逻辑分别放在两个单独的线程中,renderer 运⾏在 WebView 中,负责渲染界⾯;⼩程序业务逻辑运⾏在单独的 worker 线程,负责事件处理、API 调⽤和⽣命周期管理。两个线程之间通过 postMessage 以及 onMessage 进⾏数据交换,数据可以从 worker 线程传递到 render 重新渲染界⾯,同时renderer 也可以将事件传递给对应的 worker 处理。⼀个 worker 可以对应多个 renderer,⽅便页⾯间数据共享和交互。
在资源加载⽅⾯,⼩程序采⽤离线化⽅式加载,也就是说当打开⼩程序时,⼩程序离线包必须下载到本地,由于每个版本只下载⼀次,⼀⽅⾯节省了每次请求的资源开销,另⼀⽅⾯启动速度⼤⼤提升了。当有新的版本时,发布平台⾃动⽐对本地安装的版本和最新版本产⽣并下发差量包,客户端不需要下载整个包即可更新⼩程序⾄最新版。
3.3 构建⽣态
通过引⼊相同的⼩程序架构,使得⼩程序,可以作为⽣态进⾏多端互投。在⽀付宝中投放的⼩程序,可以只经过⼀些开放接⼝的适配,即可跑在基于相同⼩程序架构的 App 中。未来,开发者或第三⽅服务更多是⾯向⼩程序来开发,⽽App 则是提供⼀个统⼀的架构,真正做到开放⽣态,⽤完即⾛的理念。
关于⽀付宝⾃研 HTML5 容器⽅案
关于⽀付宝⾃研 HTML5 容器⽅案
mPaaS 离线包源⾃于⽀付宝原⽣⽅案,经历了严苛的业务考验,让你直接和⽀付宝使⽤同⼀套框架层代码,拥有统⼀容器及内核,相对系统内核获取更低 Crash 率和 ANR 率,适配性强,并具备良好的、弹性的扩展能⼒,结合具体业务需求定制 JSAPI。
它可以帮助减少 App ⽩屏、解决 Hybrid App 跨平台兼容与适配,提升 App 性能并⼤幅优化原⽣开发下的包⼤⼩。
⽬前 mPaaS 离线包 Demo 源码已更新在 GitHub 上,欢迎 Star:
欢迎申请试⽤,提更多的优化建议和使⽤反馈:
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论