浏览器进程和事件循环eventloop机制(三)

月语晨风

已于 2024-07-25 17:32:03 修改

阅读量1.5k

点赞数 48

分类专栏：前端基础文章标签： java 开发语言

于 2024-03-12 22:36:27 首次发布

本文链接：https://blog.csdn.net/machaowo/article/details/136664928

版权

前端基础专栏收录该内容

9 篇文章 0 订阅

订阅专栏

一、浏览器渲染进程(浏览器内核)，Event Loop机制用到的地方

1、再来看一下浏览器渲染进程中包含的线程

2、几个线程之间的关系

01、GUI渲染线程与JS引擎线程互斥

第一，由于JavaScript是可操纵DOM元素的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。

第二，由于JavaScript没有锁的概念，如果同时操作DOM元素，会发生冲突，产生问题

因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时，GUI线程会被挂起，GUI的更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

02、JS阻塞页面加载(比如巨量计算)

从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面，比如内存溢出，debugger操作，alert操作等会造成页面卡死现象。

再譬如，假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存到队列中，等待JS引擎空闲后执行。
然后，由于巨量计算，所以JS引擎很可能很久很久后才能空闲，自然会感觉到巨卡无比。所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。

03、WebWorker的应运而生(巨量计算)

HTML5中支持了Web Worker

MDN的官方解释是：

Web Worker为Web内容在后台线程中运行脚本提供了一种简单的方法。线程可以执行任务而不干扰用户界面

一个worker是使用一个构造函数创建的一个对象(e.g. Worker()) 运行一个命名的JavaScript文件 

这个文件包含将在工作线程中运行的代码; workers 运行在另一个全局上下文中,不同于当前的window

因此，使用 window快捷方式获取当前全局的范围 (而不是self) 在一个 Worker 内将返回错误

这样理解下：

创建Worker时，JS引擎向浏览器申请开一个子线程（子线程是浏览器开的，完全受主线程控制，而且不能操作DOM）
JS引擎线程与worker线程间通过特定的方式通信（postMessage API，需要通过序列化对象来与线程交互特定的数据）

所以，如果有非常耗时的工作，请单独开一个Worker线程，这样里面不管如何翻天覆地都不会影响JS引擎主线程，
只待计算出结果后，将结果通信给主线程即可，perfect!

而且注意下，JS引擎是单线程的，这一点的本质仍然未改变，Worker可以理解是浏览器给JS引擎开的外挂，专门用来解决那些大量计算问题。

其它，关于Worker的详解就不是本文的范畴了，因此不再赘述。

4、WebWorker线程与SharedWorker进程区别

WebWorker只属于某个页面，不会和其他页面的Render进程（浏览器内核进程）共享
- 所以Chrome在Render进程中（每一个Tab页就是一个render进程）创建一个新的线程来运行Worker中的JavaScript程序。
SharedWorker是浏览器所有页面共享的，不能采用与Worker同样的方式实现，因为它不隶属于某个Render进程，可以为多个Render进程共享使用
- 所以Chrome浏览器为SharedWorker单独创建一个进程来运行JavaScript程序，在浏览器中每个相同的JavaScript只存在一个SharedWorker进程，不管它被创建多少次。

看到这里，应该就很容易明白了，本质上就是进程和线程的区别。SharedWorker由独立的进程管理，WebWorker只是属于render进程下的一个线程;