【微信小程序】两大线程与微信WXS

选型：渲染界面的技术

纯客户端原生渲染 缺点：无法动态打包，动态下发。
纯Web技术来渲染 缺点：在一些复杂交互的页面上可能会面临一些性能问题。
同时，在Web技术中，UI渲染跟JavaScript脚本执行都是在一个单线程中执行，容易导致抢占资源。
客户端原生 + Web 优点：
界面主要由成熟的Web技术来渲染，辅之以大量的接口提供丰富的客户端原生能力。
同时，每个小程序页面都是用不同的WebView来渲染，更贴近原生体验，避免单个WebView任务过于繁重。

选型：脚本执行的环境

由于JavaScript的灵活性和浏览器的功能丰富，会导致很多不可控的隐私，因此，微信提供了一个单纯的JS执行环境。
通过对其中的控件进行自定义，保证了采用这个沙箱环境之后，不会有任何浏览器相关的接口，没有BOM和DOM对象。
考虑到小程序是一个多WebView架构，每个页面都是由不同的WebView渲染后显示的，
在这个架构下，我们不好去用某个WebView中的ServiceWorker去管理所有的小程序页面。
得益于客户端具有的JS解释引擎，可以创建一个单独的线程去执行JS，在这个环境下执行的都是有关小程序业务逻辑的代码。

这就是小程序双线程（渲染层+逻辑层）模型的由来。

双线程模型

小程序的运行环境分为视图层（View Thread）和逻辑层（Appservice Thread），其中：

• 视图层：WXML页面文件、WXSS样式
• 逻辑层：JS代码

这样分离设计的好处是逻辑层和视图层会同时进行、并行加载（非阻塞）。
当视图线程加载完，通知逻辑层准备好了，然后逻辑层会把准备好的数据用setData方法发送给视图线程。（对应页面生命周期中 Send Initial Data）


这种好处不可避免地带来了一些副作用：
无法操作DOM，数据更新和事件操作只能靠进程通信，但跨进程通信成本较高。
这两个线程的通信会经由微信客户端（Native）做中转，逻辑层发送网络请求也经由Native转发。

WXS诞生

WXS（即Weixin Script）的出现增强了WXML的功能，可以把它理解为WXML页面的脚本。

单例模式

WXS 可以写在WXML文件中的标签内（如wx:if等），或者是以 .wxs为后缀的文件内。
WXS 模块都为单例，模块第一次被引用时，会自动初始化为单例对象，多个页面多个地方多次引用，使用的都是同一个模块对象。若WXS在定义后一直没有被引用，那么该模块不会被解析运行。

适用场景

1）用户交互频繁、仅需改动组件样式（比如布局位置），无需改动数据内容的场景（比如侧滑菜单、索引列表、滚动渐变等）
2）数据格式处理，比如文本、日期格式化、filter过滤器。

隔离特性

WXS 只具有被微信官方赋予的功能，与逻辑层是隔离的，没有逻辑层的“特权”。
WXS 是阉割版的JS，运行在WebView中的JS线程，不能调用其他JS文件中定义的函数，也不能调用小程序提供的API。

tip：小程序并非凭空冒出来的一个概念。当微信中的WebView逐渐成为移动Web的一个重要入口时，微信就有相关的JS API了。2015年初，微信发布了一整套网页开发工具包，称之为 JS-SDK，开放了拍摄、录音、地图、支付、分享等几十个API。JS-SDK是对之前的WeixinJSBridge的一个包装，以及新能力的释放。然而JS-SDK并没有解决使用移动端网页遇到的体验不良的问题（开始显示前都有个白屏的过程），因此后来有了JS-SDK增强版本（微信Web资源离线存储）。