微信体系架构微信底层架构

转载

coolfengsy 2023-07-16 11:19:32

文章标签 微信体系架构前端客户端微信微信小程序 文章分类 架构后端开发

小程序底层框架

好久没有更新博客了，闲的无聊码上一个吧～

技术选型

当下，界面渲染技术分为三种：

纯客户端界面渲染技术
web界面渲染技术
Hybird界面渲染技术（名字高端大气上档次，实际上就是客户端渲染和web渲染混合体）

那么作为微信小程序，他的选择是什么呢？

首先，小程序的宿主是微信，如果采用native技术，这意味着，每一次的小程序发版都需要和微信一起打包，这多少不太现实。
假如，选择web技术呢，众所周知，web是个单线程，一旦遇到了复杂的逻辑，那么必然逻辑渲染会抢占UI渲染，这个性能则不太友好。
因此，微信小程序采用的hybird技术，即界面使用成熟的web技术，然后辅助了一些接口提供客户端的原生能力比如扫一扫，本地存储等。。。

沙箱环境

当然，作为web技术，他会特别的灵活，比如iframe，随意跳转页面。这就对与微信的管控和安全不是很好。所以微信提供了一个沙箱环境，在这个环境中屏蔽掉了浏览器的相关接口，只提供js的解释执行环境。因此开发者不能直接操作dom，随意跳转页面。这也就解释了为什么小程序没有 window 对象。

双线程模型

在微信小程序中，一个页面就是一个webview线程，也就是渲染层，然后js逻辑开在了另一个线程里，叫逻辑层。在通信时，由渲染层到微信客户端，再从客户端传递到逻辑层，然后逻辑层操作过后在告诉微信客户端，再由微信客户端通知渲染层进行修改。这也就是为什么很多接口都是异步的原因。

看下面这段代码到显示在页面上发生了什么呢？

<view>{{msg || 'Hello World'}}</view>

let msg = 'Good Bye'
this.setData({
	msg
})

首先当 msg = ’ '时 ,页面元素可以理解为

<view>Hello World</view>

wxml 先将他转化为js对象，可以解析为一棵dom树。
然后在逻辑层对msg值进行更改的时候，会先生成一个新的js对象，然后进行比对。最终将更改的数据进行替换，然后在页面进行渲染。

原生组件

小程序的有些内置组件则为原生组件，比如input，textarea，canvas，map 等等。调用原生组件有一定的好处，体验效果更佳，比如，可以调用客户端的键盘能力，等等那么原生组件是如何渲染的呢？
首先，微信小程序会在渲染这些组件之前先写一个同大小的view，即为占位图，在其相应的区域之上，覆盖一层原生组件，因层原生组件层级是在页面层级之上的，因此像是z-index更改层级的办法是没有用处的，当然，由于这些原生组件的层级过高，必然会导致一些问题，比如textarea的文字穿透了，怎么办？针对这些，可以采用cover-view，cover-image 这些原生组件。