微信小程序底层原理剖析
最近公司开发了好几款微信小程序，今天就做一些简单的原理分析，我们开始吧！
从两大线程说开
小程序由两大线程组成：负责界面的线程（view thread）和服务线程（appservice thread），各司其职由互相配合。两个线程分别用于渲染层和逻辑层，渲染层的界面使用了 WebView 进行渲染，通过逻辑层代码去控制渲染哪些界面，如果一个小程序存在多个界面，则渲染层存在多个 WebView 线程；逻辑层采用一个单独的 JsCore 线程运行 JS 脚本，在这个环境下执行的都是有关小程序业务逻辑的代码。套用一张官方的图来解释。
为什么要这么设计呢？主要还是处于管控和安全上的考虑。我们需要阻止开发者使用一些浏览器提供的，诸如跳转页面、操作 DOM、动态执行脚本的开放性接口。
小程序的生命周期
小程序的生命周期借鉴了Android的生命周期，如果你了解过Android的APP开发，那么理解小程序的就会很简单。
界面线程有四大状态：
-
初始化状态：初始化界面线程所需要的工作，包括工作机制，基本和我们开发者没有关系，等初始化完毕就向“服务线程”发送初始化完毕信号，然后进入等待传回初始化数据状态。
-
首次渲染状态：收到“服务线程”发来的初始化数据后（就是 json和js中的data数据），就开始渲染小程序界面，渲染完毕后，发送“首次渲染完毕信号”给服务线程，并将页面展示给用户。
-
持续渲染状态：此时界面线程继续一直等待“服务线程”通过this.setdata（）函数发送来的界面数据，只要收到就重新局部渲染，也因此只要更新数据并发送信号，界面就自动更新。
-
结束状态：结束渲染。
服务线程五大状态：
- 初始化状态：无需和其他模块交流，跟小程序开发也没多大关联，此阶段就是启动服务线程所需的基本功能，比如信号发送模块。系统的初始化工作完毕，就调用自定义的onload和onshow，
然后等待界面线程的“界面线程初始化完成”信号。
onload是只会首次渲染的时候执行一次，onshow是每次界面切换都会执行，简单理解，这就是唯一差别。
-
等待激活状态：接收到“界面线程初始化完成”信号后，将初始化数据发送给“界面线程”，等待界面线程完成初次渲染。
-
激活状态：收到界面线程发送来的“首次渲染完成”信号后，就进入激活状态既程序的正常运行状态，并调用自定义的onReady()函数。
此状态下就可以通过 this.setData 函数发送界面数据给界面线程进行局部渲染，更新页面。
- 后台运行状态：如果界面进入后台，服务线程就进入后台运行状态，从目前的官方解读来说，这个状态挺奇怪的，和激活状态是相同的，也可以通过setdata函数更新界面的。毕竟小程序的框架刚推出，应该后续会有很大不同吧。
小程序双线程间的通信
把开发者的 JS 逻辑代码放到单独的线程去运行，但在 Webview 线程里，开发者就没法直接操作 DOM。那要怎么去实现动态更改界面呢？
前面我们知道，逻辑层和渲染层的通信会由 Native （微信客户端）做中转，逻辑层发送网络请求也经由 Native 转发。这是不是意味着，我们可以把 DOM 的更新通过简单的数据通信来实现呢？
Virtual DOM 相信大家都已有了解，大概是这么个过程：用JS对象模拟DOM树 -> 比较两棵虚拟DOM树的差异 -> 把差异应用到真正的DOM树上。
在这里我们可以用上，如图：
-
在渲染层把 WXML 转化成对应的 JS 对象。
-
在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。
-
经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。
我们通过把 WXML 转化为数据，通过 Native 进行转发，来实现逻辑层和渲染层的交互和通信。而这样完整的一套框架，基本上都是通过小程序的基础库来完成的。
小程序的基础组件
native层就是小程序的框架，就像常用的react框架一样，这个框架里封装了ui层组件和逻辑层组件，这些组件可以通过微信app提供的接口调用手机硬件信息
这些基础组件库是JavaScript编写的，它可以被注入到渲染层和逻辑层运行。主要用于：
-
在渲染层，提供各类组件来组件页面的元素
-
在逻辑层，提供各种API来处理各种元素。
-
处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑
由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。
如果需要学习更多的知识，请进入个人前端平台: http://uyi2.com