浏览器的事件循环

浏览器的进程模型

        进程：程序运行需要有自己专属的内存空间，可以把这块内存空间简单的理解为进程。每个应用至少有一个进程，进程之间相互独立，即使要通信，也要相互同意。

        线程：有了进程后，就可以运行程序的代码了。运行代码的人称为线程。一个进程至少有一个线程，所以在进程开启后，会自动创建一个线程来运行代码，该线程称之为主线程。

        如果程序需要同时执行多代码块，主线程就会启动更多的线程来执行代码，所以一个进程中可以包含多个线程。

        浏览器的进程和线程。浏览器是一个多进程、多线程的应用程序。浏览器内部工作极为复杂。为了避免相互影响，为了减少连环崩溃的几率，当启动浏览器后，他会自动启动多个进程。

1. 浏览器进程：主要负责界面展示、用户交换、子进程管理等。浏览器进程内部会启动多个线程处理不同的任务。
2. 网络进程：负责加载网络资源，网络进程内部会启动多个线程处理不同的任务。
3. 渲染进程：渲染进程启动后，会开启一个渲染主线程，主线程负责执行html、css、js代码。默认情况下，浏览器会为每个标签页开启一个新的渲染进程，以保证不同的标签页之间不相互影响。

渲染主线程是如何工作的

渲染主线程是浏览器中最繁忙的线程，需要它处理的任务包括但不限于：

• 解释html
• 解释css
• 计算样式
• 布局
• 处理图层
• 每秒把页面画60次 （FPS）
• 执行全局js代码
• 执行事件处理函数
• 执行计时器的回调函数

为什么渲染进程不适用多个线程来处理这些事情？

要处理这么多的任务，主线程遇到了一个前所未有的难题：如何调度任务？

比如：

1. 正在执行一个js函数，执行到一半的时候用户点击了按钮，该立即去执行点击事件的处理函数吗？
2. 正在执行一个js函数，执行到一半的时候某个计时器到达了时间，该立即去执行它的回调吗？
3. 浏览器进程通知我“用户点击了按钮”，与此同时，某个计时器也到达了时间，该处理哪一个呢？

渲染主线程想到了一个绝妙的主意来处理这个问题，排队。

1. 在最开始的时候，渲染主线程会进入一个无限循环。
2. 每一次循环会检查消息队列中是否有任务存在。如果有就取出第一个任务执行。执行完一个后，进入下一次循环；如果没有，则进入休眠状态。
3. 其他所有线程（包括其他进程的线程）可以随时向消息队列添加任务。新任务会添加到消息队列的末尾。在添加新任务时，如果主线程是休眠状态，则会将其唤醒以继续循环拿取任务。

这样，就可以让每个任务有条不紊的持续的进行下去了。

浏览器事件循环

同步处理的逻辑

主线程逐个执行任务，例如遇到setTimeout时，阻塞住等待，当等待时间够了之后，执行回调函数及后面的逻辑。

什么是异步？

代码在执行过程中，会遇到一些无法立即处理的任务，比如：

• 计时完成后需要执行的任务。（setTimeout、setInterval）
• 网络通信完成后需要执行的任务。（XHR、Fetch）
• 用户操作后需要执行的任务。（addEnentListener）

如果让渲染主线程等待这些任务的到达时机，就会导致主线程长期处于阻塞的状态，从而导致浏览器卡死。

渲染主线程承担着极其重要的工作，无论如何都不能阻塞。因此浏览器选择异步来解决这个问题。

异步处理的逻辑

当主线程遇到setTimeout时，通知一个计时线程，主线程去执行下一个任务。当计时线程计时到了之后，将需要执行的函数放入到任务队列中。

JS为什么会阻碍渲染？

因为js代码的执行和渲染都在渲染主线程中执行。

任务有优先级吗？

任务没有优先级，在消息对垒中先进先出。

但消息队列时有优先级的

• 每个任务都有一个任务类型，同一个类型的任务必须在一个队列，不同类型的任务可以分属于不同的队列。在一次事件循环中，浏览器可以根据实际情况从不同的队列中取出任务执行。
• 浏览器必须准备好一个微队列，微队列中的任务优先所有其他任务执行。

在目前的chrom实现中，至少包含了下面的队列：

• 延时队列：用于存放计时器到达后的回调任务，优先级中。
• 交互队列：用于存放用户操作后产生的事件处理任务，优先级高。
• 微队列：用于存放需要最快执行的任务，优先级最高。Promise.resolve().then(函数)用于将一个函数放入为队列。

整体执行逻辑

1. 渲染主线程：执行全局代码，全局代码执行完后再执行2、3、4队列中的任务。
2. 微队列：
3. 延时队列：
4. 交互队列：
5. 其他线程：被主线程调用后，根据实际情况，如延时等，将任务放入2、3、4队列中。