浅谈小程序运行机制

写做背景

接触小程序有一段时间了，总得来讲小程序开发门槛比较低，但其中基本的运行机制和原理仍是要懂的。“好比我在面试的时候问到一个关于小程序的问题，问小程序有window对象吗？他说有吧”，但实际上是没有的。感受他并无了解小程序底层的一些东西，归根结底来讲应该只能算会使用这个工具，但并不明白其中的道理。

小程序与普通网页开发是有很大差异的，这就要从它的技术架构底层去剖析了。还有好比习惯Vue，react开发的开发者会吐槽小程序新建页面的繁琐，page必须由多个文件组成、组件化支持不完善、每次更改 data 里的数据都得setData、没有像Vue方便的watch监听、不能操做Dom，对于复杂性场景不太好，以前不支持npm，不支持sass，less预编译处理语言。

“有的人说小程序就像被阉割的Vue”，哈哈固然了，他们从设计的出发点就不一样，咱也得理解小程序设计的初衷，经过它的使用场景，它为何采用这种技术架构，这种技术架构有什么好处，相信在你了解完这些以后，就会理解了。下面我会从如下几个角度去分析小程序的运行机制和它的总体技术架构。

了解小程序的由来

在小程序没有出来以前，最初微信WebView逐渐成为移动web重要入口，微信发布了一整套网页开发工具包，称之为 JS-SDK，给全部的 Web 开发者打开了一扇全新的窗户，让全部开发者均可以使用到微信的原生能力，去完成一些以前作不到或者难以作到的事情。

但JS-SDK 的模式并无解决使用移动网页遇到的体验不良的问题，好比受限于设备性能和网络速度，会出现白屏的可能。所以又设计了一个加强版JS-SDK，也就是“微信 Web 资源离线存储”，但在复杂的页面上依然会出现白屏的问题，缘由表如今页面切换的生硬和点击的迟滞感。这个时候须要一个 JS-SDK 所处理不了的，使用户体验更好的一个系统，小程序应运而生。

• 快速的加载
• 更强大的能力
• 原生的体验
• 易用且安全的微信数据开放
• 高效和简单的开发

小程序与普通网页开发的区别

小程序的开发同普通的网页开发相比有很大的类似性，小程序的主要开发语言也是 JavaScript，可是两者仍是有些差异的。

• 普通网页开发可使用各类浏览器提供的 DOM API，进行 DOM 操做，小程序的逻辑层和渲染层是分开的，逻辑层运行在 JSCore
  中，并无一个完整浏览器对象，于是缺乏相关的DOM API和BOM
  API。
• 普通网页开发渲染线程和脚本线程是互斥的，这也是为何长时间的脚本运行可能会致使页面失去响应，而在小程序中，两者是分开的，分别运行在不一样的线程中。
• 网页开发者在开发网页的时候，只须要使用到浏览器，而且搭配上一些辅助工具或者编辑器便可。小程序的开发则有所不一样，须要通过申请小程序账号、安装小程序开发者工具、配置项目等等过程方可完成。
• 小程序的执行环境

小程序架构

1、技术选型

通常来讲，渲染界面的技术有三种：

• 用纯客户端原生技术来渲染
• 用纯 Web 技术来渲染
• 用客户端原生技术与 Web 技术结合的混合技术（简称 Hybrid 技术）来渲染

经过如下几个方面分析，小程序采用哪一种技术方案

• 开发门槛：Web 门槛低，Native 也有像 RN 这样的框架支持
• 体验：Native 体验比 Web 要好太多，Hybrid 在必定程度上比 Web 接近原生体验
• 版本更新：Web 支持在线更新，Native 则须要打包到微信一块儿审核发布
• 管控和安全：Web 可跳转或是改变页面内容，存在一些不可控因素和安全风险

因为小程序的宿主环境是微信，若是用纯客户端原生技术来编写小程序，那么小程序代码每次都须要与微信代码一块儿发版，这种方式确定是不行的。

因此须要像web技术那样，有一份随时可更新的资源包放在云端，经过下载到本地，动态执行后便可渲染出界面。若是用纯web技术来渲染小程序，在一些复杂的交互上可能会面临一些性能问题，这是由于在web技术中，UI渲染跟JavaScript的脚本执行都在一个单线程中执行，这就容易致使一些逻辑任务抢占UI渲染的资源。

因此最终采用了二者结合起来的Hybrid 技术来渲染小程序，能够用一种近似web的方式来开发，而且能够实如今线更新代码，同时引入组件也有如下好处：

• 扩展 Web 的能力。好比像输入框组件（input, textarea）有更好地控制键盘的能力
• 体验更好，同时也减轻 WebView 的渲染工做
• 绕过 setData、数据通讯和重渲染流程，使渲染性能更好
• 用客户端原生渲染内置一些复杂组件，能够提供更好的性能

2、双线程模型

小程序的渲染层和逻辑层分别由 2 个线程管理：视图层的界面使用了 WebView 进行渲染，逻辑层采用 JsCore 线程运行 JS脚本。

那么为何要这样设计呢，前面也提到了管控和安全，为了解决这些问题，咱们须要阻止开发者使用一些，例如浏览器的window对象，跳转页面、操做DOM、动态执行脚本的开放性接口。

咱们可使用客户端系统的 JavaScript 引擎，iOS 下的 JavaScriptCore 框架，安卓下腾讯 x5 内核提供的 JsCore 环境。

这个沙箱环境只提供纯 JavaScript 的解释执行环境，没有任何浏览器相关接口。

这就是小程序双线程模型的由来：

• 逻辑层：建立一个单独的线程去执行 JavaScript，在这里执行的都是有关小程序业务逻辑的代码，负责逻辑处理、数据请求、接口调用等
• 视图层：界面渲染相关的任务全都在 WebView 线程里执行，经过逻辑层代码去控制渲染哪些界面。一个小程序存在多个界面，因此视图层存在多个 WebView 线程
• JSBridge 起到架起上层开发与Native（系统层）的桥梁，使得小程序可经过API使用原生的功能，且部分组件为原生组件实现，从而有良好体验

3、双线程通讯

把开发者的 JS 逻辑代码放到单独的线程去运行，但在 Webview 线程里，开发者就无法直接操做 DOM。

那要怎么去实现动态更改界面呢？

如上图所示，逻辑层和试图层的通讯会由 Native （微信客户端）作中转，逻辑层发送网络请求也经由 Native 转发。

这也就是说，咱们能够把 DOM 的更新经过简单的数据通讯来实现。

Virtual DOM 相信你们都已有了解，大概是这么个过程：用 JS 对象模拟 DOM 树 -> 比较两棵虚拟 DOM 树的差别 -> 把差别应用到真正的 DOM 树上。

如图所示：

1. 在渲染层把 WXML 转化成对应的 JS 对象。

2. 在逻辑层发生数据变动的时候，经过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。

3. 通过对比先后差别，把差别应用在原来的 DOM 树上，更新界面。

咱们经过把 WXML 转化为数据，经过 Native 进行转发，来实现逻辑层和渲染层的交互和通讯。

而这样一个完整的框架，离不开小程序的基础库。

4、小程序的基础库

小程序的基础库能够被注入到视图层和逻辑层运行，主要用于如下几个方面：

• 在视图层，提供各种组件来组建界面的元素
• 在逻辑层，提供各种 API 来处理各类逻辑
• 处理数据绑定、组件系统、事件系统、通讯系统等一系列框架逻辑

因为小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。

小程序的基础库不会被打包在某个小程序的代码包里边，它会被提早内置在微信客户端。

这样能够：

• 下降业务小程序的代码包大小
• 能够单独修复基础库中的 Bug，无需修改到业务小程序的代码包

5、Exparser 框架

Exparser是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各类组件提供基础的支持。小程序内的全部组件，包括内置组件和自定义组件，都由Exparser组织管理。

Exparser的主要特色包括如下几点：

1. 基于Shadow
   DOM模型：模型上与WebComponents的ShadowDOM高度类似，但不依赖浏览器的原生支持，也没有其余依赖库；实现时，还针对性地增长了其余API以支持小程序组件编程。
2. 可在纯JS环境中运行：这意味着逻辑层也具备必定的组件树组织能力。
3. 高效轻量：性能表现好，在组件实例极多的环境下表现尤为优异，同时代码尺寸也较小。

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

内置组件

基于Exparser框架，小程序内置了一套组件，提供了视图容器类、表单类、导航类、媒体类、开放类等几十种组件。有了这么丰富的组件，再配合WXSS，能够搭建出任何效果的界面。在功能层面上，也知足绝大部分需求。

6、运行机制

小程序启动会有两种状况，一种是「冷启动」，一种是「热启动」。假如用户已经打开过某小程序，而后在必定时间内再次打开该小程序，此时无需从新启动，只需将后台状态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的状况，此时小程序须要从新加载启动。

• 小程序没有重启的概念
• 当小程序进入后台，客户端会维持一段时间的运行状态，超过必定时间后（目前是5分钟）会被微信主动销毁
• 当短期内（5s）连续收到两次以上收到系统内存告警，会进行小程序的销毁

7、更新机制

小程序冷启动时若是发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序须要等下一次冷启动才会应用上。 若是须要立刻应用最新版本，可使用 wx.getUpdateManager API 进行处理。

8、性能优化

主要的优化策略能够概括为三点：

• 精简代码，下降WXML结构和JS代码的复杂性；
• 合理使用setData调用，减小setData次数和数据量；
• 必要时使用分包优化。

一、setData 工做原理

小程序的视图层目前使用 WebView 做为渲染载体，而逻辑层是由独立的 JavascriptCore 做为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具有数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上经过两边提供的 evaluateJavascript 所实现。即用户传输的数据，须要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再经过执行 JS 脚本的形式传递到两边独立环境。

而 evaluateJavascript 的执行会受不少方面的影响，数据到达视图层并非实时的。

二、常见的 setData 操做错误

1. 频繁的去 setData在咱们分析过的一些案例里，部分小程序会很是频繁（毫秒级）的去setData，其致使了两个后果：Android下用户在滑动时会感受到卡顿，操做反馈延迟严重，由于 JS 线程一直在编译执行渲染，未能及时将用户操做事件传递到逻辑层，逻辑层亦没法及时将操做处理结果及时传递到视图层；渲染有出现延时，因为 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通讯耗时上升，视图层收到的数据消息时距离发出时间已通过去了几百毫秒，渲染的结果并不实时；
2. 每次 setData 都传递大量新数据由setData的底层实现可知，咱们的数据传输实际是一次 evaluateJavascript
3. 脚本过程，当数据量过大时会增长脚本的编译执行时间，占用 WebView JS 线程， 后台态页面进行
   setData当页面进入后台态（用户不可见），不该该继续去进行setData，后台态页面的渲染用户是没法感觉的，另外后台态页面去setData也会抢占前台页面的执行。

总结

大体从以上几个角度分析了小程序的底层架构，从小程序的由来、到双线程的出现、设计、通讯、到基础库、Exparser 框架、再到运行机制、性能优化等等，都是一个个相关而又相互影响的选择。关于小程序的底层框架设计，其实涉及到的还有不少，好比自定义组件，原生组件、性能优化等方面，都不是一点能讲完的，还要多看源码，多思考。每个框架的诞生都有其意义，咱们做为开发者能作的不仅是会使用这个工具，还应理解它的设计模式。只有这样才不会被工具左右，才能走的更远！