探索小程序底层架构原理_微信开发者工具如何找到小程序逻辑层webview

双线程架构

在这之前，我们先来思考一个问题，小程序在架构上为什么会选择双线程？

为什么是双线程？

加载及渲染性能

小程序的设计之初就是要求快速，这里的快指的是加载以及渲染。

目前主流的渲染方式有以下3种：

• Web技术渲染
• Native技术渲染
• Hybrid技术渲染（同时使用了webview和原生来渲染）

从小程序的定位来讲，它就不可能用纯原生技术来进行开发，因为那样它的编译以及发版都得跟随微信，所以需要像Web技术那样，有一份随时可更新的资源包放在远程，通过下载到本地，动态执行后即可渲染出界面。

但如果用纯web技术来开发的话，会有一个很致命的缺点那就是在 Web 技术中，UI渲染跟 JavaScript 的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源，这也就跟设计之初要求的快相违背了。

因此微信小程序选择了Hybrid 技术，界面主要由成熟的 Web 技术渲染，辅之以大量的接口提供丰富的客户端原生能力。同时，每个小程序页面都是用不同的WebView去渲染，这样可以提供更好的交互体验，更贴近原生体验，也避免了单个WebView的任务过于繁重。

微信小程序是以webview渲染为主，原生渲染为辅的混合渲染方式

管控安全

由于web技术的灵活开放特点，如果基于纯web技术来渲染小程序的话，势必会存在一些不可控因素和安全风险。

为了解决安全管控的问题，小程序从设计上就阻止了开发者去使用一些浏览器提供的开放性api，比如说跳转页面、操作DOM等等。如果把这些东西一个一个地去加入到黑名单，那么势必会陷入一个非常糟糕的循环，因为浏览器的接口也非常丰富，那么就很容易遗漏一些危险的接口，而且就算是禁用掉了所有的接口，也防不住浏览器内核的下次更新。

所以要彻底解决这个问题，必须提供一个沙箱环境来运行开发者的JavaScript 代码。这个沙箱环境只提供纯 JavaScript 的解释执行环境，没有任何浏览器相关接口。那么像HTML5中的ServiceWorker、WebWorker特性就符合这样的条件，这两者都是启用另一线程来执行 javaScript。

这就是小程序双线程模型的由来：

• 渲染层： 界面渲染相关的任务全都在 WebView 线程里执行，通过逻辑层代码去控制渲染哪些界面。一个小程序存在多个界面，所以渲染层存在多个 WebView。* 逻辑层： 创建一个单独的线程去执行 JavaScript，在这个环境下执行的都是有关小程序业务逻辑的代码。### 双线程模型

小程序的架构模型有别与传统web单线程架构，小程序为双线程架构。

微信小程序的渲染层与逻辑层分别由两个线程管理，渲染层的界面使用 webview 进行渲染；逻辑层采用 JSCore运行JavaScript代码。

webview渲染线程

如何找到渲染层？

1.我们可以通过调试微信开发者工具：微信开发者工具 ->调试 ->调试微信开发者工具

2.然后我们会再看到一个调试界面，看起来跟我们平时用的浏览器调试界面几乎一摸一样

但这并不是小程序的渲染层，而是开发者工具的结构。但我们在里面可以发现有一些webview标签，在第一个webview上的src属性看着是不是有点眼熟，没猜错的话它就是我们当前小程序打开页面的路径。所以这个webview才是小程序真正的渲染层。这里你会发现它里面并不只有一个webview，其实里面包含着视图层的webview，业务逻辑层webview，开发者工具的webview

开发者工具的逻辑层跑在webview中主要是为了模拟真机上的双线程