让小程序在自有App中启动的技术来了：mPaaS 小程序架构深度解析

2020/7/17 9:09:27

编程Tag： mPaaS 小程序·云开发

本文主要是介绍让小程序在自有App中启动的技术来了：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 的研发与迭代效率得以深度优化。

如上图所示，我们重新定义了研发模式与发布流程，每个小程序都可以作为独立产品，有自己的发布流程，无需等待其他团队。各业务团队进行完全拆分，每个业务独立演进，独立发布。

在发布过程中，要遵守以下流程：

指标线性，定义每次发布的业务和性能指标；
智能灰度，内部灰度、外部灰度、指定灰度；
实时监控，修复循环；
线上运维修复手段技术兜底。

然后我们再聊下小程序的安全。

连接安全

基于阿里巴巴无线保镖能力，保障小程序请求安全，篡改后的请求无法通过校验。

包体安全

包体经过加密、加签，保障下载过程安全，篡改后的小程序包无法正常使用。

权限安全

完整的权限管理体系，针对不同小程序开放不同权限，保障用户的隐私安全。

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

mPaaS 小程序本身已集成近上百个常用的 API，包括网络、媒体、存储、定位、扫码、蓝牙等等，这些 API 同样可以完美的运行在支付宝中。

不仅如此，应用开发者可以将自己特色的功能 mPaaS 小程序扩展能力透出给小程序开发者。这块扩展主要包括三个方面：

能力扩展：提供自定义事件能力，支持“小程序 -> 原生”，以及“原生 -> 小程序”
样式扩展：提供多种原生样式定制，包括导航栏，加载动画，启动动画等原生样式
组件扩展：提供自定义组件能力，扩展小程序标签

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

基于 mPaaS 小程序体系，我们可以将非常多的小程序标准，通过工具转化成标准小程序产物，例如开发者自己写的 mPaaS 小程序，抑或是 mPaaS 小程序市场的小程序，或者支付宝 or 其他三方小程序。通过 IDE 转化完成后，我们可以通过两种渠道，投放到不同的端上。使用 mPaaS 发布平台，即可投放到自有 App 中，使用其他三方开放平台，即可投放到对应的端上，一次开发，仅需少量适配，即可多端投放。

当然，对于自身 App 内业务场景相对匮乏的情况，基于 mPaaS 统一的小程序框架能力，阿里系的三方业务场景，能够实现无缝投放，从而满足开发者丰富自身业务场景的需求。

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

上面介绍完了 mPaaS 小程序的技术架构以及能力，接下来我们聊下基于 mPaaS 小程序在具体研发向的思考。

移动中台能力建设

所谓移动中台能力建设，我们希望通过整合整个 App 架构：在基础层面，将通用的组件下沉，避免重复创造轮子，同时标准化服务接口，为更多的上层业务提供优质、稳定且标准的服务。

那么我们就需要从两个方面来处理这个事情。

基础组件

我们在开发过程中可能会存在这样一个问题，就是两个团队协作开发，可能大家有自己沉淀的一些经典组件，我们可以对这些组件进行沉淀，同时，还可以通过小程序的自定义组件能力，对小程序提供服务。

核心能力服务化

组件沉淀后，对于一些核心的业务能力，我们需要将这部分能力进行服务化，抽象出标准的服务接口or小程序API，供其他团队或是第三方生态调用。比如说支付宝的支付服务、芝麻信用服务等，都是依托于服务化，最终良好的为其他业务提供服务的。

移动前台建设

在我们完成移动中台能力建设之后，整体的能力就已经具备了，剩下的就是结合小程序框架，建设我们的移动前台能力。

核心业务体验优化

针对一些非常核心的业务逻辑，比如支付宝宝的支付，以及一些对性能要求比较高的业务，比如首页，亦或是一些特殊交互的页面。通常我们是希望通过使用原生页面或是 flutter 等原生技术来实现页面。因为这些页面，通常不会有大改，所以对动态化能力要求不是很严格，同时原生又能满足这些页面多种多样用户体验的需求。