微信小程序架构基本原理详解（微信小程序的架构是b/s还是c/s）

这篇文章给大家带来了一些关于微信小程序的问题，主要介绍了关于基础设施原理的相关内容，包括主机环境、执行环境、小程序的整体架构、运行机制、更新机制、数据通信机制等。下面就一起来看看吧，希望能帮到你。

【相关学习推荐:小程序学习教程】

下图展示了微信小程序的整体架构:

发展起源我们先简单说说微信小程序的发展历史，这样才能知己知彼，百战不殆。微信小程序简称小程序。2017年1月9日，张小龙在微信公开课上宣布正式上线。小程序的英文名称是Mini Program，是一种无需下载和安装即可使用的应用程序。它实现了“触手可及”的梦想，用户可以通过扫描或搜索打开应用程序。

自小程序推出以来，它一直被称为APP的便携版。两者的区别在于小程序相对轻便，开发成本低，开发周期短，见效快。

小程序不是凭空出现的概念。当微信中的WebView逐渐成为移动Web的重要入口时，微信就有了相关的JS API。

据了解，小程序诞生的背景主要是由微信中的移动网页通信体验差和能力差所驱动的。当然，我认为这也是由原生应用的缺点所驱动的，例如每次都从应用商店或其他应用市场下载。即使下载了，它也会占用系统的大量空间。如果不经常使用，则极有可能被用户删除。

我们先抛开原生APP的问题。对于微信中存在的通信体验差、移动网页能力差的问题，即使微信团队后来推出了JS-SDK来解决移动网页能力不足的问题，但JS-SDK模式并没有解决移动网页使用体验差的问题。原因可以总结为这三点:白屏问题、页面切换生硬和点击延迟。

为了解决这些问题，微信团队面临的问题是如何设计一个更好的系统，使所有开发人员都能在微信中获得更好的体验。这个问题是以前的JS-SDK无法处理的，需要一个全新的系统来完成，这需要所有开发人员做到:

快速加载。

更强大的能力。

最初的体验。

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

高效简单的开发。

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

主机环境微信小程序的主机环境是微信客户端，它依赖于在微信客户端上运行，与小程序的基础库版本有着显著的关系。

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

微信小程序可以调用主机环境提供的微信客户端的能力，可以完成许多普通网页无法完成的功能，这使得小程序比普通网页拥有更多的能力。小程序将在不同版本的主机环境中运行（不同的微信客户端+不同的基础库），因此不可避免地要对每个版本的主机环境进行程序兼容。

执行环境小程序的主要开发语言是Javascript，与传统的网页开发类似，但仍有一些区别:

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

Applet、视图层和逻辑层分离，两个线程同时运行。视图层的界面由WebView渲染，逻辑层运行在JSCore中。

Web开发主要面对各个厂商的浏览器，在移动端还需要面对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）的帮助。逻辑层将数据变化通知视图层并触发视图层的页面更新，视图层将触发的事件通知逻辑层进行业务逻辑处理。

通过以上分析，你能理解放在开头的架构图吗？

上面的分析还提到了一个系统层（WeixinJsBridage），通常称为JSBridge，它扮演着中间桥的角色，非常重要。它不仅使视图层和逻辑层这两个独立的线程能够进行通信，而且在上层开发和系统的原生功能之间建立了一个桥梁，使小程序可以通过调用API来使用原生功能，并且一些组件是用原生组件实现的，因此具有良好的体验。

逻辑层还有一个重要操作，发送网络请求，这些请求也是通过系统层转发的。

讲到这里，希望大家对小程序的整体架构有一定的了解。先说小程序的一些内部机制。

运行机制小程序开始运行时有两种情况:

冷启动（重启）:当用户第一次打开它或小程序被微信主动销毁后再次打开时，小程序需要重新加载并启动，这是一种冷启动。

热启动:用户已经打开了小程序，然后在一定时间内再次打开。此时无需重启，只需将后台状态的小程序切换到前台即可。这个过程称为热启动。

需要注意的是:

1.小程序没有重启的概念。

2.小程序进入后台后，客户端会保持运行一段时间，过了一定时间后，就会被微信主动销毁。

3.如果短时间内收到系统内存警告超过两次，就会破坏小程序，这就是为什么一旦页面内存溢出，页面就会崩溃的本质原因。

如果在更新机制小程序的冷启动过程中发现新版本，将异步下载新版本的软件包，同时，它将与客户端的本地旧软件包一起启动，直到下次冷启动时才会应用。如果需要立即应用最新版本，可以使用wx.getUpdateManager API来处理。

const update manager = wx . getupdatemanager（）update manager . oncheckforupdate（function（RES）{//callback console . log（RES . has update）}）。update manager . onupdateready（function（）{ wx . show modal（{ title:& # 39；更新提示& # 39；，内容:& # 39；新版本已经准备好了。您想重新启动应用程序吗？'，success（RES）{ if（RES . confirm）{//新版本已下载。调用新版本的applyUpdate并重新启动UpdateManager。应用更新（）} }）}）更新管理器。on Update Failed（function（）{//新版本下载失败}）数据通信机制前面我们说过，小程序是基于双线程的，这意味着视图层和逻辑层之间的任何数据传输都是线程间通信，即会有一定的延迟。与传统的Web不同，当页面要更新时，可以通过调用相关的API来同步呈现。在小程序架构中，所有这些都变成了异步操作。

异步会使各部分的运行时序更加复杂。例如，在渲染第一个屏幕时，逻辑层和渲染层将同时开始初始化工作，但渲染层需要逻辑层的数据来渲染界面。如果渲染层的初始化工作很快完成，则需要等待逻辑层的指令才能进行下一步。因此，逻辑层和呈现层需要一定的机制来确保正确的时序。在每个小程序页面的生命周期中，都有多次页面数据通信。

在了解了视图层和逻辑层之间的具体通信过程后，我们也大致了解了视图层和逻辑层之间的数据传输是如何进行的。我们知道两层之间的通信是通过系统层的函数实现的，但实际上是通过双方提供的evaluateJavascript实现的。也就是说，用户传输的数据需要转换成字符串并传输，同时将转换后的数据内容拼接成JS脚本，然后通过执行JS脚本传输到双方独立的环境中。

关于evaluateJavascript:

原生调用JS，通常是直接的JS代码字符串，这有点类似于我们在JS中调用eval来执行一串代码。它一般有几种方法，如loadUrl、evaluateJavascript等。

这里就不做过多介绍了。你只需要记住它是用来调用和执行JS字符串的，这是Native用来识别JS代码的一种方式。

做过登录机制小程序的铁汁应该对这张图很熟悉:

图中的过程主要是获取微信用户唯一的openid和session_key，然后开发者服务器可以根据用户id生成自定义的登录状态，在后续的业务逻辑中进行前端交互时可以用来识别用户的身份。

调用wx.login（）获取临时登录凭证代码并将其返回给开发人员服务器。

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

UnionID机制显示，UnionID是微信不久前新添加的属性。其获取方式与openid类似，功能也类似。它是指用户的唯一标识，但其范围更广。

不明白？说白了，小程序绑定微信开放平台账号后，可以与账号下绑定的其他移动应用、网站应用和微信官方账号进行连接。例如，同一用户在PC上的扫描登录、微信官方账号开发的页面的授权登录、微信小程序的授权登录，这些场景下都可以识别同一用户，获得的UnionID是相同的。入口

性能问题在了解了小程序的架构原理之后，让我们从底层架构的角度简单分析一下常见的小程序性能问题是如何引起的。

经常调用setData（）。

频繁调用setData（），这个问题相信是非常常见的，例如在计时器中调用和在监视页面滚动的hook中调用。这些场景会容易造成小程序的性能问题，很容易出现页面卡顿、页面数据无法及时更新的情况。

在数据通信机制中，我们说过小程序基于两个线程，这意味着视图层和逻辑层之间的任何数据传输都是线程间通信。频繁调用setData（）会使线程一直处于繁忙状态，逻辑层通知视图层所需的时间也会增加。当视图层收到消息时，它可能已经发送了一段时间以上，并且呈现页面不够及时。

大量数据需要调用setData（）

在之前的数据通信机制中，我们说过传输的数据需要转换为字符串并以JS脚本的形式执行。当数据量很大时，执行脚本的编译和执行时间也会增加，从而占用线程。

页面复杂的DOM结构。

当一个页面的DOM结构复杂繁多时，必然会导致页面显示不及时、页面被卡住，甚至页面崩溃。其原因是绘制和计算过多的DOM需要时间，这会使线程过渡工作，导致客户端内存占用增加，从而触发系统回收小程序页面。

JSCore正如我上面提到的，我对“逻辑层在JSCore中运行”这句话有些怀疑，因为我看到表中列出的逻辑层的运行环境应该根据系统环境而有所区别。这句话太笼统了吗？还是这句话指的是IOS的情况？因为是写在官方文件里的，所以我没有直接否定为错误，或者只是参考IOS的情况。

经过反复核对，确认这句话实际上没有问题。为了追求结果的过程，我们需要写一下浏览器的大致情况:

浏览器的核心部分是浏览器内核，每个浏览器都有自己的内核，而WebKit对移动领域的影响最深。

WebKit是一个页面渲染和逻辑处理引擎，HTML/CSS/JavaScript由它进行处理，成为一个可视和可操作的网页。

WebKit由几个重要模块组成，整体结构如下:

WebKit由四部分组成，即:

WebKit嵌入API:负责浏览器UI和WebKit之间交互的部分。

平台API（Webkit Ports）:它使Webkit能够更方便地移植到各种操作系统和平台上，并提供了一些调用本机库的接口。

WebCore:整个WebKit中的核心渲染引擎。

JavascriptCore:JSCore: JS core是WebKit的默认嵌入式JS引擎，由苹果公司使用c开发。

让我们关注JSCore，它是WebKit的默认嵌入式JS引擎。之所以称为默认嵌入，是因为许多基于WebKit分支开发的浏览器引擎都开发了自己的JS引擎，其中最著名的是Chrome的V8引擎。

V8发动机，相信前端的小伙伴应该不会陌生。由于基于WebKit，底层默认内嵌JSCore，Android的逻辑层运行在V8上。

IOS的浏览器引擎是WebKit，内部是JSCore。

最后，开发工具的逻辑层运行在NW.js及其官方网站上。请看一段话:

我相信应该也和WebKit有关。

【相关学习推荐:小程序学习教程】

以上就是微信小程序架构基本原理的详细内容。更多资讯请关注主机参考其他相关文章！

这几篇文章你可能也喜欢：

• 微信小程序中如何实现子对父的参数传递（页面沟通）（小程序父对子的价值传递）
• 详细讲解如何在微信小程序中安装和引用ECharts。(如何安装小程序示例)
• 手把手指导你在小程序中实现保存图片的功能（小程序申请保存图片到相册）
• 如何在小程序中创建页面二维码
• 小程序如何动态制作小程序码分析（如何在小程序中动态生成小程序二维码图片）

本文由主机参考刊发，转载请注明：微信小程序架构基本原理详解（微信小程序的架构是b/s还是c/s） https://zhujicankao.com/103053.html