浅谈小程序运行机制( 二 ) _小程序

扩展 Web 的能力。比如像输入框组件(input, textarea)有更好地控制键盘的能力

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

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

用客户端原生渲染内置一些复杂组件，可以提供更好的性能

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

文章插图

文章插图
那么为什么要这样设计呢，前面也提到了管控和安全，为了解决这些问题，我们需要阻止开发者使用一些，例如浏览器的window对象，跳转页面、操作DOM、动态执行脚本的开放性接口。
我们可以使用客户端系统的 JavaScript 引擎，IOS 下的 JavaScriptCore 框架，Android/ target=_blank class=infotextkey>安卓下腾讯 x5 内核提供的 JsCore 环境。
这个沙箱环境只提供纯 JavaScript 的解释执行环境，没有任何浏览器相关接口。
这就是小程序双线程模型的由来：

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

三、双线程通信
把开发者的 JS 逻辑代码放到单独的线程去运行，但在 Webview 线程里，开发者就没法直接操作 DOM 。
那要怎么去实现动态更改界面呢?
如上图所示，逻辑层和试图层的通信会由 Native (微信客户端)做中转，逻辑层发送网络请求也经由 Native 转发。
这也就是说，我们可以把 DOM 的更新通过简单的数据通信来实现。
Virtual DOM 相信大家都已有了解，大概是这么个过程：用 JS 对象模拟 DOM 树 -> 比较两棵虚拟 DOM 树的差异 -> 把差异应用到真正的 DOM 树上。
如图所示：

文章插图
【浅谈小程序运行机制】1. 在渲染层把 WXML 转化成对应的 JS 对象。
2. 在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。
3. 经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。
我们通过把 WXML 转化为数据，通过 Native 进行转发，来实现逻辑层和渲染层的交互和通信。
而这样一个完整的框架，离不开小程序的基础库。
四、小程序的基础库
小程序的基础库可以被注入到视图层和逻辑层运行，主要用于以下几个方面：

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

由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。
小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。
这样可以：

降低业务小程序的代码包大小
可以单独修复基础库中的 Bug，无需修改到业务小程序的代码包

五、Exparser 框架
Exparser是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各种组件提供基础的支持。小程序内的所有组件，包括内置组件和自定义组件，都由Exparser组织管理。
Exparser的主要特点包括以下几点：
1.基于Shadow
DOM模型：模型上与WebComponents的ShadowDOM高度相似，但不依赖浏览器的原生支持，也没有其他依赖库;实现时，还针对性地增加了其他API以支持小程序组件编程。
2.可在纯JS环境中运行：这意味着逻辑层也具有一定的组件树组织能力。
3.高效轻量：性能表现好，在组件实例极多的环境下表现尤其优异，同时代码尺寸也较小。
小程序中，所有节点树相关的操作都依赖于Exparser，包括WXML到页面最终节点树的构建、createSelectorQuery调用和自定义组件特性等。
内置组件
基于Exparser框架，小程序内置了一套组件，提供了视图容器类、表单类、导航类、媒体类、开放类等几十种组件。有了这么丰富的组件，再配合WXSS，可以搭建出任何效果的界面。在功能层面上，也满足绝大部分需求。