mPaaS小程序技术架构深度解析

⚅ 点击观看《mPaaS 小程序新品发布会》回放 > >

随着小程序技术的愈发成熟，不一样平台的优点和典型使用场景各有侧重，同时愈来愈多的开发者能够结合自身的业务特点，经过小程序做为业务载体，造成单一平台或多平台的协同关系。
而今天，小程序技术的开放，mPaaS 小程序框架做为一款 App 通用框架，帮助开发者面向自身的 App 实现小程序投放。不止如此，小程序代码仅需撰写一次，即可多端投放至自有 App、支付宝、钉钉甚至其余小程序开放平台。

本文将围绕支付宝在移动端架构的演进逐步展开，分享咱们在“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”加群。

原文连接

本文为云栖社区原创内容，未经容许不得转载。