开发者学堂课程【mPaaS 小程序开发实战 - 教你如何独立运行小程序 ：mPaaS 小程序介绍+接入 mPaaS 小程序并实现启动 Android 版（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/741/detail/13122
mPaaS 小程序介绍+接入 mPaaS 小程序并实现启动 Android 版（一）
内容介绍
一、移动开发背景
二、mPaaS 小程序技术解析
三、基于 mPaaS 小程序的移动端能力构建
四、代码演示：mPaaS 小程序实战演示
一、移动开发背景
支付宝这些年的一个发展历程——从13年之前支付宝就推出了，那在最早早先阶段，支付宝是作为一个工具性的，是一个单体应用，它主要承载的就是支付的作用，当时就是为了淘宝去做一个担保交易。随着13年余额宝推出支付宝，慢慢的它的工程，它的规模逐渐扩大，那这时候他就需要一个平台型，这时候做了服务化和模块化。这时候的支付宝，它的功能其实越来越多。从15年开始之后，支付宝的业务进行了一个井喷的状态，集团内及这个阿里集团或者蚂蚁集团的很多的这种生态都生长在支付宝上。
所以这时候支付宝，它面临的这个问题就是一个动态化和高可用的这么一个问题。再往后18年以后，随着小程序的推出，那支付宝在这个阶段面临的就是一个新的阶段，所面临挑战就是如何去开放，去拥抱开发者，然后去开发他的生态。这个就是一个支付宝发展历程。
在发展历程中支付宝遇到的问题
• 动态性及体验——面对这个我们的开放生态，面对多样的需求。如果保证业务端的快速迭代。同时，在保证快速迭代的前提下，如何保障用户的体验是第一个动态和体验性的。
• 研发效率——如何做到一次编码，然后多端复用。然后就是，如果开发者没有很多开发经验，帮助他提高开发效率，这个是研发效率方面。
• 开放生态——开放生态就是如何将我们的能力开放给更多的开发者，如何连接更多的生态平台，丰富自身的 app 场景，这个就是 app 发展过程中遇到的问题。
现阶段移动端技术方案分析
随着上述问题，我们进入一个技术分析环节。就是为了解决这些这个遇到的问题。我们这时候引入一些技术分析，然后通过分析这些技术，然后去帮我们解决问题，刚才的问题其实很多都是一些化端动态性的问题。
所以我们将问题分为三类——
• 开发成本
• 用户体验
• 技术的动态性
从技术角度分为四个部分——
• 传统的 Native 的技术方案
• HTML5 的技术方案
• ReactNative 和 Weex 的技术方案
• Flutter 方案
从开发成本角度来说，Native 方案开发成本是最高的。所以只有一颗星。开发成本越高，获得的星会越少，因为他要需要每次开发需要开发双端，所以 Native 开发成本是最高的；HTML5 的开发成本是最低的，因为首先它的技术是最普及的，同时，它开发一次可以在两端上同时预测，所以它的开发成本达到五颗星。
然后 ReactNative 或者是 Weex 的开发成本，虽然说他是学习一次到处编写，但实际上在双端上会有不少的适配工作，同时你需要在双端上去写一些扩展的内容，或者是对他的本身的这种源码进行一些修改。它的开发成本其实也是比较高的。
Flutter 因为最近新出，并且谷歌大力在推，然后它确实可以做到一次编写双端运行。它的开发成本其实在业务上的开发成本其实是比较低的，它主要的开发成本是在维护框架，如果说因为它现在迭代比较快，框架可能不支持的话，可能就要频繁的去更新框架版本，或者是自己自行进行修复。
从用户体验的角度来说，Native 也是最好的。它支持各种各样的原生渲染，所以他是五颗星。HTML5 它体验是最差的，那这里只有两颗星，因为它只是支持 web 的渲染。
ReactNative 它的渲染要强于 HTML5，它将 JS 去解析成原生共建并渲染。但是由于他也是进行了一层翻译，所以他的体验上也不是特别完美。所以这里是三颗星。Flutter 因为它是统一的渲染内核，所以他的用户体验比较好。呃，相比于原生来说，它仅有一些比较少的一些的体验上的差异。它是仅次于原生的一个用户体验。
从动态性来说，首先 Native 是最差的，他只能做一些热修复或者热更新，并且 ros 基本上是不支持这么做。
HTML5 的动态性是最好的，然后可以在双端被通过离线的方式或者在线的方式直接把你的业务下发下去。ReactNative 是四颗星，它就是通过下发 JS 来达到这个动态的更新。Flutter 的话，本身 Flutter 其实不支持动态，但是随着这个 FLutter 生态越来越多，Flutter 的动态化也比较多，所以这里给到三颗星。
比如说通过 git 转成 aot 的方式，或者是一些动态引擎。动态的 ui 解析渲染，然后再配合一些简单的逻辑指标。来达到动态性的这种能力。
分析完四个技术方案，这里我们就要带出 mPaaS 的一个解决方案，mPaaS 解决方案就是要发布一个 mPaaS 小程序，这个小程序会兼顾动态性，体验，开发效率以及开放性的 Hybrid 架构方案。其实是基于 web 但又不完全是一种 web 方案。
二、mPaaS 小程序技术解析
1、mPaaS 小程序技术定义
小程序的技术定义，小程序是一种依赖 Web 技术，形成了原生能力的新的移动应用程序格式，有四个非常明显的特点——
• 获取便捷——小程序可以随用随走。
• 连接稳定——在什么时间你都可以获得到这个小程序。
• 安全可靠——小程序一定会经过平台的审核然后进行一些安全的管控，才能使用到对应的业务
• 性能优异——像传统的 HTML5 这种方案，它的性能有很大的提升
2、mPaaS 小程序开发框架
实际上小程序是一次编写多端运行，可以把小程序分为四个部分。最左边的部分的话呢，是这个小程序基础框架，它包含整个的小程序的 App，生命周期，然后页面的周期，然后以及视图和自定义组件。在往右是一个基础的组件和 API， 它包含了非常多的基础组件和 API。在往右的就是你自己定义的一些开放的 API 和组件。
最后，这是小程序 IDE。提供 App应用级的页面级的视图级的组件级的编写，然后编写完成之后，可以把它发放到第三方小程序或者是你自己的业务的小程序，以及一些阿里系的外头的一些小程序。这就是一个整个小程序的一个开发框架。
3、mPaaS 小程序整体架构
mPaaS 小程序，首先是基于支付宝，和支付宝的架构是一样的，简单介绍一下 mPaaS 的一个小程序架构。先从右边来看这个整个的运行时的一个架构，首先，它是渲染层和逻辑层分离双线程进行的双线程的一个架构。渲染层每个页面会有一个渲染器来帮助它的页面集中渲染。
渲染完之后，有一些页面的事件交互通过事件发送给到 Native 的消息通道，消息通道将这些事件发给逻辑层，逻辑层找到对应页面的逻辑进行逻辑处理，处理完成之后，将结果返回给页面层，页面层根据结果再去对结果进行渲染。
这就完成了一个小程序整体的一个架构流程梳理。同时，Native 层还会提供非常多的底层能力，以 API 的形式提供给逻辑层和渲染层。右边就是一个整体的运行时的一个渲染架构。
Render 是一个渲染器，渲染器可能是通过外部的渲染器，或者是通过 Flutter 渲染器或者是一些 web 加 Native 结合的渲染器等等，渲染器是可以随时替换的。这就是一个小程序运行时的一个渲染架构。
左边是小程序的构建和小程序的发布。
构建就是在代码编写中，可以进行多端转换、编译打包、预览调试，在发布的时候，把小程序构建完成之后，可以对它进行上传，然后你的输入端会对它进行审核。
审核完成之后，可以进行发布，发布之前可以对本次发布进行一些灰度发布，进行一些灰度的验证。这张图就是一个 pass 小程序的一个整体架构。
4、mPaaS 小程序标准
首先，小程序要满足以下六个标准，才是个比较标准的小程序。
• 双线程结构
• 包体构造
• UI 组件& API
• 入口规范
• 部件
• 安全&隐私管控
这是基于 w3c 蓝皮书给出的标准的定义。首先小程序要求是双线，具备双线程结构，也就是渲染和逻辑分离。
其次，小程序包体构造要按照一定规范，例如描述文件要有一个页面结构文件、样式文件和逻辑文件等等，这是它的包体构造。第三，小程序一定对开发者提供一些基础的 UI 和 API。第四，小程序要有一个合理的入口规范、启动参数、skmer。第五是小程序要支持以小部件的形式嵌入到别的页面当中。
例如聊天页面中的一些卡片等一些小部件。最后小程序一定要具备安全能力和隐私管控能力。这就是一个小程序的标准。
5、mPaaS 小程序动态性
这是一个 mPaaS 小程序的一个服务端的发布体系。首先，客户端 sdk 去访问这个小程序，然后小程序会通过 sdk 去访问服务端先到 cdn，然后再到我们的网关，再到配置中心，然后到我们的这个移动发布服务上，然后发布服务会通过查询关系型数据库，然后查询出对应的小程序，然后再通过我们的下载服务下载到客户端上。右边是一个 mPaaS 控制台，可以通过控制台去上传，去管理发布等，这就是一个整体的发布的一个结构。
发布它具备这么几种能力：
• 智能灰度能力，多种的升级策略——我可以根据这个内部黑度，灰度，外部灰度，人群，地域机型等多种规则供你选择，你可以对你的这个要发的业务去做一些灰度上的发布。
• 增差量分离线包更新能力——我们知道，在这个移动互联网时代，一个差量包越小，那它的下载成功率、出达率会越高。
• 系统高性能保障——让整个 mPaaS 的下载接口响应小于三毫秒，然后它的 QPS 大于5w/s，复达率是99.99%。
6、mPaaS 小程序动态发布实践
这其实是总结出来的一个比较好的一个发布的流程，首先就是发布一个小程序，我们要制定一些指标，然后再去通过灰度发布验证指标，然后运维监控，然后指标验证通过之后，进行正式发布，然后对线上的小程序进行持续监控。
这就是一个完整的周期，周期完之后，我们再进行下一次的编码构建，下一次的制定指标，这就是一个小程序的完整的一个发布事件。有了小程序的这个框架或者是平台，你的 APP 可以把你的业务分成多个业务，多个产品，产品 a 一直到产品 n，每一个产品之间的迭带相互影响，不用再像原来一样，所有发版都 All in 在一个时间点。我们可以每一个业务组去制定自己的业务指标。这就是一个小程序的一个发布实践。
7、mPaaS 小程序安全性
安全性的话，小程序主要从三个点来保证它的安全性。
• 连接安全——就是基于阿里巴巴的一个无线保镖能力，保障小程序请求安全。如果 APP 是被篡改或者是被人反编译打包黑产攻击，那他的请求小程序的请求是无法通过校验的。
• 包体安全——小程序有一些代码或者是逻辑，要下发到你的客户端上，所以小程序包一定要保证安全。我们是通过服务端加密客户端解密来保证包体安全。一旦当你的小程序的包认为不安全，或者是没有通过校验，这时候会去走线上的版本，拉线上的包体，然后走一个 format 的机制，这就是包体安全
• 权限安全——你的每个小程序都可以制定自己小程序的权项。每一个接口也可以制定每个接口的权限。比如说，去访问支付，那某些小程序可能就不能访问，通过审核或者后来配置成功的小程序，才可以访问对应的比较高的这个等级的权限。这就是一个小程序的安全和隐私管控。
8、mPaaS 小程序扩展性
因为小程序是一个 sdk，那到每个人的应用中，可能对小程序的整体的展现样式会有一些自己的定制。这里提供了三个方向的自定义
• 自定义接口——mPaaS 小程序支持自定义一些你自己的能力提供给小程序进行调用。那他是支持双向通的。小程序可以调用原生的自定义接口，原生也可以发送一些事件到小程序，小程序来监听。这个是自定义接口
• 自定义样式——mPaaS 提供多种样式，包括导航栏的样式，然后胶囊按钮的样式以及你的小程序，启动，加载动画等这些样式可以编辑。
• 自定义组件——小程序支持一些自定义组件的扩展标签，比如说像地图，都是将一个原生的组件去嵌入到小程序页面中，这就是自定义组件的一个自定义。
9、mPaaS 小程序实现多端投放
这个图分为四个部分，第一个部分就是小程序的来源是从哪里来？有四个方向。首先是你自建的一个 mPaaS 小程序，自己开发通过 id， 自己开发自己的业务小程序，这是一个来源；第二个来源，是 mPaaS 会提供一个小程序市场。
会持续的往里边提供一些小程序；第三个就是支付宝小程序，如果你的业务之前开发过支付宝小程序，你可以直接把它拿来使用，直接投到自己的 APP 上；第四个就是其他三方小程序，mPaaS、IDE 插件会提供一些转换能力，将其他三方的小程序，转成支付宝小程序格式，然后投放到我们自己的 APP 中。第二层是一个 IDE 层，IDE 层首先会提供多端投放工具。
把其他的小程序转换，然后小程序 IDE 还会提供开发，预览，调试等功能去帮助你去编写自己的业务代码。再下一层是 mPaaS 的一个发布层，发布层左边是 mPaaS 的发布平台，右边是其他开放的，第三方的开放平台。mPaaS 发布平台，就会把小程序去发布到你自己的 app 中，其他第三方开放平台的就会发布到对应的平台中，那mPaaS 平台会对应到应用层，会发到自建的应用上，自有的 APP上。
然后可以看到自有 APP 可以跑，一些自建小程序、第三方小程序，或者是 mPaaS 提供的一些阿里系的场景小程序，比如说你在应用上想跑一个饿了么、高德打车等一些场景系的小程序。
右边是第三方的平台，比如说，可以把开发好的小程序投到支付宝，淘宝这些阿里系的平台上，同时也可以投到一些其他的第三方框架平台上。
10、mPaaS 小程序场景生态
小程序实际上和支付宝是完全相同的架构，相同的小程序可以直接经过少量的改造，进行多端的投放。
这里有一个 mPaaS Server， 然后把一些第三方的场景小程序投放到 mPaaS Server 上，然后最终去拉到自己的 APP 上。这就是整个场景小程序的一个投放流程。
