微信小程序底层架构

从技术的发展角度来看，微信小程序是从微信中的 webView 和 JS-SDK 进化到了今天的形态。那么，小程序和普通的h5页面到底有什么区别呢？

运行环境：小程序基于浏览器内核重构的内置解析器，而 h5 的宿主环境是浏览器。所以小程序中没有 DOM 和 BOM 的相关 API，jQuery和一些 NPM 包都不能在小程序中使用；

系统权限：小程序能获得更多的系统权限，如网络通信状态、数据缓存能力等；

渲染机制：小程序的逻辑层和渲染层是分开的，而 h5 页面 UI 渲染跟 JavaScript 的脚本执行都在一个单线程中，互斥。所以 h5 页面中长时间的脚本运行可能会导致页面失去响应。

其实，小程序开发过程中我们面对的是 iOS 和 Android 微信客户端和辅助开发的小程序开发者工具。根据官方文档，这三大运行环境也是有所区别的：

运行环境

逻辑层

渲染层

iOS

JavaScriptCore

WKWebView

Android

X5 JSCore

X5浏览器

小程序开发者工具

NWJS

Chrome WebView

所以微信小程序介于 web 端和原生 App 之间，能够丰富调用功能接口，同时又跨平台。

2. 小程序架构

2.1 双线程模型

小程序的渲染层和逻辑层分别由2个线程管理：

渲染层：界面渲染相关的任务全都在 WebView 线程里执行。一个小程序存在多个界面，所以渲染层存在多个 WebView线程。

逻辑层：采用 JsCore 线程运行JS脚本。

视图层和逻辑层通过系统层的 WeixinJsBridage 进行通信：逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务处理。

（页面渲染的具体流程是：在渲染层，宿主环境会把 WXML 转化成对应的 JS 对象，在逻辑层发生数据变更的时候，我们需要通过宿主环境提供的 setData 方法把数据从逻辑层传递到渲染层，再经过对比前后差异，把差异应用在原来的Dom树上，渲染出正确的UI界面）

双线程模型是小程序框架与业界大多数前端 Web 框架不同之处。基于这个模型，可以更好地管控以及提供更安全的环境。缺点是带来了无处不在的异步问题（任何数据传递都是线程间的通信，也就是都会有一定的延时），不过小程序在框架层面已经封装好了异步带来的时序问题。

2.2 组件系统

我们知道小程序是有自己的组件的，这些基本组件就是基于 Exparser 框架。Exparser 基于 WebComponents 的 ShadowDOM 模型，但是不依赖浏览器的原生支持，而且可在 纯 JS 环境中运行。

小程序中，所有节点树相关的操作都依赖于 Exparser，包括 WXML 到页面最终节点树的构建、CreateSelectorQuery 调用和自定义组件特性等。

现在微信小程序也支持自定义组件了，用法和组件间通信类似于 Vue。

2.3 原生组件

在内置组件中，有一些组件并不完全在 Exparser 的渲染体系下，而是由客户端原生参与组件的渲染。比如说 Map 组件。它渲染的层级比在 WebView 层渲染的普通组件要高。

引入原生组件的优点是：

扩展 Web 的能力

体验更好，减轻 WebView 的渲染工作

绕过 setData、数据通信和重渲染流程，性能更好

2.4 运行机制

2.4.1 启动

热启动：：假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台态的小程序切换到前台，这个过程就是热启动；

冷启动：用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动，即冷启动。

2.4.2 销毁

只有当小程序进入后台一定时间，或者系统资源占用过高，才会被真正的销毁。