页面渲染的方式主要有三种
1.web渲染
2.Native原生渲染
3.web与Native两者掺杂，即Hybrid渲染。
小程序的呈现形式为第三种。
双线程通信方式
为什么要双线程 ？ -> 为了管控安全，避免操作DOM。
小程序的渲染层和逻辑层分别由 2 个线程管理：渲染层的界面使用了 WebView 进行渲染，逻辑层采用 JsCore 线程运行 JS 脚本。
微信小程序的框架包含两部分 view视图层、APP service逻辑层。
view层用来渲染页面结构，
AppService用来逻辑处理、数据请求、接口调用。
在两个进程（两个webview）里运行。
视图层和逻辑层通过系统层的JSBridage进行通信。
逻辑层： 创建一个单独的线程去执行JavaScript,在这个环境下执行的都是有关小程序业务逻辑的代码
渲染层： 界面渲染相关的任务全都在webView线程中执行，通过逻辑层的代码去控制渲染哪些界面。
一个小程序存在多个界面，所以渲染层存在多个webview线程。
逻辑层和渲染层的通信会由Native（微信客户端）做中转，
逻辑层发送网络请求也会经由Native转发。
evaluate Javascript
视图层和逻辑层的数据传输，实际上通过两边提供的evaluateJavascript实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份JS脚本，在通过JS脚本的形式传递到两边独立环境。
因为evaluateJavascript的执行会受很多方面的影响，数据到达视图层并不是实时的。随意我们的setData函数将数据从逻辑层发送到视图层，是异步的。
模板数据绑定方案
1.解析语法生成AST
2.根据AST结果生成DOM
3.将数据绑定更新至模板
抽象语法树(abstract syntax tree或者缩写为AST)
最容易引发性能问题的主要是第三点，而关于数据更新的解决方案，React首先提出了虚拟DOM的设计，而现在也基本被大部分框架吸收，小程序也不例外。
虚拟 DOM 机制 virtual Dom
用JS对象模拟DOM树 -> 比较两个DOM树 -> 比较两个DOM树的差异 -> 把差异应用到真正的DOM树上
1.在渲染层把WXML转化成对应的JS对象
2.在逻辑层发生数据变更的时候，通过宿主环境提供的setData方法把数据从逻辑层传递到Native，再转发到渲染层
3.经过对比前后差异，把差异应用在原来的DOM树上，更新界面
小程序的基础库
小程序的基础库是JavaScript编写的，它可以被注入到渲染层和逻辑层运行。主要用于：
在渲染层，提供各类组件来组件页面的元素
在逻辑层，提供各种API来处理各种元素。
处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑
小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。
小程序的基础库不会打包在小程序的代码中，它会被提前内置在微信客户端。这样可以：
降低业务小程序的代码包大小
可以单独修复基础库中的Bug，无需修改到业务小程序的代码包
Exparser
Exparser是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各种组件提供基础支持。小程序内所有组件，包括内置组件和自定义组件，都有Exparser组织管理。
双线程的渲染机制
双线程的渲染，其实是结合了前面的一系列机制。
1.通过模板数据绑定和虚拟DOM机制，小程序提供了带有数据绑定语法的DSL，渲染层来描述页面结构。
2.小程序在逻辑层提供了设置页面数据的api
this.setData({
key : value
});
3.逻辑层需要更改页面时，只要把修改后的data通过setData传到渲染层。
传输的数据，会转换为字符串形式传输，故应避免传递大量数据。
4.渲染层会根据渲染机制重新生成虚拟DOM树，并更新到对应的DOM树上，引起界面变化。
引入原生组件
绕过 setData、数据通信和重渲染流程，使渲染性能更好。
扩展 Web 的能力。比如像输入框组件（input, textarea）有更好地控制键盘的能力。
体验更好，同时也减轻 WebView 的渲染工作。比如像地图组件（map）这类较复杂的组件，其渲染工作不占用 WebView 线程，而交给更高效的客户端原生处理。
原生组件的渲染过程：
组件被创建，包括组件属性会依次赋值。
组件被插入到 DOM 树里，浏览器内核会立即计算布局，此时我们可以读取出组件相对页面的位置（x, y坐标）、宽高。
组件通知客户端，客户端在相同的位置上，根据宽高插入一块原生区域，之后客户端就在这块区域渲染界面。
当位置或宽高发生变化时，组件会通知客户端做相应的调整。