本文将围绕支付宝在挪动端架构的演进逐渐开展，分享咱们在“App 动态性”“晋升研发效率”等方面所做的思考和具体实际。同时，针对 mPaaS 小程序能力的凋谢，也将开展介绍咱们如何实现“小程序代码只写一次，多端投放”，而这将给开发者带来齐全不同的开发体验。

支付宝 App 倒退历程

首先让咱们先回顾看看支付宝 App 在近几年的具体倒退历程。

支付宝一开始仅仅只是一个单体利用的工具型 App，让用户能够在手机实现支付宝相干的业务查问和操作。2013 年后，支付宝逐渐转型为平台型 App，平台型 App 具备“服务化、模块化、工具组件化”的特点。这个时候支付宝的业务不仅仅是领取，还须要给客户提供很多生存相干的服务，例如余额宝、缴电费等。2015 年后支付宝成长为超级 App，此时支付宝外面须要反对大量简单的业务。2018 年，随着小程序的推出，支付宝开始凋谢本人的商业能力，用本人流量助力合作伙伴，因而整个 App 面临凋谢、动态化、高可用的挑战，面对这些挑战，咱们把它总结为以下三个方面：

1. 动态性及体验
• 面对多样的需要，如何保障业务的疾速迭代？
• 保障 App 动静更新的前提下，如何保障用户体验？

2. 研发效率
• 如何做到代码一次编写，多端复用？
• 没有客户端开发教训，如何晋升开发效率？

3. 凋谢生态
• 如何将能力凋谢给更多开发者？
• 如何连贯更多生态平台，丰盛本身 App 场景？

有了问题，咱们会通过技术手段，来解决这些问题，咱们从下面的三个方向登程，来进行技术选型。

首先咱们从业务 开发成本 角度来看：
• 原生作为最根底的开发模式，须要双端都进行开发，无疑老本是最高的；
• 其次是 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 具备的“在线 + 离线”的动态性，该计划依然存在肯定差距；
• 接下来是 Flutter，尽管有很弱小的热重载机制，不过因为 Google 的限度，正式版本 iOS 无奈做到热更新，目前的话，能够通过批改引擎，批改 JIT 和 AOT 形式来做到 iOS 热更，或是采取运行时解析渲染来做到动态化，但相比于下面两个计划，在动态性上，flutter 略差一些。
• 最初原生，Android/iOS 双端均能够通过一些黑科技伎俩，进行动静更新，不过因为 iOS 政策禁止，因而在动态性上，原生计划临时不举荐；

剖析完四种计划的不同的几个方向，那么 mPaaS 带来的答案是：
「兼顾动态性、体验、开发效率、开放性的 Hybrid 架构计划，即 mPaaS 小程序」。

mPaaS 小程序技术解析

什么是小程序呢？
依据 w3c 小程序白皮书对小程序的定义，小程序，是一种依赖 Web 技术，集成了原生能力的，新的挪动应用程序格局。它具备获取「便捷、连贯稳固、安全可靠、性能优异」这四个特点。

mPaaS 小程序，基于 Web 技术，学习成本低。
一套小程序代码，同时反对 iOS 和 Android，靠近原生体验。
同时提供丰盛的组件和 API，如获取用户信息、本地存储、领取性能等。

接下来咱们来拆解小程序残缺的技术架构，试着通过「运行阶段、开发阶段、公布阶段」将小程序整体的架构开展。

• 运行阶段
小程序采纳双线程模式将页面渲染和业务逻辑别离放在两个独自的线程中，renderer 运行在 WebView 中，负责渲染界面；小程序业务逻辑运行在独自的 worker 线程，负责事件处理、API 调用和生命周期治理。两个线程之间通过 postMessage 以及 onMessage 进行数据交换，数据能够从 worker 线程传递到 render 从新渲染界面，同时 renderer 也能够将事件传递给对应的 worker 解决。一个 worker 能够对应多个 renderer，不便页面间数据共享和交互。

对于渲染速度、交互响应要求高的场景，如地图，小程序将原生地图组件嵌入到 WebView 上，相比在 Canvas 上渲染地图，绘制速度和效率更高。

资源加载方面，小程序采纳离线化形式加载，也就是说当关上小程序时，小程序离线包必须下载到本地，因为每个版本只下载一次，一方面节俭了每次申请的资源开销，另一方面启动速度大大晋升了。当有新的版本时，公布平台主动比对本地装置的版本和最新版本产生并下发差量包，客户端不须要下载整个包即可更新小程序至最新版。

• 开发与公布阶段
利用开发必然不能短少欠缺工具链的反对，小程序 IDE 汇合了编码、调试、预览以及公布等能力。客户端通过简略的适配，即可在真机利用中实时预览和调试小程序。

对小程序架构有了初步的理解之后，咱们接下来看看 mPaaS 小程序将如何实现动静公布。这恰好是 mPaaS 小程序外围的亮点，借助「包公布和治理」的能力，App 的研发与迭代效率得以深度优化。

如上图所示，咱们从新定义了研发模式与公布流程，每个小程序都能够作为独立产品，有本人的公布流程，无需期待其余团队。各业务团队进行齐全拆分，每个业务独立演进，独立公布。

在公布过程中，要恪守以下流程：
1. 指标线性，定义每次公布的业务和性能指标；
2. 智能灰度，外部灰度、内部灰度、指定灰度；
3. 实时监控，修复循环；
4. 线上运培修复伎俩技术兜底。

而后咱们再聊下小程序的平安。
• 连贯平安
基于阿里巴巴无线保镖能力，保障小程序申请平安，篡改后的申请无奈通过校验。
• 包体平安
包体通过加密、加签，保障下载过程平安，篡改后的小程序包无奈失常应用。
• 权限平安
残缺的权限管理体系，针对不同小程序凋谢不同权限，保障用户的隐衷平安。

接着咱们看下小程序框架能力扩大体系。

mPaaS 小程序自身已集成近上百个罕用的 API，包含网络、媒体、存储、定位、扫码、蓝牙等等，这些 API 同样能够完满的运行在支付宝中。不仅如此，利用开发者能够将本人特色的性能 mPaaS 小程序扩大能力透出给小程序开发者。这块扩大次要包含三个方面：
• 能力扩大：提供自定义事件能力，反对“小程序 -> 原生”，以及“原生 -> 小程序”
• 款式扩大：提供多种原生款式定制，包含导航栏，加载动画，启动动画等原生款式
• 组件扩大：提供自定义组件能力，扩大小程序标签

最初咱们再聊聊小程序的多端投放与生态。

基于 mPaaS 小程序体系，咱们能够将十分多的小程序规范，通过工具转化成规范小程序产物，例如开发者本人写的 mPaaS 小程序，抑或是 mPaaS 小程序市场的小程序，或者支付宝 or 其余三方小程序。通过 IDE 转化实现后，咱们能够通过两种渠道，投放到不同的端上。应用 mPaaS 公布平台，即可投放到自有 App 中，应用其余三方开放平台，即可投放到对应的端上，一次开发，仅需大量适配，即可多端投放。

当然，对于本身 App 内业务场景绝对匮乏的状况，基于 mPaaS 对立的小程序框架能力，阿里系的三方业务场景，可能实现无缝投放，从而满足开发者丰盛本身业务场景的需要。

基于 mPaaS 小程序的挪动端能力构建

下面介绍完了 mPaaS 小程序的技术架构以及能力，接下来咱们聊下基于 mPaaS 小程序在具体研发向的思考。
• 挪动中台能力建设

所谓挪动中台能力建设，咱们心愿通过整合整个 App 架构：在根底层面，将通用的组件下沉，防止反复发明轮子，同时标准化服务接口，为更多的下层业务提供优质、稳固且规范的服务。
那么咱们就须要从两个方面来解决这个事件。

• 根底组件
  咱们在开发过程中可能会存在这样一个问题，就是两个团队合作开发，可能大家有本人积淀的一些经典组件，咱们能够对这些组件进行积淀，同时，还能够通过小程序的自定义组件能力，对小程序提供服务。
• 外围能力服务化
  组件积淀后，对于一些外围的业务能力，咱们须要将这部分能力进行服务化，形象出规范的服务接口 or 小程序 API，供其余团队或是第三方生态调用。比如说支付宝的领取服务、芝麻信用服务等，都是依靠于服务化，最终良好的为其余业务提供服务的。

挪动前台建设

在咱们实现挪动中台能力建设之后，整体的能力就曾经具备了，剩下的就是联合小程序框架，建设咱们的挪动前台能力。

• 外围业务体验优化
  针对一些十分外围的业务逻辑，比方领取报的领取，以及一些对性能要求比拟高的业务，比方首页，亦或是一些非凡交互的页面。通常咱们是心愿通过应用原生页面或是 flutter 等原生技术来实现页面。因为这些页面，通常不会有大改，所以对动态化能力要求不是很严格，同时原生又能满足这些页面多种多样用户体验的需要。
• 简单业务小程序化
  对一些简单的二级业务，可能业务自身会频繁的进行迭代，那么对于原生 native 将会是劫难般的开发体验，这时候，咱们需将这部分业务剥离进去，通过前端技术将业务革新成小程序，再通过公布服务将离线包公布到利用上。这样，就满足了咱们业务复杂多变的场景。
• 三方生态化
  咱们不仅本身提供各种各样的服务，也须要引入第三方服务来服务更多的人群，传统的 H5 页面因为过于宽泛的前端规范，加上有肯定的技术门槛，这里就不如标准、简略的小程序了。同时，在利用下面咱们介绍的挪动中台建设，对第三方小程序提供多种多样的自有中台能力，实现场景多样化。

围绕着小程序如何帮忙咱们革新本身的业务模块，并且逐渐逐步形成动态化更新，置信大家有了更全面的意识。目前 mPaaS 小程序已凋谢收费试用，欢送接入体验。在接入测试阶段，有任何答疑需要，也欢送应用钉钉搜寻“32843812”加群。

我和我的共事期待你的到来。

原文链接：https://developer.aliyun.com/article/767886?utm_content=g_1000163105
本文为阿里云原创内容，未经容许不得转载。