微信小程序的整体架构图，你值得拥有！！
发表时间：2023-11-04 07:15:16
文章来源：炫佑科技
浏览次数：226
菏泽炫佑科技 菏泽炫佑小程序开发 菏泽炫佑app制作 炫佑科技
微信小程序的整体架构图，你值得拥有！！
万事开头难，所以发一张图以示诚意。
这张图是微信小程序的整体架构图。 具体的分析会在下面的整体架构中进行讲解。 主要是给你心里留下一个印象。 现在就让我们开始本文的快乐之旅吧。 (=^▽^=)
发展原点
我们先简单说一下微信小程序的发展历史。 只有知己知彼，才能百战百胜。 微信小程序简称小程序。 张小龙于2017年1月9日在微信公开课上宣布正式上线。小程序英文名为Mini。 它是一个无需下载和安装即可使用的应用程序。 它实现了“触手可及”应用程序的梦想。 用户可以通过扫描或搜索的方式打开应用程序。
小程序自推出以来，就被称为便携版APP。 两者的区别在于，小程序相对轻量级，开发成本低，开发周期短，见效快。
小程序并不是一个凭空出现的概念。 当微信逐渐成为移动Web的重要入口时，微信就有了相关的JS API。
是移动终端（手机、iPad）提供的运行环境。 它是系统渲染网页的一个控件。 可以与页面交互，实现APP和Web混合开发。 渲染网页需要强大的渲染内核支持，这与IOS有关。 系统的内核不同。
据我了解，小程序诞生的主要推动力是微信移动网页的沟通体验差、能力弱。 当然，我认为这也是原生APP的缺点所驱动的微信小程序的整体架构图，你值得拥有！！，比如每次都要从App Store或者其他应用程序下载。 市场下载，即使下载了，也会占用系统大量空间。 如果不经常使用，被用户删除的可能性就很大。
我们暂时先把原生APP的问题放在一边。 至于微信通讯体验差、移动网页能力弱的问题，尽管微信团队后来推出了 JS-SDK 来解决移动网页能力不足的问题，但 JS-SDK 的模式并没有解决微信移动网页能力不足的问题。使用移动网页时体验不佳。 原因可以概括为三点：白屏问题、页面切换僵硬、点击滞后。
为了解决这些问题，微信团队面临的问题是如何设计更好的系统，让所有开发都能在微信中获得更好的体验。 这个问题是之前的JS-SDK无法处理的，需要一个全新的系统来解决。 它需要使所有开发能够执行以下操作：
这就是小程序的由来。
宿主环境
微信小程序的托管环境是微信客户端，依赖于微信客户端运行，与小程序的基础库版本有很大关系。
我们可以将微信客户端和小程序的基础库作为微信小程序的托管环境。
微信小程序可以调用宿主环境提供的微信客户端的能力微信小程序开发原理，可以完成很多普通网页无法完成的功能。 这使得小程序比普通网页拥有更多的能力。 小程序会运行在不同版本的宿主环境中（不同的微信客户端+不同的基础库），因此各个版本的宿主环境的程序兼容性是不可避免的。
执行环境
小程序的主要开发语言是，与传统的Web开发类似，但还是有一定的区别：
微信小程序运行在多个平台：iOS（/iPad）微信客户端、微信客户端、PC微信客户端、Mac微信客户端以及用于调试的微信开发工具。
每个平台的脚本执行环境以及用于渲染非原生组件的环境都不同。 具体区别如下：
运行环境 逻辑层 渲染层
V8
自主研发的Xweb引擎，基于
iOS系统
开发工具
西北.js
电脑版()
核心
核心
苹果
不知道大家看到这里有没有什么疑问呢？ （T_T）
呃……写到这里，我对上面这句话“逻辑层跑进来”有些疑问。 思路的具体解释在下面的目录中，可以在下面查看。
小程序整体结构
通过以上内容，大家应该对小程序的诞生和环境有了一个大概的了解。 现在我们来说一下小程序的整体设计结构。
整个小程序系统架构分为两部分：视图层（）和逻辑层（App）。 这两部分由两个独立的线程管理。
视图层和逻辑层之间的通信需要使用系统层（）。 逻辑层将数据变化通知视图层，并触发视图层的页面更新。 视图层将触发的事件通知给逻辑层进行业务逻辑处理。
页面渲染的大致流程是：我们在编译项目的时候，会将WXML转换成对应的JS对象（DOM）。 当逻辑层数据发生变化时，我们会通过()方法将数据从逻辑层传递到视图层。 view层接收到数据后，会在内部比较差异，将差异应用到原始Dom树上，然后正确渲染UI界面，完成页面渲染过程。
通过上面的分析，你能看懂一开始放的架构图了吗？ (-^〇^-)
上面的分析还提到了一个系统层（），一般简称为“系统层”，它起到了中间桥梁的作用，非常重要。 它不仅允许视图层和逻辑层两个独立的线程进行通信，而且在上层开发和底层系统功能之间架起了一座桥梁（），允许小程序通过调用API来使用原生功能，以及一些组件是用原生组件实现的。 所以要有一个好的体验。
逻辑层还有一个重要的操作，发送网络请求，这些请求也是通过系统层转发的。
说了这么多，希望大家对小程序的整体结构有了一定的了解。 我们先来说说小程序的一些内部机制。
运行机制
小程序启动运行时有两种情况：
需要注意：
1、没有重启小程序的概念。
2、当小程序进入后台时，客户端会维持一段时间的运行状态，一定时间后会被微信主动销毁。
3、如果短时间内收到系统两次以上的内存警告，小程序也会被销毁。 这就是页面内存一旦溢出就会崩溃的本质原因。
更新机制
如果冷启动时发现小程序有新版本，则会异步下载新版本包，并先使用客户端本地的旧包启动，直到下次启动时才会应用冷启动。 如果需要立即应用*新版本，可以使用wx. API 来处理它。
const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
// 请求完新版本信息的回调
console.log(res.hasUpdate)
})
updateManager.onUpdateReady(function () {
wx.showModal({
title: '更新提示',
content: '新版本已经准备好，是否重启应用？',
success(res) {
if (res.confirm) {
// 新的版本已经下载好，调用 applyUpdate 应用新版本并重启
updateManager.applyUpdate()
}
}
})
})
updateManager.onUpdateFailed(function () {
// 新版本下载失败
})
数据通讯机制
前面我们提到小程序是基于双线程的，这意味着视图层和逻辑层之间的任何数据传输都是线程之间的通信，这意味着会有一定的延迟。 这不像传统的Web，当页面需要更新时，可以通过调用相关API来同步渲染。 在小程序架构中，这一切都是异步操作。
异步会使各部分的运行时间变得更加复杂。 例如，在渲染首屏时，逻辑层和渲染层会同时开始初始化工作，但渲染层需要逻辑层的数据来渲染界面。 如果渲染层初始化工作很快完成，就必须等待逻辑层的指令。 只有这样我们才能进行下一步。 因此，逻辑层和渲染层需要一定的机制来保证正确的时序。 每个小程序页面的生命周期内，都会有多次页面数据通信。
了解了视图层和逻辑层之间的具体通信流程之后，我们对视图层和逻辑层之间的数据传输也有了一点了解。 我们知道两者之间的通信依赖于系统层，但实际上是通过双方进行的。 提供的东西就实现了。 即用户传输的数据需要转换成字符串进行传递。 同时将转换后的数据内容拼接成JS脚本，然后通过执行JS脚本传递到双方独立的环境中。
关于：
调用JS通常是直接的JS代码串，这有点类似于我们在JS中调用eval来执行一串代码。 一般有以下几种方法。
这里我就不做过多的介绍了。 你只需要记住它是用来调用和执行JS字符串的，它是一种识别JS代码的方式。
登录机制
做过小程序的人应该熟悉这张图：
图中的流程主要是获取微信用户的唯一身份。 然后开发服务器可以根据用户ID生成自定义的登录状态，用于后续业务逻辑中前后端交互时识别用户的身份。
调用wx.login()获取临时登录凭证代码并发回开发服务器。 调用授权。 接口换取用户唯一标识、用户在微信开放平台账号下的唯一标识（如果当前小程序已绑定微信开放平台账号）和会话密钥。 机制说明
这是微信不久前新增的功能。 其获取方法类似，功能也类似。 它们都指的是用户的唯一标识符，但其范围更广。
官方解释：如果开发拥有多个移动应用、网站应用、公众号（包括小程序），可以通过公众号（包括小程序）对用户唯一来区分用户的唯一性。 也就是说，同一个用户在同一个微信开放平台下，对不同应用的访问权限是相同的。
不知道吗？ 说白了，小程序绑定微信开放平台账号后，可以与该账号绑定的其他移动应用、网站应用、公众账号进行对接。 例如：同一用户在PC上扫描登录，对微信公众号开发页面进行授权，对微信小程序进行授权。 在这些场景中，可以识别相同的用户并获得相同的信息。
性能问题
了解小程序的架构原理后，我们从底层架构的角度简单分析一下常见的小程序性能问题是如何产生的。
频繁调用()
频繁调用()相信是一个很常见的问题，比如在定时器中调用它，或者在监视页面滚动的钩子中调用它。 这些场景很容易造成小程序性能问题，很容易出现页面卡顿、页面卡顿等情况。 数据更新不及时。
前面我们在数据通信机制中提到，小程序是基于双线程的，这意味着视图层和逻辑层之间的任何数据传输都是线程之间的通信。 频繁调用()会导致线程一直处于忙碌状态，逻辑层通知视图层所花费的时间会增加。 当视图层收到消息时，可能距离发送已经超过一定时间，渲染页面就会不够及时。
数据量巨大需要调用()
还是在前面的数据通信机制中，我们说过传输的数据需要转换成字符串，然后以JS脚本的形式执行。 当数据量较大时，执行脚本的编译和执行时间也会增加。 ，占用线程。
页面复杂的DOM结构
当页面的DOM结构复杂且非常庞大时，这必然会导致页面显示延迟、页面卡顿，甚至页面崩溃。 可以想象，造成这种情况的原因是过多的DOM绘制和计算。 它们都需要时间，这会导致线程过渡工作并增加客户端内存使用量，从而触发系统回收小程序页面。
上面我提到我对“逻辑层运行于”这句话有一些疑问，因为我看到表中列出的逻辑层运行的环境应该由系统环境来区分。 那么这句话是不是太笼统了？ 还是这句话指的是IOS的情况？ 因为是官方文档写的，所以我并没有因为写错而直接拒绝，或者只是参考了IOS的情况。
经过一番核实，确认这句话其实没有问题。 为了追踪结果过程，我们需要写一下浏览器的大概情况：
浏览器的核心部分是浏览器内核。 每个浏览器都有自己的内核，也是对移动领域影响*深远的浏览器。
它是一个页面渲染和逻辑处理引擎。 HTML/CSS/经过它的处理，成为可见可操作的网页。
它由多个重要模块组成。 整体结构如下：
它由四个部分组成，即：
让我们重点关注默认嵌入的 JS 引擎部分。 之所以称为默认嵌入，是因为很多基于分支开发浏览器引擎都开发自己的JS引擎，其中*著名的就是V8引擎。
相信前端朋友对V8引擎一定不会陌生。 由于是基于V8的，所以底层也默认嵌入，V8的逻辑层运行在V8上。
IOS的浏览器引擎是内部的。
*后，开发工具的逻辑层运行在NW.js上。 去它的官网看看这段话：
我相信这与它有关。
既然我们对这个问题有了一定的了解，小编就不多说了，就此结束。 (-^〇^-)
至此，这篇文章就结束了，让我们来献花吧。
我希望这篇文章对您有所帮助。 如果您有任何疑问，期待您的留言。
