浅谈微信小程序底层架构

• 运行环境：小程序基于浏览器内核重构内置解析器，而h5的宿主环境是浏览器。所以小程序中没有DOM和BOM的相关API，jQuery和一些NPM包都不能在小程序中使用；
• 系统权限：小程序能获得更多的系统权限，如网络通信状态、数据缓存能力等；
• 渲染机制：小程序的逻辑层和渲染层是分开的，而h5页面UI渲染跟JavaScript的脚本执行都在一个单线程中，互斥。所以h5页面中长时间的脚本运行可能会导致页面失去响应。

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

所以微信小程序介于 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层渲染的普通组件要高。

引入原生组件的优点是：

WebWebView
setData

2.4 运行机制

2.4.1 启动

• 热启动：假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台态的小程序切换到前台，这个过程就是热启动；
• 冷启动：用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动，即冷启动。

2.4.2 销毁

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

2.5 更新机制

开发者在后台发布新版本之后，无法立刻影响到所有现网用户，但最差情况下，也在发布之后 24 小时之内下发新版本信息到用户。

小程序每次冷启动时，都会检查是否有更新版本，如果发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序需要等下一次冷启动才会应用上。

所以如果想让用户使用最新版本的小程序，可以利用wx.getUpdateManager做个检查更新的功能：

checkNewVersion() {    const updateManager = wx.getUpdateManager();
    updateManager.onCheckForUpdate((res) => {      console.log('hasUpdate', res.hasUpdate);      // 请求完新版本信息的回调
      if (res.hasUpdate) {
        updateManager.onUpdateReady(() => {          this.setData({            hasNewVersion: true
          });
        });
      }
    });
  }

微信小程序的基础底层架构大概就这么多，有机会再看看源码思考解析吧。