一、小程序 VS web与原生开发
| 开发类别 | 优点 | 缺点 |
|---|---|---|
| Web前端开发 | 跨端开发，速度快，支持公司业务快速发展 | 兼容性，体验较差 |
| Native原生开发 | 更好的体验，性能，兼容性 | 功能迭代需要客户端发版 |
| 支付宝小程序开发 | 不需要客户端发版，同时接近原生体验，性能，兼容性 | 依赖支付宝容器能力，开发需要编译预览，真机调试（开发速度，体验不友好） |
支付宝小程序属于hybrid（混合）开发，小程序框架层提供了大量的原生基础组件， 使得体验接近原生；而页面样式，业务逻辑则是使用CSS，JavaScript开发；接下来我们 了解下支付宝小程序的技术架构。
二、小程序技术架构
1、启动流程
2、双线程模型
由于web开发太开放了，可以直接操作DOM，跳转到其他web页面，为了安全与管控（包括请求必须是https协议且域名必须设置白名单，逻辑层js代码不能访问浏览器DOM与BOM对象），小程序采用了双线程模型，即：视图线程（webview） 与 逻辑线程（worker）
2.1、逻辑层与视图层交互
逻辑层通过setData方法更新数据，setData调用线程postMessage方法将数据传递到视图层从而更新渲染视图 用户触发视图层ui事件，视图层调用postMessage（带上事件回调），逻辑层负责监听并执行定义的callback
2.2、逻辑层与原生交互
逻辑层通过jsapi（内部通过AlipayJsBridge）来调用原生能力 同时定义jsapi的回调来监听原生执行的结果
三、小程序框架
1、appx框架
├── af-appx.min.js
├── af-appx.worker.min.js
├── ...
- af-appx.min.js：也叫appx render框架，主要是用来渲染视图的，如：将小程序view标签转换为div；
- af-appx.worker.min.js：也叫appx worker框架，主要是建立worker与render的通信机制；提供构建小程序App，小程序页面Page，小程序自定义组件Component 全局方法...，提供小程序jsapi通过AlipayJsBridge调用原生能力
简要概括如下图：
2、App与Page生命周期（路由机制）
需要特别注意的是：用户点击右上角关闭，小程序并不会直接销毁，而是进入后台，触发app.onHide事件，当用户再次进入(打开)小程序时，小程序会从后台进入前台，触发app.onShow事件
3、组件生命周期
四、小程序测试
1、新增自定义编译模式
小程序app.json配置默认启动页只有一个（默认设置为首页），如果你在开发过程中需要测试你新增的功能页面，你可以在小程序开发者工具ide中新增编译模式，设置启动页，还可以设置需要模拟的页面，全局参数，这样非常方便，而不需要去改动小程序的代码配置；如下图：
2、性能调试（入口在ide实验室）
-
在你完成功能页面开发后，即将上传小程序代码审核之前，你必须对你的页面进行性能调试，它可以帮助你发现代码错误，页面性能耗时等问题，并且建议你该怎么去做。
-
性能调试默认只针对启动页(即：app.json配置的第一个页面)，对新开发的功能页面做性能调试需要更改app.json配置。
3、质量洞察与开发监控（入口在ide实验室）
作为小程序开发者，应该每天关心小程序的质量及线上问题监控状态，我们可以通过小程序开发者工具ide实验室（质量洞察，开发监控）发现存在的问题并在下一个版本迭代中解决出现的问题。
4、web版打码工具（用于测试小程序功能入口页面）
在实际的项目开发及测试过程你可能会遇到如下问题
-
多套服务端接口环境，如：我的团队需要对小程序上架版本进行测试与生产接口环境的流程该怎么做？
-
我在小程序中做了一个活动（后续我可能在另一个小程序中做了另一个活动），公司内部或外部会帮我推广该活动链接，我需要在最短的时间内给到，该怎么做？
-
三方小程序跳公司小程序，回跳三方小程序时传递了数据，我们该怎么去验证？
-
三方小程序集成了我们的插件页面，插件与小程序进行了事件通信，我们该如何去验证？
以下流程是我们需要实现的，如图：
