小程序的双线程是什么？为什么要这么设计？
发表时间：2023-11-30 21:14:32
文章来源：炫佑科技
浏览次数：122
菏泽炫佑科技 菏泽炫佑小程序开发 菏泽炫佑app制作 炫佑科技
小程序的双线程是什么？为什么要这么设计？
在上一节“小程序的诞生”中，我们也提到了小程序的双线程设计。
目前页面渲染的方式主要有以下三种：
网页渲染。 原生渲染。 Web 则将两者混合在一起，也就是我们常说的渲染。
前面说过，小程序*终的呈现形式是+原生组件。 我们根据之前对小程序的预期来看一下：
由于小程序的宿主是微信，如果使用纯客户端原生技术来编写小程序，则需要将小程序代码与微信代码打包在一起，并跟随微信发布版本。 这种方法和开发节奏肯定是错误的。
所以方向应该像Web技术一样，把一个可以随时更新的资源包放在云端，下载到本地，动态执行后就可以渲染出界面。
如果使用纯Web技术来渲染小程序，在一些交互复杂的页面上可能会面临一些性能问题。
这是因为在Web技术中，UI渲染和脚本执行是在单线程中执行的，这很容易导致一些逻辑任务抢占UI渲染资源。
一般来说，小程序选择的渲染方式可以采用类似Web的方式开发，代码也可以在线更新。
同时引入原生组件还有以下好处：
现在，我们剩下一个非常重要的问题：控制和安全。 因此，提出了双线程设计。
双线程小程序
不知道哪位大佬能想出双线程这样的模型，不过反正我很佩服666。
什么是双线程？ 我们先来看看官方的图：
小程序的渲染层和逻辑层分别由两个线程管理：渲染层的界面渲染，逻辑层使用线程运行JS脚本。
为什么要这样设计呢？ 为了解决前面提到的控制和安全问题，我们需要阻止开发使用某些浏览器提供的开放接口，例如跳转页面、操作DOM、动态执行脚本等。
我们可以使用客户端系统的引擎、iOS下的框架、下腾讯x5内核提供的环境。 通过提供沙箱环境来运行开发代码来解决。 这个沙箱环境只提供了一个纯粹的解释和执行环境，没有任何浏览器相关的接口。
这就是小程序双线程模型的由来：
双线程通信
将开发的JS逻辑代码放入单独的线程中运行，但是在线程中，开发无法直接操作DOM。 那么如何动态改变界面呢？
前面我们知道，逻辑层和渲染层之间的通信会通过（微信客户端）进行中继，逻辑层发出的网络请求也会被转发。
这是否意味着我们可以通过简单的数据通信来更新DOM？
相信大家都已经了解DOM了。 大致流程是：使用JS对象模拟DOM树 -> 比较两个虚拟DOM树的差异 -> 将差异应用到真实的DOM树上。
这里我们就可以使用了，如图：
在渲染层将WXML转换为对应的JS对象。 当逻辑层发生数据变化时，数据通过宿主环境提供的方法从逻辑层传递到渲染层，然后转发到渲染层。 对比前后差异后，将差异应用到原来的DOM树上，更新界面。
我们通过将WXML转换为数据并转发来实现逻辑层和渲染层之间的交互和通信。 这样一套完整的框架基本上是通过小程序的基础库完成的。
小程序的基础库
小程序的基础库写好了，可以注入渲染层和逻辑层运行。 主要用到：
由于小程序的渲染层和逻辑层是由两个线程管理的，因此两个线程各自注入基础库。 小程序的基础库不会打包在某个小程序的代码包中，而是预先内置到微信客户端中。
没关系：
框架
它是微信小程序的组件组织框架，内置于小程序基础库中，为小程序的各个组件提供基础支持。 小程序内的所有组件，包括内置组件和自定义组件，均由组织管理。 特点包括：
基于DOM模型：该模型与DOM高度相似，但不依赖浏览器原生支持，也没有其他依赖库； 实现过程中还添加了其他API来支持小程序编程。 可以运行在纯JS环境中：这意味着逻辑层也具备一定的组件树组织能力。 高效轻量：性能良好，尤其是在组件实例较多的环境下，而且代码量也较小。
更多基础库和框架的信息微信小程序开发过程，还可以参考：《小程序开发指南》
结论
本节简单讲一下小程序设计中比较重要的模型之一——双线程。 双线程的出现、设计、数据通信、基础库和框架，都是相互关联、相互影响的选择。
关于小程序底层框架的设计，其实涉及到的内容我们一时半会无法掌握小程序的双线程是什么？为什么要这么设计？，比如自定义组件、原生组件，还有他们做的很多性能优化工作，这些不是简单就能解释清楚的。几句话。 的。 我们能做的就是多思考。
