浏览器执行js原理

浏览器执行js原理

是不是大都数前端开发者都会有这样的疑惑,确实,我自己在开发的过程中每次碰到promise,setTimeout,requestAnimationFrame都会去想,在这个执行的过程中到底发生了什么?

解析:

在前端执行一系列任务的时候,渲染进程会创建一个消息队列,在这个消息队列里存放着待执行的任务函数,按照先进先出的原则,依次执行任务函数。因此只要消息队列里有任务,JS执行主线程就会不断的执行消息队列里的任务。这便是js单线程执行js代码的简单原理,当然涉及的深的话,应该还要有IO线程,专门处理新加进来的任务,以及其它进程过来的任务。

但是js执行过程作为一个单线程的执行过程,其实是有缺点的。上面说过了,消息队列是“先进先出”的属性,也就是说放入队列中的任务,需要等待前面的任务被执行完,才会被执行。鉴于这个属性,那js是如何处理高优先级的任务?

js是如何处理高优先级的任务?

比如一个典型的场景,DOM节点的变化,增、删,改,如果页面上的一个输入框状态需要实时的映射到页面上。一个通用的设计的是,利用 JavaScript 设计一套监听接口,当变化发生时,渲染引擎同步调用这些接口,这是一个典型的观察者模式,即给这个输入框添加一个变化事件的监听。

但是这个模式有一个问题,就是如果当前的DOM变化非常的频繁,都去执行js任务的话,会导致当前在执行的js任务被延长,从而导致执行效率的下降;如果把这些任务添加到消息队列的尾部,则无法及时响应用户的操作。要想兼容这两种情况,微任务便应运而生了。

通常我们把消息队列中的任务称为宏任务,每个宏任务中都包含了一个微任务队列,在执行宏任务的过程中,如果 DOM 有变化,那么就会将该变化添加到微任务列表中,这样就不会影响到宏任务的继续执行,因此也就解决了执行效率的问题。

等宏任务中的主要功能都直接完成之后,这时候,渲染引擎并不着急去执行下一个宏任务,而是执行当前宏任务中的微任务,因为 DOM 变化的事件都保存在这些微任务队列中,这样也就解决了实时性问题。

这便是在js执行过程中为什么会有微任务与宏任务之分的原因。

文章转自 浏览器执行js原理 , https://www.xiaye0.com/articlejs?id=40