小程序技术方案探讨

微信小程序上线大半年，大部分技术原理也有文章介绍了，本文尝试从需求出发探讨微信小程序技术方案的来源，以及最近公测的支付宝小程序技术方案上的考量。

微信小程序

微信小程序的需求是让第三方开发者能够接入，能够使用微信的提供的接口去开发应用嵌入在微信里。对于这个需求，最简单的实现方案是：让外部开发者开发纯H5应用，在微信的 H5 容器里打开，容器提供微信 native 接口，就好了。在有小程序以前，已经有不少这样的业务接入，像京东购物，钱包里的各类友商大众点评/滴滴出行等，均可以认为是一个“小程序”，内嵌在微信里，能调用微信 native 接口，是否是沿着这种模式下去，把相应的接口开放给第三方，再提供个入口就好了？

实际上这种简单的方案不能知足需求，在产品上微信小程序有另外两个很重要的需求：

1. 管控。做为一个平台必须对接入的应用有管控能力，必须能尽可能精确控制应用的内容和类型，毕竟若出现非法应用平台是要承担责任的，H5 的方式太过自由，开发者能够随时改变整个应用的内容，平台难以检测到这些改变，没法管控。另外H5开发质量良莠不齐，平台也没法管控，这对于一贯有洁癖的微信来讲没法接受。
2. 体验。做为一个“小程序”须要让体验接近原生，而上述像京东购物这些普通 H5 页面的体验不太行，包括启动速度/页面切换流畅度都有问题，跟原生体验无法比。

全部小程序的技术方案都是为了这两个需求服务。

管控

为了知足管控的需求，技术上微信作了两个事情：小程序框架和分离JS运行环境。

框架/DSL

H5太自由，首先要作的就是限制它的自由，怎样限制？天然是作个框架套住，让开发者只能按框架的规则去开发。那应该使用怎样的框架？

在 PC SNS 时代，Facebook 作开放平台时有相似的场景，为了第三方开发者能在 Facebook 平台上开发，同时又能限制住开发者的权限，Facebook 要求开发者使用自定义的一套 DSL(FBML)去开发，而这个 DSL 能怎么写，最终能转成什么，如何执行，都是平台说了算，同时也能够很方便作代码扫描和审查。

小程序正好能借鉴这样的设计思路，界面不使用 HTML 开发，而是自定义一套 DSL，这样就能够很容易配合审核/代码扫描/域名限制等系列措施去作管控，这就是小程序这一套框架的来源。这套框架经过 wxml 去描述界面，wxss 描述样式，js 去处理逻辑和数据，再经过工具一系列处理把这些转为 HTML/CSS/JS 显示在 webview 上，并处理界面交互和数据更新。

这样用一套框架去限制开发方式，再造一层 DSL，除了管控外还有一个好处，就是容易进行针对性优化，DSL 最终转成什么，最终如何执行渲染都由框架决定，上层不感知，能够作成由 webview 渲染，有条件也能够用相似RN的方案本身实现渲染层。

JS 环境

经过框架限定开发方式后，管控上还有个问题，就是如何限制应用端类JS语言调用dom API？小程序跑在 webview 上，渲染时必然要经过 JS 操做 dom，若是小程序框架和应用 JS 代码都有权限操做 dom，应用可能会经过各类方式在上线后绕过检查，注入 JS 调用 dom 接口去修改页面结构和内容，变成跟审核时不同的应用。怎样能限制应用的 JS 调用 dom 的权限？微信想了个比较创新的解决方案，就是：JS 运行环境与浏览器分离，运行在单独的 JS 引擎上。

脱离了浏览器，JS 天然没有 dom 的调用权限，任何跟 webview 界面相关的 API 都没法拿到。而小程序框架核心JS运行在webview上，能够自由操做dom，经过小程序框架定义的机制，应用端经过 wxml/wxss 定义固定的渲染样式，JS 端只管数据绑定，数据能够经过 native 桥梁从 JS 引擎传递到 webview，JS端没法作任何渲染相关的操做，能够对渲染的内容有完整的管控权。

独立的 JS 运行环境除了知足管控需求外，也额外带来一些好处和一些坏处，好处在于：

1. 多个页面能够共享一个 JS 运行环境，数据能够很方便地共享，整个小程序生命周期里共享同一个上下文，更接近 APP 的开发体验。
2. JS 与页面渲染分离并行执行，不会出现 JS 执行时卡住页面渲染的状况，提高渲染性能。

坏处在于：

1. 多了数据序列化传输的开销，数据须要从 JS 传到 webview 给视图层渲染，须要序列化为字符串格式再进行传输。
2. iOS 上 WKWebview 的 JS 引擎比 JavaScriptCore 多了 JIT 优化，执行速度快不少倍，小程序的 JS 运行在 JavaScriptCore 上没法享受到这个优化。

因为管控需求过于刚需，这个方案带来坏处能够接受。

体验

小程序最主要的两个技术点 — 框架和JS运行分离 都是源自管控需求，而体验上的需求就是由各类细致的性能优化组成了，不少文章也分析过，这里简单说下，包括：

1. 离线包：整个小程序打包下发，不须要打开每一个页面都去请求，减小第二次打开时间以及页面切换时间。
2. 预加载：预加载多一个wkwebview放后台，用户打开小程序时省去初始化wkwebview时间。另外对于一个小程序内的页面切换，得益于框架的设计，能够作到预渲染模板，切换时再填充数据，加快渲染速度。
3. 缓存：退出小程序后不会当即销毁，会在后台继续跑5分钟，在这期间用户切回小程序时速度快。
4. 视觉：小程序首次加载经过loading和动画的方式过渡，拒绝白屏，给人一种快的感受，同时提高了小程序的标识度。

剩下的就是围绕小程序这个平台的周边建设了，像组件，native接口，IDE，后台管理，版本管理，权限控制等基础支持。