李艺《微信小程序全栈开发实战》（第一章）

双线程运行机制

逻辑层和视图层通过微信底层的weixinJSBridge进行通信，小程序代码中使用的setData改变视图绑定的数据在底层对应执行的是evaluateJavascript这个函数，当视图层的交互触发了，由视图层像逻辑层传递信息时，也是通过这个函数进行的。这个函数的参数时文本，每次调用都需要进行原始类型->文本->原始类型这一系列的转化，并且还是单通道的，不存在像c++、Golang那样的并发线程特征，所以它的效果时非常差的。

小程序的特点及开发能力

小程序的特点

小程序的开发能力

基于安全考虑，小程序中不支持动态执行 JS 代码，即：
不支持使用 eval 执行 JS 代码
不支持使用 new Function 创建函数

开发小程序的一般流程

小程序的运行机制

微信小程序相当与运行在特定机制下的Hybird技术。
小程序的启动机制

• 热启动： 用户已经打开过某个小程序，在一定时间内再次打开，小程序只是从后台到前台
• 冷启动：小程序首次打开，或者被微信销毁之后再次打开，此时小程序需要重新加载并启动
  注意：什么时候可以应用新的版本呢？小程序在冷启动时会检查是否有更新的代码包，并且异步下载新的代码包，并且同时用客户端本地的代码包进行启动，及新版本的小程序要等下一次冷启动时才会用上。如果想马上用上新的版本，可以用wx.getUpdateManager进行处理。
  
  小程序销毁的情况：
• 在后台运行超过一定时间（五分钟左右）
• 当短时间内（一般是五秒）连续两次收到内存的警告，此时用户会收到警告（运行内存不足，请重新打开该小程序，这对用户非常的不友好，可以使用wx.onMemoryWarning来进行内存监听）

小程序双线程

视图层和逻辑层通过weixinJSBridge和native底层进行通信。在event和data的交互处理上，逻辑层把变化通知到视图层，触发视图层的更新，视图层再把触发的事件通知到逻辑层进行业务逻辑的处理。

视图的持续更新是如何实现的

简单的说这个问题是通过setdata实现的，看一下在hybird中是如何执行js代码的：

setdata要求更新的数据首先会会将这些数据转换为字符串，接着将字符串与代码拼接成一个javascript脚本，最后将拼接的内容传递给一个evaluateJvascript原生方法，然后去执行。
小程序在视图更新上也做了一些虚拟dom的优化，所以从数据到达视图层的更新并不是实时进行的。

使用setData可能会遇到哪些问题

由于视图线程和逻辑线程分属于两个线程，两个线程通过前置的setData驱动着的数据交换还要通过weixinJsBridge进行中转，这个中转的效率是及其低下的，所以有时候安卓的用户在界面滑动时会感受到页面的卡顿。这是因为视图层一直在尝试渲染，逻辑层发来的更新请求被阻塞了，当这种阻塞达到200毫秒以上时，视图渲染便会产生卡顿。
卡顿不仅和更新的频率有关和更新的数据量也有关系，当使用setData更新大列表数据，或者更新一个很大的size的图片时，也容易产生卡顿。
在ios系统上，小程序的页面是由多个WKWebView组成的，在系统内存紧张时，一步分的WKWebView会被系统回收掉，也就是曾经打开的小程序页面成为了无法回退。

微信为什么要打造一个WXS语言

WXS（WeiXin Script）是小程序的一套脚本语言，结合 WXML，可以构建出页面的结构。
WXS 与 JavaScript 是不同的语言，有自己的语法，并不和 JavaScript 一致。
WXS不依赖于运行时的基础库版本，可以在所有版本的小程序中运行。
看一下wxs的试例：

<wxs module="foo">
var some_msg = "hello world";
module.exports = {
  msg : some_msg,
}
</wxs>
<view> {{foo.msg}} </view>

微信团队声称wxs在小程序中会比js快1-20倍，这是因为wxs虽然也是js代码，但是它不运行在小程序的逻辑线程之内，而是运行在视图线程之内，它直接操作视图数据，避免了跨线程的通讯开销。
正是因为小程序的双线程架构在数据更新上有瓶颈，所以微信团队才打造了一个wsx视图脚本，虽然它有很多优点，但是也有非常多的缺点：

• wsx运行环境和其他js代码时隔离的，它不能调用其他js代码提供的函数，也不能调用微信提供的wx开头的api接口
  -wsx函数不能作为视图模板中的事件回调句柄（它所定义的函数无法作为事件句柄绑定在组件上的）
• wsx在ios上比js快1-20倍，但是在安卓机上两者是没有任何差异的

视图线程

wcc是wxml编译器，用于将wxml代码编译为js代码。wcsc是wxss编译器，负责将wxss代码编译为js代码。小程序的视图层是在polymer框架基础之上基于web component标准实现的。
在编译完成之后会在内存中创建一个虚拟的dom，使用虚拟dom是为了实现视图的渲染效率。相较而言，vue也是在web component之上实现了虚拟dom，vue将模板中的每个节点都解析为web component一个node节点，即使是一个简单的变量文本的绑定，也解析为一个独立的节点。这样在数据更新的时候，更新的是节点的文本，这些与小程序一致。
比vue更进一步的是小程序除了一般视图组件，还有原生组件，小程序将视图组件放在下面，将解析之后的原生组件放在一般组件的上面。我们在开发时要注意这一点，原生组件永远放在一般组件之上。

逻辑线程

小程序页面启动时，首先触发的是onLoad和onShow事件。当视图初始化加载完成之后，notify通知逻辑线程组件已经准备好，接着逻辑线程将初始化的data数据发给视图线程，由视图线程渲染，视图进入渲染。
完成首次渲染之后，视图通知逻辑线程渲染完成，派发onReady事件，监听到这个事件，说明页面可以交互了，此时视图进行持续渲染状态。在运行过程中，如果用户输入了事件，会触发逻辑线程的事件函数，事件函数执行后可能会向setData发送数据，由视图线程更新。
当用户进入到别的小程序时，当前页面进入后台状态， 此时逻辑线程派发onHide事件，当页面由后台切入到前台时，又会派发onShow事件。如果页面被销毁，就会派发onUnLoad事件。

总结

小程序采用双线程架构，一个负责页面的渲染、一个负责业务逻辑的处理，两个线程通过weixinJsBridge与微信Native底层进行通讯，包括两者这件进行的事件与数据的交换也是通过它完成的。所有平台能力、硬件能力，也是通过weixinJsBridge间接提供的。
由于微信小程序setData在频繁更新和大数据更新上由瓶颈，所以引入了wxs编程语言。一般的处理方式是这样的，从后台接收回来的数据，在页面onLoad之前就塞在Data数据之中，用于视图的初始化渲染，后续的视图交互与更新，如果不与后台有关，就使用 wxs编程语言直接在视图中完成渲染，这样可以提高渲染效率。