简单说说微信小程序的底层原理

小程序选择了 Hybrid 的渲染方式，将UI渲染跟 JavaScript 的脚本执行分在了两个线程。

双线程模型

小程序的渲染层和逻辑层分别由两个线程管理：

• 渲染层：界面渲染相关的任务全都在 WebView 线程里执行。一个小程序存在多个界面，因此渲染层存在多个WebView 线程。
• 逻辑层：采用JsCore 线程运行JS脚本，在这个环境下执行的都是有关小程序业务逻辑的代码。

双线程之间的通讯

咱们都知道小程序是避免DOM操做，而是采用数据驱动来渲染页面的，那么他究竟是怎么经过更改数据来更新DOM呢。

逻辑层和渲染层的通讯会由 Native （微信客户端）作中转，逻辑层发送网络请求也经由 Native 转发。经过把 WXML 转化为数据，经过 Native 进行转发，来实现逻辑层和渲染层的交互和通讯。

1. 在渲染层会把WNML转化成Js对象，Js对象会模拟DOM树
2. 逻辑层更新数据的时候，经过setData方法将数据从逻辑层转发到Native,Native再转发到渲染层
3. 这时候，比较两虚拟DOM树的差别，最后将差别应用到真实DOM树上，更新页面。

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

小程序的生命周期

小程序的生命周期借鉴了Android的生命周期，若是你了解过Android的APP开发，那么理解小程序的就会很简单。

界面线程有四大状态：

• 初始化状态：初始化界面线程所须要的工做，包括工做机制，基本和咱们开发者没有关系，等初始化完毕就向“服务线程”发送初始化完毕信号，而后进入等待传回初始化数据状态。

• 首次渲染状态：收到“服务线程”发来的初始化数据后（就是 json和js中的data数据），就开始渲染小程序界面，渲染完毕后，发送“首次渲染完毕信号”给服务线程，并将页面展现给用户。

• 持续渲染状态：此时界面线程继续一直等待“服务线程”经过this.setdata（）函数发送来的界面数据，只要收到就从新局部渲染，也所以只要更新数据并发送信号，界面就自动更新。

• 结束状态：结束渲染。

服务线程五大状态：

• 初始化状态：无需和其余模块交流，跟小程序开发也没多大关联，此阶段就是启动服务线程所需的基本功能，好比信号发送模块。系统的初始化工做完毕，就调用自定义的onload和onshow， 而后等待界面线程的“界面线程初始化完成”信号。

onload是只会首次渲染的时候执行一次，onshow是每次界面切换都会执行，简单理解，这就是惟一差异。

• 等待激活状态：接收到“界面线程初始化完成”信号后，将初始化数据发送给“界面线程”，等待界面线程完成初次渲染。

• 激活状态：收到界面线程发送来的“首次渲染完成”信号后，就进入激活状态既程序的正常运行状态，并调用自定义的onReady()函数。

此状态下就能够经过 this.setData 函数发送界面数据给界面线程进行局部渲染，更新页面。

• 后台运行状态：若是界面进入后台，服务线程就进入后台运行状态，从目前的官方解读来讲，这个状态挺奇怪的，和激活状态是相同的，也能够经过setdata函数更新界面的。毕竟小程序的框架刚推出，应该后续会有很大不一样吧。

运行机制

启动

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

销毁

只有当小程序进入后台必定时间，或者系统资源占用太高，才会被真正的销毁。

更新机制

开发者在后台发布新版本以后，没法马上影响到全部现网用户，但最差状况下，也在发布以后 24 小时以内下发新版本信息到用户。

小程序每次冷启动时，都会检查是否有更新版本，若是发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序须要等下一次冷启动才会应用上。

因此若是想让用户使用最新版本的小程序，能够利用 wx.getUpdateManager 作个检查更新的功能