浏览器的event loop,一起来了解下吧

151 阅读7分钟

本文主要对于javascript运行环境---浏览器的event loop机制的一些理解,不足之处,请多多指正。

Javascript单线程

JavaScript语言单线程的,也就是说,同一个时间只能做一件事。那么,为什么JavaScript只能是单线程呢?

JavaScript的单线程,与它的用途有关。作为浏览器脚本语言,JavaScript的主要用途是与用户互动,以及操作DOM。这决定了它只能是单线程,否则会带来很复杂的同步问题。比如,假定JavaScript同时有两个线程,一个线程在某个DOM节点上添加内容,另一个线程删除了这个节点,这时浏览器就不知道该以哪个线程为主。

虽然在Html5新规范中定义,允许JavaScript脚本创建多个线程,但是子线程完全受主线程控制,并且不得操作DOM。所以,这个新标准并没有改变JavaScript单线程的本质。

首先,我们来看看Javascript代码执行过程中都会有哪些东西?

代码执行栈(JavaScript execution context stack)

在代码执行过程中,主线程有一个栈,每一个函数执行的时候,都会生成新的execution context(执行上下文),执行上下文会包含一些当前函数的参数、局部变量之类的信息,它会被推入栈中, running execution context(正在执行的上下文)始终处于栈的顶部。当函数执行完后,它的执行上下文会从栈弹出。

现在我们来看看这段代码的执行顺序:

function foo2() {
    console.log('foo2');
}
function foo1() {
    console.log('foo1');
    foo2();
}
foo1();

代码结果是:

// foo1
// foo2

具体流程如图所示

  • 栈中代码的执行遵循先进后出原则

Javascript运行环境的运行机制

在Javascript中,所有任务可以分成两种,一种是同步任务(synchronous),另一种是异步任务(asynchronous)。同步任务指的是,在主线程上排队执行的任务,只有前一个任务执行完毕,才能执行后一个任务;异步任务指的是,不进入主线程、而进入"任务队列"(task queue)的任务,只有"任务队列"通知主线程,某个异步任务可以执行了,该任务才会进入主线程执行。

主要流程:

  1. 所有同步任务都在主线程上执行,形成一个执行栈(execution context stack)。
  2. 主线程之外,还存在一个"任务队列"(task queue)。只要异步任务有了运行结果,就在"任务队列"之中放置一个事件。
  3. 一旦"执行栈"中的所有同步任务执行完毕,系统就会读取"任务队列",看看里面有哪些事件。那些对应的异步任务,于是结束等待状态,进入执行栈,开始执行。
  4. 主线程不断重复上面的第三步。 根据这个流程画了一张简单的草图,不足之处,请大家指正,图示如下:

浏览器的event loop

浏览器的event loop在html5的规范中明确定义。事件、用户交互、脚本、渲染、网络这些都是我们所熟悉的东西,他们都是由event loop协调的。触发一个click事件,进行一次ajax请求,背后都有event loop在运作。

什么是event loop

主线程不断的从任务队列中获取事件来执行,这个过程是不断的循环的,这样的一种运行机制也就被称之为Event Loop(事件循环)

  • 主线程在运行时,会生成堆和栈,里面存储的是调用的代码
  • 栈中调用的代码会调用各种外部的API,这些代码执行会在任务队列中添加各种事件
  • 只要栈中的代码执行完成,主线程就会去读取任务队列,依次执行任务队列中事件对应的回调函数
  • 栈中的同步代码总会先于任务队列中的异步代码执行

现在我们来看这段代码在浏览器中是如何执行的:

console.log('1');

setTimeout(function () {
    console.log('setTimeout 1')
}, 0);

Promise.resolve().then(function () {
    console.log('promise 1');
}).then(function () {
    console.log('promise 2');
});

console.log('2');

测试这段代码在不同的浏览器上显示的顺序

  • 谷歌浏览器显示的是这样的

  • safari 9.1.2浏览器中显示的却是promise1 promise2会在setTimeout的后边

为什么会出现不同浏览器解析这段代码输出不同的顺序? 在了解完macro-task和micro-task之后就明白了

macro-task

一个event loop有一个或者多个macro-task队列。 当用户代理安排一个任务,必须将该任务增加到相应的event loop的一个macri-tsak队列中。

每一个macro-task都来源于指定的任务源,比如可以为鼠标、键盘事件提供一个macro-task队列,其他事件又是一个单独的队列。可以为鼠标、键盘事件分配更多的时间,保证交互的流畅。

那么有哪些任务源是macro-task任务源呢?

  • DOM操作任务源:此任务源被用来相应dom操作,例如一个元素以非阻塞的方式插入文档。
  • 网络任务源:网络任务源被用来响应网络活动。

macro-task任务源包含的范围比较广泛,基本上我们对DOM元素进行事件绑定并且绑定的各个事件都是macro-task任务源,需要注意的是setTimeout、setInterval、setImmediate也是macro-task任务源。所以macro-task任务源可以总结为

  • setTimeout
  • setInterval
  • setImmediate
  • I/O

micro-task

除了macro-task还有一个micro-task,这一个概念是ES6提出Promise以后出现的。这个micro-task queue只有一个。并且会在且一定会在每一个macro-task后执行,且执行是按顺序的。加入到micro-task的事件类型有Promise.resolve().then(), process.nextTick()值得注意的是,event loop一定会在执行完micrtask以后才会寻找新的可执行的macrotask队列。

常见的产生micro-task事件的方法:

  • process.nextTick
  • promise
  • Object.observe
  • MutationObserver

在Promises/A+规范的Notes 3.1中提及了promise的then方法可以采用"宏任务(macro-task)"机制或者"微任务(micro-task)"机制来实现。所以开头提及的promise在不同浏览器的差异正源于此,有的浏览器将then放入了macro-task队列,有的放入了micro-task队列。

那让我们再来看一段代码:

setTimeout(function setTimeout2() {
    console.log('setTimeout1');
}, 0);
setTimeout(function setTimeout2() {
    console.log('setTimeout2');
    Promise.resolve().then(function promise1() {
        console.log('promise1');
    });
}, 0);
Promise.resolve().then(function promise2() {
    console.log('promise2');
    setTimeout(function setTimeout1() {
        console.log('setTimeout3');
        Promise.resolve().then(function promise1() {
            console.log('promise3');
        });
    }, 0);
});

我们来看这段代码在浏览器中执行的具体结果:

代码执行过程: script里的代码被列为一个macro-task,放入macro-task队列。

循环1:

  1. 【macro-task队列:script ;micro-task队列:】
  2. 从macro-task队列中取出script任务,推入栈中执行。
  3. promise2列为micro-task,setTimeout1列为macro-task,setTimeout2列为macro-task。
  4. 【task队列:setTimeout1 setTimeout2;micro-task队列:promise2】
  5. script任务执行完毕,执行micro-task checkpoint,取出micro-task队列的promise2执行。

循环2:

  1. 【macro-task队列:setTimeout1 setTimeout2;micro-task队列:】
  2. 从macro-task队列中取出setTimeout1,推入栈中执行,将promise1列为micro-task
  3. 【macro-task队列:setTimeout2;micro-task队列:promise1】
  4. 执行micro-task checkpoint,取出micro-task队列的promise1执行。

循环3:

  1. 【macro-task队列:setTimeout3;micro-task队列:】
  2. 从macro-task队列中取出setTimeout3,推入栈中执行。
  3. setTimeout3任务执行完毕,执行micro-task checkpoint。
  4. 【macro-task队列:;micro-task队列:promise3】
  5. 执行micro-task checkpoint,取出micro-task队列的promise3执行。

event loop的处理过程

event loop的处理过程(Processing model) 在规范的Processing model定义了event loop的循环过程:

一个event loop只要存在,就会不断执行下边的步骤:

  1. 在tasks队列中选择最老的一个task,用户代理可以选择任何task队列,如果没有可选的任务,则跳到下边的micro-tasks步骤。
  2. 将上边选择的task设置为正在运行的task。
  3. Run: 运行被选择的task。
  4. 将event loop的currently running task变为null。
  5. 从task队列里移除前边运行的task。
  6. micro-tasks: 执行micro-tasks任务检查点。(也就是执行micro-tasks队列里的任务)
  7. 更新渲染(Update the rendering)...
  8. 如果这是一个worker event loop,但是没有任务在task队列中,并且WorkerGlobalScope对象的closing标识为true,则销毁event loop,中止这些步骤,然后进行定义在Web workers章节的run a worker。
  9. 返回到第一步。

event loop会不断循环上面的步骤,概括说来:

event loop会不断循环的去取tasks队列的中最老的一个任务推入栈中执行,并在当次循环里依次执行并清空micro-task队列里的任务。

文中的图示是根据网络文档整理而成,不足之处或者有错误的地方,请指出,谢谢