1. 前言
本文将结合阔悬在 iWeb 杭州站沙龙现场的分享《支付宝小程序在 mPaaS 中的深度集成实践》，介绍支付宝小程序框架的设计原理，以及如何在 mPaaS 体系中的深度集成支付宝小程序。
分享内容将从以下两个方面展开：
- 支付宝小程序框架的系统介绍（支付宝小程序框架概述、应用层框架、Native SDK）
- mPaaS 技术架构与助力（mPaaS 小程序、mPaaS 小程序 IDE、mPaaS MDS）
2. 小程序简介：移动互联网新热点
近来，小程序俨然成为了移动互联网的新热点。继 2017 年初微信正式推出微信小程序后，各个大厂陆续发布了各自的小程序 —— 支付宝小程序、百度小程序、头条小程序，小程序成为了各家移动互联网生态布局的重要一环。
通过小程序生态可以引入大量的外部服务，不仅丰富了平台的能力，而且可以为平台带来大量的用户流量，从而使得平台具备无限的潜能。
3. 支付宝小程序简介
支付宝小程序是一种全新的开发模式，它运行在支付宝客户端，可以被便捷地获取和传播，为终端用户提供更优的用户体验。为方便小程序的开发者，支付宝小程序具有类似微信小程序的 DSL 和开发环境，降低小程序开发者的学习成本。
4. 支付宝小程序框架浅析
1. 基础需求
小程序的本质需求是让第三方开发者可以接入，使得第三方开发的小程序可以在平台级应用中运行。
对于这个需求，最简单的实现方案是：让外部开发者开发纯 H5 应用，在应用的
H5 容器里打开，容器提供一些原生的接口供H5使用。比如在支付宝和微信上的“滴滴出行”以 H5 的形式运行在各自的平台中，这种模式看似还不错，但是实际上这种简单的方案不能满足这两个小程序的基础需求：
- 体验：作为一个“小程序”需要让体验接近原生，而上述像滴滴出行这些普通 H5 的体验不太行，包括启动速度、页面切换流畅度都有问题，跟原生体验没法比。
- 管控：作为一个平台必须对接入的应用有管控能力，必须能尽量精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，H5 的方式太过*，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。另外 H5 开发质量参差不齐，平台也无法管控。
2. 框架概述
为了实现小程序并满足上述的小程序的两个需求，小程序框架应运而生。我们先看下小程序框架大图，自上而下看。
- 小程序代码：这是小程序开发者使用小程序 DSL 及各种组件开发的小程序。
- 小程序组件及 API：这是小程序的组件及 API 层，提供了小程序所需的各种组件和小程序 API。小程序开发者只需要在基于这一层提供的组件及 API 进行小程序的开发。
- 小程序应用层框架：这是小程序运行的框架层，它基于 React 实现了小程序的运行框架。该层主要包含小程序的逻辑处理引擎及渲染层。
- Native SDK：该层提供了小程序所需的 Native 能力，通过J avaScriptCore 为小程序的 JS 层框架提供大量的 Native API，此外该层还提供了小程序包管理、后台保活等基础能力。
- React 和 React Native：这一层是小程序底层运行环境，分别对应于 Web 和 Native 环境，使得小程序可运行在 WebView 和 iOS/Android 上。
- 系统层：即 Web 内核、iOS 和 Android，是系统级的平台层。
目前支付宝的小程序使用的是 React 版，蚂蚁内部的其他 App 有在使用 React Native 版的小程序。
3. 应用层框架
我们一起看下小程序应用层框架。每个小程序的代码分为两部分——逻辑处理和视图渲染，分别运行在 worker （js 引擎） 以及 render （渲染层）中。
- worker 运行小程序的逻辑处理代码，包括事件处理，api 调用以及框架的生命周期管理。 worker 只有一个，方便 App 数据在页面间的共享和交互。
- render 运行小程序的渲染代码，主要包括模版、样式和框架的跨终端的 js 组件或 native 组件，获取逻辑层的数据操作渲染引擎（React/ReactNative）进行渲染，render 在小程序中可以有多个。
- worker 和所有的 render 都建立连接，将需要渲染的数据传递给对应的 render 进行渲染，worker 也会将 api 调用转给 Native SDK 处理。
- render 则将组件的触发事件送到对应的 worker 处理，同时接受 worker 的调用进行重新渲染。 render 可以看作一个无状态的渲染终端，小程序的状态都保留在 worker 内。
可见该框架可以做到，JS 逻辑代码与页面渲染分离并行执行，不会出现 JS 代码执行时卡住页面渲染的情况，进而提升渲染性能。多个页面可以共享一个 JS 运行环境，数据可以很方便地共享，整个小程序生命周期里共享同一个上下文，更接近 App 的开发体验。小程序的模板样式是自定义的格式，这样可以做到开发时使用固定的 DSL，不依赖底层的渲染引擎，这样引擎的优化升级不会造成上层的小程序代码的不兼容，并且渲染行为是完全是可控的。
4. Native SDK
我们再看 Native 层，在支付宝中是由 Nebula H5 容器负责实现，它为小程序提供 Native 能力，为小程序提供的包管理、后台保活等功能。
- Native API：小程序调用的 API 中有部分功能需要在 native 中实现，这部分 API 通过桥接调用进入对应的 Native API。
- 包管理：负责小程序包的下载、存储、加载。小程序包的下载具有多种策略，可以满足小程序的预下载、强制更新等需求。
- 后台保活：小程序在后台可以存活 5 分钟，使得用户在下次打开时可以获得更好的体验。
5. 小结
现在让我们回到前面提到的两个小程序的基本需求，体验和管控。我们看下框架是如何实现这两个需求的。对于体验需求，主要有以下几点：
- 框架对小程序做了逻辑处理和视图渲染的分离以提升渲染性能
- 对于较重的组件（地图）使用 Native 实现以提升性能
- 小程序公共资源预置在小程序框架以提升加载性能
- 后台保活机制提高二次启动速度
对于管控需求，主要有两点：
- 小程序开发只能使用框架提供的自定义的模板样式
- JS 代码运行在与 Webview 隔离的 JS 引擎中，无法操作浏览器 DOM
5. mPaaS 技术架构与助力
1. 支付宝小程序与 mPaaS
小程序这么有优势，那能否把支付宝小程序放到其他 APP 中运行呢？答案是肯定的，借助 mPaaS，小程序技术不仅在蚂蚁金服内部使用，也能够提供给外部用户使用。
首先简单介绍下什么是 mPaaS，mPaaS 全称是 Mobile Platform as a Service，即移动端的 PaaS 。作为蚂蚁金服独创的移动研发平台，它源于支付宝近 10 年的移动技术的沉淀，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助生态伙伴快速搭建稳定高质量的移动 App。
2. mPaaS 小程序
再来看下什么是 mPaaS 小程序，它是在支付宝小程序的基础上做了瘦身、去依赖的小程序 SDK，为了能便捷的输出给其他 App 快速地搭建出小程序平台。它保持和支付宝小程序一样的模板样式和通用 API，仅仅少量的像授权这样的开放的 API 需要客户自定义开发。借助 mPaaS 小程序，可以做到一套小程序代码，在支付宝和自己的 App 上双端投放和运行，甚至可以构建出自己的小程序生态体系。
这里和大家分享下 mPaaS 小程序在其他 App 中集成时可能需要解决的问题：
- SDK 集成冲突，这个是多个 SDK 集成可能会遇到的共性问题，一般通过去除不要的 SDK 或者对 SDK 中部分符号名做针对性的修改。
- 开放 API 定制开发，开放 API 依赖后端的服务，比如用户授权这个 API，它需要获取用户的账号信息，那么就需要重写这个 API 的具体实现，去访问 App 的用户中心服务以实现授权功能。小程序框架提供了一套自定义和重写 API 的插件机制，能快速的去重写某个 API，甚至添加一个新的 API。
3. mPaaS 小程序 IDE
小程序的开发除了可使用支付宝小程序开放平台提供的 IDE，还可以使用 mPaaS 版的小程序 IDE。通过 mPaaS 版的 IDE 可以导出本地的小程序包，后续在 mPaaS 发布平台中使用这个本地包直接发布。未来，小程序 IDE 将会与 mPaaS 直接打通，在 IDE 中可以直接完成 mPaaS 小程序的开发、测试和发布这一系列的开发运维体验。
4. mPaaS MDS
小程序技术的一个基础的能力，就是小程序发布系统。mPaaS 小程序的发布服务是由 mPaaS 的移动发布系统（MDS）提供的。MDS 提供多种发布策略，能够在正式发布之前进行多种类型的灰度测试。MDS 提供增量差分包更新能力，可减少更新包的体积，在移动端网络不稳定场景中发挥优势。
目前，mPaaS 小程序已在众多政务项目中落地服务，帮助政务小程序在支付宝和自有 App 双端投放运行。相同的业务功能使用小程序实现，在支付宝和自有 App 中可进行共用，能显著地降低开发成本，做到业务的快速上线及动态更新。
如果想要进一步了解 mPaaS 小程序，可以复制地址到浏览器中打开：
http://t.cn/ELBlvEr
关于小程序框架的优化思路或具体实践，如果你有任何疑问或建议，欢迎随时和我们一同交流。
往期阅读