微信小程序全栈开发实战学习二（小程序运行机制简介从零构建一个WebApp需要做哪些事情？）

小程序的启动分两种情况，冷启动和热启动

小程序的三种启动方式

1.首次打开小程序，从微信云端下载小程序代码包，并且运行（冷启动）
2.最近启动过小程序，再打开一次小程序会直接从后台切换到前台（热启动）
3.长时间没有运行，被微信主动销毁，再次打开，从缓存读取代码包，同时从微信云端检查版本更新（冷启动）
ps:也就是说小程序更新版本要等到冷启动，如果想立刻更新，我们可以使用wx.getUpdateManager

小程序被主动销毁情况

1. 后台运行五分钟就会被销毁
2. 短时间内5s内连续收到两次系统内存警告，就会被销毁
   ps：监听内存报警事件可以使用wx.onMemoryWarning接口

小程序的两种状态

前台状态和后台状态
当用户关闭小程序或者按了home键，其实小程序还可以运行一段时间，进入了后台状态
再次打开就会从后台进入前台，这是小程序的热启动机制，相当于浏览器打开标签切换

小程序的双线程架构

为了安全和管控，小程序使用双线程执行：视图线程和逻辑线程

1. View视图线程，提供各类组件，渲染界面
2. App Service逻辑线程

两者都是通过微信底层的WeixinJSBrindge实现的

小程序的运行原理

1.小程序视图的持续更新是怎么实现的？
简单来说是通过setData实现的

如图所示，这是Hybird执行js的一段代码，webView通过调用evaluateJavascript执行一个js方法，并且执行以后还可以得到js代码返回的内容。
小程序里面setData也是通过evaluateJavascript方法实现的，视图层和逻辑层的数据传输，实际上都是通过底层的WeixinJSBridge通过原生的evaluateJavascript实现的，setData要求更新的数据，首先会将数据转化为字符串，接着将字符串与代码拼接成一个javascript脚本，最后把拼接的内容传给evaluateJavascript，然后执行。

2.使用setData有什么问题？
因为视图线程和逻辑线程是两个线程，而且setData还要通过WeixinJSBridge进行中转，效率很低，所以Android用户在界面滑动的时候会感觉页面卡顿，因为视图线程一直在渲染，逻辑层发来的更新请求就阻塞了。阻塞>=200毫秒时，视图渲染就会卡顿，卡顿与更新频率，更新数据量都有关系。
ios上，小程序页面是由多个WKWebView组成的，在系统内存紧张时，一部分WKWebView会被系统回收，也就是说，一部分页面无法回退。

3.微信为什么要造一个wxs？
微信打造的一套脚本语言，结合wxml可以构建出页面的组件结构，与js不同。
由于setData在频繁更新和大数据更新上有瓶颈，影响渲染效率，所以微信引用了wxs。
使用WXS也是有缺陷的

1. WXS运行环境与其他JS代码是隔离的。
2. WXS函数不能作为视图模板中的事件回调句柄。
3. WXS在IOS设备上比JS快2-20倍。在Android 上效率没有差异。

4.视图线程编译图

5.逻辑线程生命状态图

小程序启动时，首先触发的是onLoad和onShow。
视图初始化装载完成以后，notify通知逻辑线程组件已经准备好，接着逻辑线程将初始化的Data数据发给视图线程，进入渲染状态，完成首次渲染以后，视图线程通知逻辑线程，派发onready事件，此时代表页面可以交互了。视图进入持续渲染状态。
页面在后台运行时会触发onHide事件，页面切换到前台就会触发onShow事件，页面被销毁就会触发onUnload。

6.逻辑线程的四个状态

1. 初始化状态
   启动服务线程所需的基本功能，系统的初始化完毕，调用onLoad和onShow,等待界面线程的初始化完成，onLoad首次进入页面运行，onshow是每次界面切换的时候都会触发
2. 等待激活状态
   接收到视图线程初始化完成信号，将初始化数据发送给视图线程，等待界面线程完成初次渲染。
3. 激活状态
   收到界面线程发送来的首次渲染完成信号后，就进入激活状态，调用自定义的onReady函数。
   4.后台运行状态