小程序原理

小程序页面渲染

移动应用的页面渲染方式

移动应用：

• 原生应用(native app)
• 网页应用(web app，或HTML5 app)
• 混合模式移动应用(hybrid app)

对应页面渲染方式：

移动应用	页面渲染方式
原生应用(native app)	Native 渲染
网页应用(web app，或HTML5 app)	Web 渲染
混合模式移动应用(hybrid app)	Hybrid 渲染

Hybrid 渲染

小程序最终的呈现形式，是 WebView + 原生组件，Hybrid 方式。

优缺点对比：

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

为什么要使用Hybrid渲染？

1、原生渲染不可行：小程序要能独立于微信客户端的发版来迭代，原生渲染需要与微信代码一起打包，跟随微信发布版本，这是不对的。所以方向应该是需要像 Web 技术那样，有一份随时可更新的资源包放在云端，通过下载到本地，动态执行后即可渲染出界面。
2、纯web技术渲染不可行：使用纯web技术，一些复杂交互页面可能面临一些性能问题。因为Web技术中，UI和JS的脚本在单线程中，这样容易导致逻辑任务抢占UI渲染资源。
3、小程序选择了 Hybrid 的渲染方式，可以用一种近似 Web 的方式来开发，并且还可以实现在线更新代码。同时，引入原生组件有以下好处：

• 扩展 Web 的能力。比如像输入框组件（input, textarea）有更好地控制键盘的能力
• 体验更好，同时也减轻 WebView 的渲染工作
• 绕过 setData、数据通信和重渲染流程，使渲染性能更好

小程序使用双线程模型

什么是进程、线程与多线程

进程：
进程（Process）是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。
线程：
线程（英语：thread）是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

同一进程中的多条线程将共享该进程中的全部系统资源，如虚拟地址空间，文件描述符和信号处理等等。但同一进程中的多个线程有各自的调用栈（call stack），自己的寄存器环境（register context），自己的线程本地存储（thread-local storage）。

多线程：
多线程是指程序中包含多个执行流，即在一个程序中可以同时运行多个不同的线程来执行不同的任务，也就是说允许单个程序创建多个并行执行的线程来完成各自的任务。
优点：
可以提高CPU的利用率。在多线程程序中，一个线程必须等待的时候，CPU可以运行其它的线程而不是等待，这样就大大提高了程序的效率。
缺点：
线程也是程序，所以线程需要占用内存，线程越多占用内存也越多；
多线程需要协调和管理，所以需要CPU时间跟踪线程；
线程之间对共享资源的访问会相互影响，必须解决竞用共享资源的问题；
线程太多会导致控制太复杂，最终可能造成很多Bug。

小程序为什么使用双线程模型

• 小程序的要求：小程序迭代脱离微信客户端，体验优于网页，能结合微信的API，开发者的学习成本低。
  小程序这边的解决方案就是用跟开发网页类似的html+css+js（wxml+wxss+js）降低开发者学习成本，微信客户端去解析运行。
• 小程序不希望开发者能直接操作DOM，因为有些涉及用户隐私的数据，小程序只希望展示给用户看，不希望开发者能够获取，如果直接用网页那一套，开发者是能获取用户隐私的。
• 需要限制一些API的调用，比如不希望小程序能跳转到其他页面，这样偷懒不想开发小程序的开发者就会把小程序跳转到网页，会降低小程序生态的质量。那如果加一个API黑名单，调用这些API就无效，不也能解决问题吗？但这样做的话，你需要一直去维护一个黑名单列表，因为说不准不时就更新一些新的“不安全”的API。

所以，基于以上几点，直接把JavaScript执行的逻辑层环境放到沙盒，一个纯JavaScript的执行环境，没有浏览器的概念，这样就没有DOM相关的API了，那小程序也得有页面啊，所以渲染层就单独开一个线程了。这就是双线程的由来。

小程序的运行环境

小程序的运行环境分成渲染层和逻辑层，其中 WXML 模板和 WXSS 样式工作在渲染层，JS 脚本工作在逻辑层。
小程序的渲染层和逻辑层分别由2个线程管理：渲染层的界面使用了WebView 进行渲染；逻辑层采用JsCore线程运行JS脚本。一个小程序存在多个界面，所以渲染层存在多个WebView线程，这两个线程的通信会经由微信客户端（下文中也会采用Native来代指微信客户端）做中转，逻辑层发送网络请求也经由Native转发，小程序的通信模型下图所示。

双线程通信

Virtual DOM：用JS对象模拟DOM树 -> 比较两棵虚拟DOM树的差异 -> 把差异应用到真正的DOM树上。

1. 在渲染层把 WXML 转化成对应的 JS 对象。
2. 在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。
3. 经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。

小程序的基础库

小程序的基础库是 JavaScript 编写的，它可以被注入到渲染层和逻辑层运行。主要用于：

• 在渲染层，提供各类组件来组建界面的元素
• 在逻辑层，提供各类 ==API ==来处理各种逻辑
• 处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑
  由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。这样可以：
• 降低业务小程序的代码包大小
• 可以单独修复基础库中的 Bug，无需修改到业务小程序的代码包
  Exparser 框架
  Exparser 是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各种组件提供基础的支持。小程序内的所有组件，包括内置组件和自定义组件，都由 Exparser 组织管理。Exparser 特点包括：

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

参考资料：

小程序的底层框架
native APP，hybrid APP和web APP
小程序为什么要使用双线程模型
小程序实现原理解析