条条大路通罗马：mPaaS 新增体验入口

Z时代
2024-01-10
分类：技术分享

近日，移动开发平台 mPaaS 体验入口正式上线「知晓云」官网，用户进入控制台创建应用后，即可体验尝鲜。

而本文也将从 mPaaS 小程序框架解析展开，分享其如何帮助开发者实现“小程序代码仅需开发一次，便可多端投放”的效果。

前言

本文将从以下两个方面展开分享：

支付宝小程序框架的系统介绍（支付宝小程序框架概述、应用层框架、Native SDK）

mPaaS 技术架构与助力（mPaaS 小程序、mPaaS 小程序 IDE、mPaaS MDS）

我们将从支付宝小程序框架的设计原理入手，回顾其演进路径及具体的优化策略。同时，为满足开发者实现在自有 App 内投放小程序的需求，mPaaS 小程序尝试针对小程序 SDK 完成瘦身、去依赖。借助 mPaaS 小程序，可以做到一套小程序代码，在支付宝和自己的 App 中双端投放和运行，甚至构建出自己的小程序生态体系。

小程序简介：移动互联网新热点

近来，小程序俨然成为了移动互联网的新热点。继 2017 年初微信正式推出微信小程序后，各个大厂陆续发布了各自的小程序 —— 支付宝小程序、百度小程序、头条小程序，小程序成为了各家移动互联网生态布局的重要一环。通过小程序生态可以引入大量的外部服务，不仅丰富了平台的能力，而且可以为平台带来大量的用户流量，从而使得平台具备无限的潜能。

支付宝小程序简介

支付宝小程序是一种全新的开发模式，它运行在支付宝客户端，可以被便捷地获取和传播，为终端用户提供更优的用户体验。为方便小程序的开发者，支付宝小程序具有类似微信小程序的 DSL 和开发环境，降低小程序开发者的学习成本。

支付宝小程序框架浅析

基础需求

小程序的本质需求是让第三方开发者可以接入，使得第三方开发的小程序可以在平台级应用中运行。对于这个需求，最简单的实现方案是：让外部开发者开发纯 HTML5 应用，在应用的 HTML5 容器里打开，容器提供一些原生的接口供 HTML5 使用。比如在支付宝和微信上的“滴滴出行”以 HTML5 的形式运行在各自的平台中，这种模式看似还不错，但是实际上这种简单的方案不能满足这两个小程序的基础需求：

体验，作为一个“小程序”需要让体验接近原生，而上述像滴滴出行这些普通 HTML5 的体验不太行，包括启动速度、页面切换流畅度都有问题，跟原生体验没法比。

管控，作为一个平台必须对接入的应用有管控能力，必须能尽量精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，HTML5 的方式太过自由，开发者可以随时改变整个应用的内容，平台难以检测到这些改变，无法管控。另外 HTML5 开发质量参差不齐，平台也无法管控。

框架概述

为了实现小程序并满足上述的小程序的两个需求，小程序框架应用而生。我们先看下小程序框架大图，自上而下看。

小程序代码，这是小程序开发者使用小程序 DSL 及各种组件开发的小程序。

小程序组件及 API，这是小程序的组件及 API 层，提供了小程序所需的各种组件和小程序 API。小程序开发者只需要在基于这一层提供的组件及API进行小程序的开发。

小程序应用层框架，这是小程序运行的框架层，它基于 React 实现了小程序的运行框架。该层主要包含小程序的逻辑处理引擎及渲染层。

Native SDK，该层提供了小程序所需的 Native 能力，通过 JavaScriptCore 为小程序的 JS 层框架提供大量的Native API，此外该层还提供了小程序包管理、后台保活等能力等基础能力。

React 和 React Native，这一层是小程序底层运行环境，分别对应于 Web 和 Native 环境，使得小程序可运行在 WebView 和 iOS/Android 上。

系统层，即 Web 内核、iOS 和 Android，是系统级的平台层。

目前支付宝的小程序使用的是 React 版，蚂蚁内部的其他 APP 有在使用 React Native 版的小程序。

应用层框架

我们一起看下小程序应用层框架。每个小程序的代码分为两部分——逻辑处理和视图渲染，分别运行在 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，不依赖底层的渲染引擎，这样引擎的优化升级不会造成上层的小程序代码的不兼容，并且渲染行为是完全是可控的。

Native SDK

我们再看Native层，在支付宝中是由 Nebula H5 容器负责实现，它为小程序提供Native 能力，为小程序提供的包管理、后台保活等功能。

Native api，小程序调用的api中有部分功能需要在native中实现，这部分api通过桥接调用进入对应的native api。

包管理，负责小程序包的下载、存储、加载。小程序包的下载具有多种策略，可以满足小程序的预下载、强制更新等需求。

后台保活，小程序在后台可以存活5分钟，使得用户在下次打开时可以获得更好的体验。

小结

现在让我们回到前面提到的两个小程序的基本需求，体验和管控。我们看下框架是如何实现这两个需求的。对于体验需求，主要有以下几点：

框架对小程序做了逻辑处理和视图渲染的分离以提升渲染性能

对于较重的组件（地图）使用 Native 实现以提升性能

小程序公共资源预置在小程序框架以提升加载性能

后台保活机制提高二次启动速度

对于管控需求，主要有两点：

小程序开发只能使用框架提供的自定义的模板样式

JS 代码运行在与 Webview 隔离的 JS 引擎中，无法操作浏览器 DOM

mPaaS 技术架构与助力

支付宝小程序与 mPaaS

小程序这么有优势，那能否把支付宝小程序放到其他 APP 中运行呢？答案是肯定的，借助 mPaaS，小程序技术不仅在蚂蚁金服内部使用，也能够提供给外部用户使用。

首先简单介绍下什么是 mPaaS，mPaaS 全称是 Mobile Platform as a Service，即移动端的 PaaS 。是蚂蚁金服独创的移动研发平台，它源于支付宝近 10 年的移动技术的沉淀，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助生态伙伴快速搭建稳定高质量的移动 APP。

mPaaS 小程序

再来看下什么是 mPaaS 小程序，它是在支付宝小程序的基础上做了瘦身、去依赖的小程序 SDK，为了能便捷的输出给其他 APP 快速地搭建出小程序平台。它保持和支付宝小程序一样的模板样式和通用 API，仅仅少量的像授权这样的开放的 API 需要客户自定义开发。借助 mPaaS 小程序，可以做到一套小程序代码，在支付宝和自己的 APP 上双端投放和运行，甚至可以构建出自己的小程序生态体系。

mPaaS 小程序 IDE

小程序的开发除了可使用支付宝小程序开放平台提供的 IDE，还可以使用 mPaaS 版的小程序 IDE。通过 mPaaS 版的 IDE 可以导出本地的小程序包，后续在 mPaaS 发布平台中使用这个本地包直接发布。未来，小程序 IDE 将会与 mPaaS 直接打通，在 IDE 中可以直接完成 mPaaS 小程序的开发、测试和发布这一系列的开发运维体验。