深度解析 mPaaS 小程序一站式研发

支付宝技术团队

于 2019-09-24 11:05:44 发布

阅读量3.3k

点赞数

分类专栏：蚂蚁技术文章标签：蚂蚁金服阿里巴巴

本文链接：https://blog.csdn.net/weixin_44326589/article/details/101271592

版权

蚂蚁技术专栏收录该内容

111 篇文章 37 订阅

订阅专栏

写在前面

自从微信小程序推出以来，越来越多的业务场景可以通过小程序构建体验闭环，同时各大厂商也纷纷推出了自己的小程序平台。究其背后的原因，笔者认为由于近年来移动互联网的头部流量聚集效应愈发明显，如何做好存量市场的活跃度成为各大 App 的核心课题。根据《中国移动互联网全景生态流量洞察报告》显示，头部 O2O 的应用最大流量来源显示已经是小程序。对于小程序，一方面它需要降低接入门槛，并提供足够安全的方式确保第三方业务能够良好运行，另一方面需要结合自身平台的优势能力，让第三方业务场景找到更多的结合点与可玩性。

本文基于夜禹在蚂蚁金服 CodeDay#3 上海站的分享议题《小程序一站式研发深度解析》整理成稿，着重向读者介绍 mPaaS 小程序技术体系以及背后技术细节。与其他小程序研发平台不同的是，mPaaS 小程序技术体系能够让开发者拥有自己的小程序开放平台。基于 mPaaS 小程序，开发者不仅可以在自己的应用中快速开发上线小程序，甚至可以邀请其他开发者为自己开发小程序。由于mPaaS与支付宝共用一套技术体系，因此支付宝的小程序可以顺利投放到开发者自己的应用内。

小程序技术选型

构建生态方面，为何小程序选型更优？

在小程序出现之前，我们通常会直接使用第三方提供的 HTML5 页面来实现业务合作。直接用 HTML5 来构建开放平台看起来是比较简单易行的方案，但当 App 面对海量的第三方接入方时，就显得捉襟见肘了。直接使用 HTML5 主要面临以下几个问题：

应用体验：直接使用第三方 HTML5 页面，意味着 HTML5 页面的性能体验直接取决于第三方，比如硬件规格大小、CDN 部署、前端框架选型等等。第三方研发水平的参差不齐直接影响原生 App 的用户体验，甚至稳定性，反而会让用户流失，适得其反。
应用安全：由于 HTML5 页面部署在第三方服务器上，平台方很难及时审核控制页面内容的改动，监管的风险不可控制。第三方服务的安全问题同样危及到 App 自身的安全。
研发门槛：HTML5 页面的开发尽管比原生开发简单，但依然具有一定的门槛，比如对前端框架的熟练程度，工具链的配置，服务器购置等等。只有更进一步降低研发门槛，才能争取到更多非 Web 技术栈开发者群体。

小程序定义

在我们全面介绍小程序之前，首先要给小程序下个定义，这直接决定了我们要做什么事情。用一句话来概括，小程序是个“应用”。小程序作为“应用”具备以下几个特点：

生命周期：和原生应用开发类似，小程序页面拥有完整的生命周期，从应用打开到应用关闭，开发者都能够感应到生命周期的变化，这一点是 HTML5 页面所不具备的。
应用隔离：考虑到安全，各个小程序在运行时和持久存储上都是隔离的。首先，小程序运行在独立子进程中，即使发生崩溃，也不会影响宿主应用所在的主进程；其次，宿主应用为每个小程序分配独立的持久存储控件，每个小程序只能访问被分配的存储目录。
应用框架：应用框架分为视图、逻辑、样式三个部分。在视图方面，与H5明显不同的是，标记语言的使用更加简化，根据以往在应用开发中积累的最佳实践，定义一部分常用视图组件，开发者很容易选择自己需要的组件。沿用虚拟 DOM 的概念，开发者无法直接操作视图更新，只能通过更新视图绑定的数据源来刷新页面，避免直接操作类似 DOM 的数据结构而产生性能问题。样式方面，直接沿用 CSS 属性，但引入新的尺寸单位 rpx 用于快速适配移动端屏幕。

应用开发必然不能缺少完善工具链的支持，小程序 IDE 集合了编码、调试、预览以及发布等能力。客户端经过简单的适配，即可在真机应用中实时预览和调试小程序。

渲染方案

我们依然使用 WebView 作为小程序的渲染引擎，但保留了未来切换引擎的可能性。开发者编写的小程序需要经过一系列的打包流程转换为 Web 引擎可执行的资源。打包后的产物不仅包含页面、代码和资源，同时也包含 API 访问权限、小程序文件签名等安全信息用于客户端进行安全校验。

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

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

资源加载方面，小程序采用离线化方式加载，也就是说当打开小程序时，小程序离线包必须下载到本地，由于每个版本只下载一次，一方面节省了每次请求的资源开销，另一方面启动速度大大提升了。当有新的版本时，发布平台自动比对本地安装的版本和最新版本产生并下发差量包，客户端不需要下载整个包即可更新小程序至最新版。

小程序平台体系

除了优秀的应用框架和用户端体验之外，小程序能力扩展、应用分发、监控及数据分析等方面进行也是必不可少的。

能力扩展

mPaaS 本身已集成近上百个常用的 API，包括网络、媒体、存储、定位、扫码、蓝牙等等，这些 API 同样可以完美的运行在支付宝中。不仅如此，应用开发者可以将自己特色的功能通过小程序容器的插件机制透出给小程序开发者。

应用分发

mPaaS MDS 发布服务不仅可以下发 HTML5 离线包、开关配置和热修复包，同样也能够分发小程序包。MDS 的灰度能力在小程序上同样适用，小程序全量上线之前，我们可以以白名单、时间窗、地域、应用版本等维度进行灰度发布，在灰度期间验证小程序的可用性、稳定性。

监控与分析

小程序上线后，我们是一定会希望了解小程序的运行数据，不仅是性能稳定性，也包括业务方面的数据。小程序容器内置一套通用性指标，如小程序页面打开/关闭、JavaScript 执行异常、页面白屏、启动耗时、闪退等数据在指定点位自动抓取并择机上报至 MAS 分析服务，MAS 提供实时大盘以多种维度展现这些数据。业务方面的数据指标，小程序提供数据上报接口供开发者调用，上报的数据经过 MAS 提供的自定义分析引擎展现自己所希望可到的报表形式。

快速接入小程序

mPaaS 最近发布了新的基线版本，该版本增加了相当多的小程序特性，除了支持更多的 API 之外，真机预览与调试功能也已经上线，可以在公有云上使用。对于 Android 平台，相较于传统复杂的接入方式，我们提供更加轻便的接入方式，叫做 mPaaS Inside，意思是把 mPaaS 当做 SDK 嵌入到自己的 App 里，开发者不需要再和以前一样只能大幅改造自己的 App 才能接入 mPaaS。

具体步骤可参考：