微信小程序架构原理基础解析****

发展由来****

我们先来简单讲讲微信小程序的发展历，知己知彼方能百战不殆。微信小程序简称小程序。张小龙于2017年01月09日在微信公开课上宣布其正式上线。小程序英文名为 Mini Program，是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开应用。

小程序上线以来，一直被称为便携版的 APP，关于两者之间的区别，无外乎是小程序相对轻便、开发成本低、开发周期短、收效快。

小程序并非凭空冒出来的一个概念，当微信中的 WebView 逐渐成为移动 Web 的一个重要入口时，微信就有相关的 JS API 了。

WebView 是移动端（手机、IPad）提供的运行 JavaScript 的环境，是系统渲染 Web 网页的一个控件，可与页面 JavaScript 交互，实现 APP 与 Web 的混合开发，WebView 渲染 Web 页面需要强大的渲染内核支持，这其中 Android 与 IOS 系统的内核又有所不一样。

根据了解，小程序诞生的背景主要推动力是由于移动网页在微信内传播体验不良，能力不强，当然我觉得这其中也有原生 APP 缺点原因的推动，比如每次都要从 App Store 或者其他应用市场下载，即使下载了，也占据系统很大的空间，如果不经常用，被用户删掉的可能性也非常大。

我们先抛开原生APP的问题不谈，对于移动网页在微信内传播体验不良，能力不强的问题，即使后来微信团队推出了 JS-SDK 来解决移动网页能力不足的问题，但 JS-SDK 的模式并没有解决使用移动网页遇到的体验不良的问题，这其中的原因大概能概括为这三个点：白屏问题、页面切换的生硬和点击的迟滞感。

为了解决这些问题，微信团队面临的问题是如何设计一个比较好的系统，使得所有开发者在微信中都能获得比较好的体验。这个问题是之前的 JS-SDK 所处理不了的，需要一个全新的系统来完成，它需要使得所有的开发者都能做到：

· 快速的加载。

· 更强大的能力。

· 原生的体验。

· 易用且安全的微信数据开放。

· 高效和简单的开发。

这就是小程序的由来。文档

宿主环境****

微信小程序的宿主环境为微信客户端，它是依赖于微信客户端上运行的，并且跟小程序基础库版本有重大关联关系。

我们可以把 微信客户端 以及 小程序基础库 简称为微信小程序的宿主环境。

微信小程序可以调用宿主环境提供的微信客户端的能力，可以完成许多普通网页无法完成的功能，这就使得小程序比普通网页拥有更多的能力。小程序会运行在不同版本（不同的微信客户端+不同基础库）的宿主环境下，因此针对各个版本的宿主环境做程序上的兼容也是在所难免的。

执行环境****

小程序的主要开发语言是 Javascript，它与传统网页开发具有相似性但还是有一定区别：

· 网页开发，渲染线程和脚本是互斥的，这也是为什么长时间的脚本运行可能会导致页面失去响应的原因，本质就是我们常说的 JS 是单线程的。

· 小程序，视图层和逻辑层是分开的，双线程同时运行，视图层的界面使用 WebView 进行渲染，逻辑层运行在 JSCore 中。

· 网页开发，主要面对各厂商的浏览器，在移动端还需要面对 Safari、Chrome 以及 iOS、Android 系统中的各式 WebView。

· 小程序，主要面对两大操作系统IOS和Android的微信客户端，还有开发工具、PC端（window）、Mac。开发时候需要注意的是微信客户端的版本号和小程序API 支持的基础库版本号。

微信小程序运行在多种平台上：iOS（iPhone/iPad）微信客户端、Android 微信客户端、PC 微信客户端、Mac 微信客户端和用于调试的微信开发者工具

小程序整体架构****

整个小程序系统构架分成两个部分：视图层(WebView) 和逻辑层(App Service)，这两个部分分别由两个独立线程管理。

· 视图层：也称为渲染层，渲染层用来渲染页面结构，主要由 WebView 进行渲染，一个小程序可以存在多个界面，所以渲染层可能存在多个 WebView 线程。

· 逻辑层：逻辑层采用 JSCore 线程运行 JS 脚本。逻辑层主要用来逻辑处理、数据请求、接口调用等。

视图层和逻辑层之间的沟通则需要借助系统层(WeixinJsBridage) 进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务逻辑处理。

运行机制****

小程序启动运行两种情况：

· 冷启动（重新开始）：用户首次打开或者小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动，即为冷启动。

· 热启动：用户已经打开过小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需要将后台态的小程序切换到前台，这个过程就是热启动。

更新机制****

小程序冷启动时如果发现有新版本，将会异步下载新版本的包，并同时会先用客户端本地的旧包进行启动，等下次冷启动才会应用上。如果需要马上应用最新版本，可以用 wx.getUpdateManager API 进行处理。

数据通信机制****

小程序是基于双线程的，那就意味着任何在视图层和逻辑层之间的数据传递都是线程间的通信，也就是会有一定的延时。这不像传统Web一样，当页面要更新时调用相关API就能同步渲染出来，在小程序架构里面，这一切成了异步操作。

异步会使得各部分的运行时序变得复杂一些。比如在渲染首屏的时候，逻辑层与渲染层会同时开始初始化工作，但是渲染层需要有逻辑层的数据才能把界面渲染出来，如果渲染层初始化工作较快完成，就要等逻辑层的指令才能进行下一步工作。因此逻辑层与渲染层需要有一定的机制保证时序正确，在每个小程序页面的生命周期中，存在着若干次页面数据通信。

登录机制****

1. 调用 wx.login() 获取临时登录凭证 code，并回传到开发者服务器。

2. 调用 auth.code2Session 接口，换取用户唯一标识 openid 、用户在微信开放平台帐号下的唯一标识 UnionID（若当前小程序已绑定到微信开放平台帐号）和会话密钥 session_key。

性能问题

频繁调用setData()

频繁调用 setData()，这个问题相信已经是很常见的，比如在定时器中调用、在监听页面滚动的钩子中调用，这些场景很容易就会引起小程序的性能问题，容易出现页面卡顿、页面数据更新不及时的情况。

前面在数据通信机制中我们讲过小程序是基于双线程的，那就意味着任何在视图层和逻辑层之间的数据传递都是线程间的通信，频繁的去调用 setData()，会使得线程之间一直处于忙碌状态，逻辑层通知到视图层耗时就会上升，视图层收到消息的时候可能已经距离发出的时间超过一定时间了，渲染页面就不够及时了。

庞大的数据量去调用setData()****

还是在前面的数据通信机制中，我们说过传输的数据需要转换成转换为字符串的形式传递，且通过 JS 脚本的形式去执行，当数据量大时，执行脚本的编译执行时间也会上涨，占用线程。

页面复杂繁多的DOM结构****

当一个页面 DOM 结构复杂并且非常多的时候，这必定带来页面显示不及时，页面卡顿，甚至可能会出现页面奔溃的情况，这其中的原因可想而知，是过于 DOM 绘制、计算都是需要时间的，这将使得线程过渡的工作，带来客户端内存占用上升，从而触发系统回收小程序页面。

微信框架解析