微信小程序架构基本原理详解（微信小程序B/S或C/S架构）

本文介绍了微信小程序的相关问题。 主要介绍宿主环境、执行环境、小程序整体架构、工作机制、更新机制等基本架构原理的相关内容。 我们来看看数据通信是如何工作的等等。 我希望这对你有帮助。

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

下图是微信小程序的整体架构。

发展由来

首先简单介绍一下微信小程序的发展历史。 只有了解自己和敌人，你才能赢得任何战斗。 微信小程序简称小程序。 张小龙老师于2017年1月9日在微信公开课上宣布正式上线。 小程序的英文名称是Mini Program。 这是一个不需要下载或安装的应用程序。 我们让“随时可用”的应用程序梦想成真。 用户可以扫描或搜索来打开应用程序。

小程序自推出以来，就被称为便携版APP。 两者的区别在于，小程序相对轻量级，开发成本更低，开发周期更短，提供结果更快。

小程序并不是一个凭空诞生的概念。 当微信的WebView逐渐成为移动网络的重要门户时，微信就有了相关的JS API。

WebView是移动设备（手机、iPad）提供的执行JavaScript的环境。 这是一个允许系统渲染网页的控件。 与页面上的JavaScript配合，实现APP和Web的混合开发。 WebView需要强大的工具来渲染网页。 渲染内核支持。 Android和IOS系统内核不同。

据我了解，小程序诞生的主要推动力是微信移动网页传播经验不足、能力较弱。 当然，我认为这也是由于原生APP的弊端造成的，比如每次都要从App Store下载。 或者即使你从其他应用市场下载它，也会占用你系统大量的空间。 如果您不经常使用它，您的用户很可能会删除它。

我们先抛开原生APP的问题。 对于微信移动网页传播经验不足，问题是你的体力不够。 后来微信团队推出了JS-SDK来解决移动网页功能不足的问题，但是JS-SDK模型解决了我没有使用移动网页时体验不佳的问题。 我认为原因可能是白屏问题、页面切换困难、点击滞后等。

为了解决这些问题，微信团队面临的问题是设计一个更好的系统，让所有开发者都能在微信上有更好的体验。 这个问题无法用之前的JS-SDK来处理，需要全新的系统来解决。 所有开发人员应该能够：

加载速度快。

更强大的能力。

原生体验。

简单易用，安全微信数据开放。

高效、简单的开发。

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

托管环境

微信小程序的托管环境为微信客户端。 这个取决于运行在微信客户端上，与小程序基础库的版本有重要关系。

微信小程序的托管环境可以参考微信客户端和小程序基础库。

微信小程序可以调用宿主环境提供的微信客户端功能，实现许多常规网页无法实现的功能。 这为小程序提供了比常规网页更多的功能。 由于小程序运行在不同版本的宿主环境（不同的微信客户端+不同的基础库）中，程序与各个版本的宿主环境的兼容性是不可避免的。

执行环境

小程序的主要开发语言是Javascript。 这与传统的Web开发类似，但也有一些区别。

Web 开发、渲染线程和脚本是互斥的。 因此，长时间运行脚本可能会导致页面无响应。 本质就是人们常说的JS是单线程的。

在小程序中，视图层和逻辑层是分离的，两个线程同时运行。 视图层界面使用WebView渲染，逻辑层在JSCore中执行。

Web开发主要涉及各个厂商的浏览器。 在移动端，我们还要和Sa打交道。Fari、Chrome 以及适用于 iOS 和 Android 系统的各种 WebView。

小程序主要支持IOS、Android两大操作系统的微信客户端、开发工具、PC（windows）、Mac。 开发时需要注意微信客户端的版本号以及小程序API支持的基础库的版本号。

微信小程序运行在多个平台，包括iOS（iPhone/iPad）微信客户端、Android微信客户端、PC微信客户端、Mac微信客户端以及用于调试的微信开发者工具。

每个平台都有不同的脚本编写和渲染非本机组件的环境。 具体区别是：

小程序整体架构

通过以上，大家应该对小程序的诞生和环境有了一个大概的了解。 接下来我们讨论一下小程序的整体设计结构。

整个小程序系统架构分为视图层（WebView）和逻辑层（App Service）两部分。 这两部分由两个独立的线程管理。

视图层：也称为渲染层，渲染层用于渲染页面结构，主要由WebView渲染。 一个小程序可以有多个界面，因此渲染层可能有多个WebView线程。

逻辑层：逻辑层使用JSCore线程执行JS脚本。 逻辑层主要用于逻辑处理、数据请求、接口调用等。

视图层和逻辑层之间的通信必须使用系统层（WeixinJsBridage）。 逻辑层将数据变化通知视图层，从而触发视图层的页面更新，视图层通知所触发的事件。 移至逻辑层进行业务逻辑处理。

通过上面的分析，你是否了解了最初布置的架构图？

上面的分析中还提到了系统层（WeixinJsBridage），即通常所说的JSBridge。 它作为一个中间桥梁，非常重要。 它不仅允许视图层和逻辑层两个独立的线程进行通信，而且充当上层开发和系统之间的桥梁。它充当系统底层功能（原生）的桥梁，允许小程序调用API并使用原生功能，并且一些组件采用原生组件实现，提供更好的体验。

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

既然你已经了解了这些，我希望你对小程序的整体结构有所了解。 首先我们来说说小程序的一些内部机制。

工作机制

小程序启动和运行有两种情况。

冷启动（重启）：如果用户第一次打开小程序或者重新打开被微信主动销毁的小程序。 该程序必须重新加载并启动。 这是冷启动。

热启动：用户打开小程序，然后在一定时间内再次打开小程序。 这种情况下，不需要重启，只需将小程序的后台状态切换到前台即可。 这个过程称为热启动。 开始。

注意：

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

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

3.小程序在短时间内收到系统发出的3次或以上内存警告也会被销毁。 这就是页面内存溢出时页面崩溃的根本原因。

更新机制

小程序冷启动时发现新版本时，异步下载新版本包，并与本地旧包同时启动。 客户端首先开始启动，直到下次冷启动时才会启动。 应用。 如果您需要立即应用最新版本，可以使用 wx.getUpdateManager 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来同步渲染。 在小程序架构中，这都是异步操作。

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

了解了视图层和逻辑层之间的具体通信流程之后，对于视图层和逻辑层之间的数据传输也有了一点了解。 可以看到两者之间的通信依赖于系统层的功能，而系统层的功能实际上是通过两者提供的EvaluateJavascript来实现的。 这意味着用户提交的数据必须转换为字符串并传递。 同时，将转换后的数据内容组合成JS脚本，通过执行JS脚本传递到两个独立的环境。

关于evaluateJavascript：

native调用JS时，通常是直接的JS代码串。 这和JS中调用eval执行一串代码类似。 一般有loadUrl、evaluateJavaScript 等方法。

这里我不会讲太多细节。 你一定要记住，这是用来调用和执行JS字符串的，也是native识别JS代码的方式。

登录机制

任何曾经运行过小程序的人都应该熟悉这个图。

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

调用wx.login()获取临时登录授权码并发回开发者服务器。

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

UnionID机制​​说明

UnionID是微信不久前新增的一个功能。 获取方法与openid相同，功能也相同。 两者都指的是用户的唯一ID，但它们的范围更广泛。

不明白吗？说白了，你把小程序绑定到微信开放平台账号后，就可以连接到该账号绑定的其他移动应用、网站应用、公众账号。 例如，同一用户在PC上扫描登录，审批微信公众号开发的页面，审批微信小程序。 在这些场景下，可以识别出同一个用户，获得的UnionID也是相同的。 传送门

性能问题

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

过于频繁地调用 setData()

过于频繁地调用 setData() 似乎是一个非常常见的问题（在计时器上调用它，（例如在监视的钩子中调用）页面滚动）。 。 在这些场景下，小程序很容易出现页面延迟、页面数据更新不及时等性能问题。情况。

在数据通信机制中，我们提到小程序是基于双线程的。 这意味着视图层和逻辑层之间的所有数据传输都是线程间通信，频繁调用 setData() 会使线程保持忙碌。 当逻辑层通知视图层时，消耗的时间会增加。 当视图层收到消息时，距离消息发送可能已经过去了一段时间，页面可能无法在足够的时间内渲染。 。

对大量数据调用setData()

以前的数据通信机制需要将发送的数据转换为字符串后再传递。 通过JS脚本执行。 ，如果数据量大的话，运行脚本的编译时间和执行时间也会增加，占用线程。

页面的 DOM 结构复杂

如果页面的 DOM 结构复杂且数量较多，必然会导致页面渲染延迟、页面卡顿等。甚至导致页面消失。 失败。 造成崩溃的情况可能有多种原因。 绘制和计算 DOM 需要时间，这会导致线程过渡工作，增加客户端内存使用量，并导致系统回收小程序页面。

JSCore

我上面提到“逻辑层由JSCore执行”这句话之所以有问题，是因为表中列出的逻辑层执行的环境是根据系统环境来区分的因为。我看到它需要完成。 。 这么说来，这个说法是不是太笼统了？或者这个说法是指IOS的情况吗？ 官方文档里是这么写的，所以我并不是因为写错或者我只是指IOS的情况而直接否认。

经核实，确认该说法正确。 为了追踪产生的过程，需要描述浏览器的大致情况。

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

WebKit是一个页面渲染和逻辑处理引擎。 对HTML/CSS/JavaScript进行处理以创建可以显示和操作的网页。

WebKit 由几个重要的模块组成。整体结构为：

WebKit由四个部分组成：

WebKit Embedding API：负责浏览器UI和WebKit之间交互的部分。

平台API（WebKit端口）：使WebKit更容易移植到不同的操作系统和平台，并提供多种调用本机库的接口。

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

JavaScriptCore：JSCore是WebKit默认内置的JS引擎，由Apple使用C语言开发。

让我们重点关注 JSCore 部分。 JSCore 是 WebKit 默认内置的 JS 引擎。 很多基于WebKit分支的浏览器引擎都开发了自己的JS，所以据说是默认嵌入的。 引擎，最著名的是 Chrome 的 V8 引擎。

相信各位前端朋友都熟悉V8引擎。 由于是基于WebKit，JSCore默认嵌入在最底层，Android逻辑层运行在V8上。

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

开发工具的最终逻辑层运行在 NW.js 之上。 访问官网，看到下面一段话：

我想这也和WebKit有关系。

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

下载微信小程序

微信是支持通过蜂窝网络发送语音消息、视频、照片和文本的蜂窝通信软件。 微信带来了全新的移动通信体验，您可以单独或群组聊天，还可以根据您的地理位置查找附近的人。 有需要的朋友，请快来保存您的下载体验吧！

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

• 微信小程序开发的宿主环境详解（微信小程序开发环境搭建流程）
• 来说说微信小程序中的事件绑定（微信小程序中的一个按钮可以绑定多个事件吗？）
• 增强微信小程序基本概述（微信小程序基础知识）
• 简介：实现小程序的授权登录功能
• 微信小程序列表渲染示例介绍（小程序渲染HTML代码）

本文由主机参考刊发，转载请注明：微信小程序架构基本原理详解（微信小程序B/S或C/S架构） https://zhujicankao.com/140542.html