Event Loop即事件循环，是解决javaScript单线程运行阻塞的一种机制。 主要是为了协调单线程下，事件、用户交互、脚本、UI 渲染和网络处理等行为，防止主线程的不阻塞。
因为JavaScript 是单线程，也就是说， 所有任务需要排队，前一个任务结束，才会执行后一个任务。
但是IO设备（输入、出设备）可能会因为网络等因数导致速度很慢（比如Ajax）继而CPU没有充分利用，所以设计者将IO设备的任务挂起，先执行后面的任务，等到IO设备返回了结果，再回过头，把挂起的任务继续执行下去。于是，就把所有任务分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。
只有前一个任务执行完毕，才能执行后一个任务；直接在主线程上排队执行且最先执行，形成一个执行栈
不进入主线程、而是进入"任务队列"（task queue）的任务，只有"任务队列"通知主线程，某个异步任务可以执行了，该任务才会进入主线程执行。
（1）所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。
（2）主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。
（3）一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，执行一个宏任务， 执行过程中如果遇到微任务，就将它添加到微任务的任务队列中 宏任务执行完毕后，再依次执行执行当前微任务队列中的所有微任务，当前宏任务执行完毕，开始检查渲染，然后GUI线程接管渲染 渲染完毕后，JS线程继续接管，开始下一个宏任务（从事件队列中获取）
（4）主线程不断重复上面的第三步。
"任务队列"是一个先进先出的数据结构，也是一个事件的队列（也可以理解成消息的队列），IO设备完成一项任务，就在"任务队列"中添加一个事件，表示相关的异步任务可以进入"执行栈"了。主线程读取"任务队列"，就是读取里面有哪些事件。
"任务队列"中的事件，除了IO设备的事件以外，还包括一些用户产生的事件（比如鼠标点击、页面滚动等等）。只要指定过回调函数，这些事件发生时就会进入"任务队列"，等待主线程读取。
所谓"回调函数"（callback），就是那些会被主线程挂起来的代码。异步任务必须指定回调函数，当主线程开始执行异步任务，就是执行对应的回调函数。
例子1
例子2：
例子3：
nodejs事件循环和浏览器的事件循环不一样的。浏览器的Event loop是在HTML5中定义的规范，而node中则由libuv库实现
一、同步和异步所谓单线程，无非就是同步队列和异步队列，js代码是自上向下执行的，在主线程中立即执行的就是同步任务，比如简单的逻辑操作及函数，而异步任务不会立马立马执行，会挪步放到到异步队列中，比如ajax、promise、事件、计时器等等。
也就是先执行同步，主线程结束后再按照异步的顺序再次执行。
二、时间循环(Event Loop)
Event Loop是什么？中文翻译是事件循环，等待主线程中任务全部完成后，再回来把异步队列中任务放到主程序中运行，这样反复的循环，就是事件循环。
b14d903a712b31c34f347ba7d64b697e.png
先来看组代码
console.log('开始111') setTimeout(function () {console.log('setTimeout111') }, 0) Promise.resolve().then(function () {console.log('promise111') }).then(function () {console.log('promise222') }) console.log('开始222')
打印 “开始111”，再打印“开始222”。
中途的三个异步，进入到了异步队列，等待同步执行完(打印完)，返回来再执行异步，所以是后打印出来。
打印的结果先放一放，我们稍后回来再说。现在我们中途插播一段知识点：
三、宏观任务和微观任务(先执行微观任务，再执行宏观任务)：
在事件循环中，每进行一次循环操作称为tick，tick 的任务处理模型是比较复杂的，里边有两个词：分别是 Macro Task (宏任务)和 Micro Task(微任务)。
简单来说：
宏观任务主要包含：setTimeout、setInterval、script(整体代码)、I/O、UI 交互事件、setImmediate(Node.js 环境)
微观任务主要包括：Promise、MutaionObserver、process.nextTick(Node.js 环境)
规范：先执行微观任务，再执行宏观任务
那么我们知道了，Promise 属于微观任务， setTimeout、setInterval 属于宏观任务，先执行微观任务，等微观任务执行完，再执行宏观任务。所以我们再看一下这个代码：
console.log('开始111') setTimeout(function () {console.log('setTimeout111') }, 0) Promise.resolve().then(function () {console.log('promise111') }).then(function () {console.log('promise222') }) console.log('开始222')
我们按照步骤来分析下：
1、遇到同步任务，直接先打印 “开始111”。
2、遇到异步 setTimeout ，先放到队列中等待执行。
3、遇到了 Promise ，放到等待队列中。
4、遇到同步任务，直接打印 “开始222”。
5、同步执行完，返回执行队列中的代码，从上往下执行，发现有宏观任务 setTimeout 和微观任务 Promise ，那么先执行微观任务，再执行宏观任务。
所以打印的顺序为：开始111 、开始222 、 promise111 、 promise222 、 setTimeout111 。
同理，我们再来分析一个代码：
console.log('开始111')setTimeout(function () { console.log('timeout111')})new Promise(resolve =>{ console.log('promise111') resolve() setTimeout(() =>console.log('timeout222'))}).then(function () { console.log('promise222')})console.log('开始222')
分析一下：
1、遇到同步代码，先打印 “开始111” 。
2、遇到setTimeout异步，放入队列，等待执行 。
3、中途遇到Promise函数，函数直接执行，打印 “promise111”。
4、遇到setTimeout ，属于异步，放入队列，等待执行。
5、遇到Promise的then等待成功返回，异步，放入队列。
6、遇到同步，打印 “开始222”。
7、执行完，返回，将异步队列中的代码，按顺序执行。有一个微观任务，then后的，所以打印 “promise222”，再执行两个宏观任务 “timeout111” “timeout222”。
所以，打印的顺序为：开始111 、 promise111 、 开始222 、 promise222 、 timeout111 、 timeout222 .
先执行主任务，把异步任务放入循环队列当中，等待主任务执行完，再执行队列中的异步任务。异步任务先执行微观任务，再执行宏观任务。一直这样循环，反复执行，就是事件循环机制。
在网上也看了不少关于javascript事件循环的文章，多数是以浏览器事件循环与nodejs中事件循环做对比，分析两种环境的差异。下面说的内容是浏览器事件循环与前端性能之间的关系，了解之后在开发中规避一些性能问题。以下所探讨的事件循环皆指浏览器的事件循环，本文属于个人理解，如有不对欢迎提点。
提到事件循环，相信现在多数前端小白并不陌生了。首先事件循环分为宏任务和微任务。
宏任务：鼠标事件，键盘事件，网络事件，Html解析, 定时器等；
微任务：Dom变化，Promise
当这些事件发生的时候浏览器会在对应的事件队列（宏任务队列和微任务队列）中添加该事件处理器（回调函数）等待执行。而事件循环是一直循环着看事件队列中是否还有未处理的处理器，如果有的话就从队列首位取出处理器执行，执行完之后就移除对应处理器，就是这样一直循环着直到浏览器关闭为止，即使事件队列为空！但是在处理宏任务队列和微任务队列的方式不同。
在一次事件循环中只能处理一个宏任务，而需要处理所有微任务直到微任务队列清空
说明：事件循环是在主程序执行完之后就开始循环执行事件，主程序说简单点就是一个js文件从第一行执行到最后一行，主程序结束（此处说的是该应用就一个js文件）
举一个生活中的例子：
银行中排队办理业务的时候，假设每个排队等待办理的普通客户是宏任务，而VIP客户是微任务。那么在银行早上开始上班的之前，柜员启动相应的机器（电脑，打印机等）属于主程序，等一切准备好之后就开始办理业务了。假如现在有10个普通用户（宏任务）在等待，开始处理第一个客户，处理完之后叫号第二个客户，开始处理。如果在处理第二个客户的时候突然来个一个vip用户，那么在处理为完普通用户之后就轮到处理VIP用户（微任务），如果在处理VIP用户的时候又来了个VIP用户的话3号普通客户就得等待处理完两个VIP客户。当然此处举例皆是只该银行就一个服务窗口，复合js单线程模式。
下图是一个完整的事件循环图：
浏览器通常会尝试60秒渲染一次页面，以达到每秒60帧(60fps)的速度, 60fps是检验前端体验是否流畅的标准，在动画里就意味着当浏览器没16ms一次刷新的话，体验是最流畅的，所有在整个页面生命周期中每一次事件循环都应该在16ms内完成。
但是在事件循环中可能会处理比较耗时的任务，那么渲染就会延后这样就会导致动画看上去不流畅，更严重的可能是页面处于假死状态等影响用户体验。
如果加上UI渲染的话上面的事件循环图是这样的
上面提到浏览器会尝试16ms重新渲染页面，那么假如在处理事件的时候遇到耗时任务的时候，浏览器将会延迟渲染页面，如果处理不当那将会导致体验差问题。接下来仔细分析以下整个流程。
首先先排除为任务，只有宏任务的程序。现在有两个点击事件
假如主线程运行需要15ms，btn1事件处理器完成需要8ms， btn2需要10ms；那么整个流程是这样：
假如用户点击速度很快的时候，主线程运行期间在5ms和12ms时候分别点击了btn1,btn2按钮，触发点击事件，此时因为还处与主线程运行时间内，所有此时会向宏任务队列添加两个事件任务。当主线程运行到15ms时结束，此时浏览器可以重新渲染。渲染完之后进入事件循环，首先从任务队列中取出任务btn1事件处理器执行，此过程会耗时8ms，处理完之后结束一次事件循环，并移除事件处理器btn1。此时浏览器可以重新渲染，渲染完之后又进行到第二次事件循环，重复上述步骤，直到事件队列清空为止。
如果事件循环中存在为任务的话流程如下：
其实只是在宏任务之后加入了一个时间段处理为任务.。在第一循环中处理btn1事件处理器时添加promise1到微任务队列中，在执行完btn1事件之后检查微任务队列发现有一个任务待处理，然后取出处理之后移除微任务promise1在循环微任务队列，发现以微任务队列为空，28ms时浏览器可以重新渲染（此时浏览器距离上次渲染相差12ms，渲染流畅）。在执行第二次事件循环的时候，在执行到微任务队列时，需要处理两个任务，耗时8ms，46ms时浏览器可以重新渲染（此时浏览器距离上次渲染相差18ms，渲染流畅）。
总结：如果在事件循环中有的任务比较耗时，会导致浏览器渲染fps变小，从而导致用户体验差。如向页面中插入10000个td节点的时候，如果是一次循环就appendChild一次，那相当于总共会有10000个微任务待执行，这样就会影响到浏览器渲染的fps,所有会出现点击页面没有反响的体验，这就是为什么插入多个节点需要拼接到一起一次性插入节点。了解事件循环和浏览器渲染之间到联系之后，以后开发多注意一些耗时任务到处理，到此分享结束。
