转载：支付宝小程序技术历程 - 框架概述

前言

经过近一年的开发，上周 支付宝小程序 终于得以公测，期间由于我们的疏忽将 wx 的部分示例放到了我们的开放文档中，给公司造成了麻烦，在此团队成员向各位同事表示歉意。但正如道歉信所言，我们的底层架构是完全基于蚂蚁金服多年的技术积累，踩过无数的坑而形成，且一直在完善中。之前一年我也 all in 在小程序中出于保密很少发文(其实我变懒了？？)，经过本周的平稳运行，我想解释下支付宝小程序的技术架构，在公司内部希望大家能够对支付宝小程序有更多的了解。

历程

回想近一年的开发，技术选型多次变更，历程曲折而又折腾，可谓苦中作乐。在去年 9 月份响应号召，我们先后尝试了 react-native，react web，以及基于纯开放 jsapi 的 h5 等方案，最终在年初确定了对外的支付宝小程序采用 react web 方案，但我们并没有放弃 react-native 方案，目前稳定运行在蚂蚁财富客户端中。

框架

小程序框架的设计目标为无缝运行在桌面 web 开发环境(IDE)，客户端原生环境（react-native），客户端 web 环境中，运行效果示意图：

image

因此框架顺应潮流命名为 AppX(Application framework for X platform). 也是支付宝小程序中引入的 js 文件名称。

设想的整体方案中还包括了 native SDK 的支持，后续分别由 nebula 以及小程序 native 容器承担了该角色.

image

架构图

image

每个小程序的代码分为两部分，分别运行在 worker(JSEngine) 以及 render 渲染层中， render 可以有多个， worker 只有一个，方便 app 数据在页面间的共享和交互。

worker 运行小程序的逻辑处理代码，包括事件处理，api 调用以及框架的生命周期管理。

render 运行小程序的渲染代码，主要包括模版／样式和框架的跨终端的 js 组件或 native 组件，获取逻辑层的数据操作渲染引擎(React/ReactNative)进行渲染。

worker 和所有的 render 都建立连接，将需要渲染的数据传递给对应的 render 进行渲染，worker 也会将 api 调用转给 native SDK 处理。

render 则将组件的触发事件送到对应的 worker 处理，同时接受 worker 的 setData 调用 React 重新渲染。 render 可以看作一个无状态的渲染终端，状态统统保留在 app 级别的 worker 里面，因此 render 可以看作 react 单页 app 中的 dumb component，worker 可以看作 react 单页 app 中的 redux。

IDE 开发环境

运行在 electron 中，通过空白 webview 模拟单独的 js 线程运行小程序的 worker 代码(可以保持调试窗口的稳定性以及定制性) ，通过 electron 进程通信机制将逻辑处理产生的渲染数据渲染到对应的 webview 页面.

客户端 web 环境

render 包括一个 UIViewController(Activity) 以及 webview，worker 为每个应用提供独立的唯一线程，其中 ios 通过 jscore， android 通过系统的 service worker 运行小程序 app 的 worker 部分代码，并和当前应用的所有 webview 建立连接，用户将数据从 jscore 线程中传递给 webview 渲染，同时客户端通过拦截 jscore 线程的 api 调用提供 native 功能。

客户端 react-native 环境

render 包括一个 UIViewController(Activity) 以及 react-native root view，worker 通过 react-native 共享 bridge 实现。worker 可以通过 react-native NativeModules 和客户端直接通信，setData 则更简单了就是 react-native 自带的 setState 通信机制