浏览器和Node.js的JavaScript执行流程都是基于事件循环（event loop）。
理解事件循环的工作原理对于设计正确的架构以及优化架构都非常重要。
Event Loop
event loop的概念非常简单。以下是伪码说明
for(;;) {
Java script Engine 等待任务
Java script Engine 执行任务
Java script Engine 休眠
}
引擎的算法如下：
- 当有任务时：
- 从最老的任务开始执行
- 当没有任务时休眠，一旦有任务到来，执行1
当我们在浏览网页时，JavaScript引擎大部分时间啥也不做，只有当一个script或者一个控件handler或者一个Event被激活时，引擎才运行。
以下是任务（task）的例子
- 当浏览器加载一个外部脚本
<script src=“…”>，执行这个脚本就是一个任务。 - 当用户移动他们的鼠标，分配一个鼠标移动事件（mouseevent）并执行它就是一个任务
- 当
setTimeout的定时任务到期了，运行该函数的callback就是一个任务。
任务是一个集合。JavaScript引擎执行它们，然后等待更多的任务到来（引擎在等待任务时处于休眠状态，几乎不消耗CPU资源）
如果引擎在忙碌执行任务时，新任务到来之后会排队（enqueue）。这些排队的任务形成了一个队列，这个队列就叫做“macrotask queue”（v8 术语）
例如，当JavaScript引擎在执行script的时候，用户移动了鼠标触发了mousemove，以及setTimeout可能同时到期触发了它的callback被执行。这些任务如上图所示就形成了一个队列。
队列中的任务基于“先来先服务”的原则被处理。即，浏览器的JavaScript引擎会执行完script之后，处理mousemove事件，最后处理setTimeout。
两个细节问题：
- 当引擎在执行任务时，它不会进行渲染（rendering）。只有任务被执行完成，对DOM的改变才会被绘制。
- 如果任务的执行时间很长，浏览器就无法执行别的任务，处理用户事件，经过一段时间，浏览器会弹出一个警告，例如“页面无响应”。
Use-case 1: 拆分大（CPU-hungary）任务
例如，有一个语法高亮的任务非常消耗CPU资源。为了高亮代码，它需要执行分析、创建许多不同颜色的元素，然后把这些元素加到document中，如果是一大段文本，这个任务将执行很长时间。
当JavaScript引擎忙于执行语法高亮任务时，它无法做其它DOM相关的任务、处理用户事件等等。因此这有可能导致浏览器无响应。
我们可以通过将大任务拆分成小任务规避这个问题。例如，先高亮100行文本，然后通过setTimeout(0)调度一个新任务处理下100行的文本，以此类推，每处理100行文本通过setTimeout(0)调度一次。
以下是不同过setTimeout进行调度的代码，可能会引发浏览器无响应
let I = 0;
let start = Date.now();
function count() {
// do a heavy job
for (let j = 0; j < 1e9; j++) {
I++;
}
alert(“Done in “ + (Date.now() - start) + ‘ms’);
}
count();
JavaScript引擎在执行以上代码中的for循环时，如果有用户事件到来，引擎会将用户事件放入队列中，因为上面的for循环占据了CPU资源，所以有可能用户事件任务长期得不到执行，导致页面僵死。
以下是对上面代码的优化
let I = 0;
let start = Date.now();
function count() {
// do a piece of the heavy job (*)
do {
I++;
} while (I % 1e6 != 0);
if (I == 1e9) {
alert(“Done in “ + (Date.now() - start) + ‘ms’);
} else {
setTimeout(count); // schedule the new call (**)
}
}
count();
现在，浏览器在执行“计数（count）”的过程中，也可以处理和用户的交互了。
优化的思路是让count函数执行部分工作（*），然后重新调度（re-schedule）count函数执行剩下的工作
- 首先，运行 counts：i=1...1000000
- 其次，运行 counts：i= 1000001..2000000
- 不断的通过setTimeout进行调度，最后达到（I == le9）的条件
如果浏览器在忙于执行某次count的时候，有一个用户事件（例如 onclick）到了，它会先排队，然后count执行完了，下一个被调度的count会排在用户事件的任务后面，因此引擎会先执行用户事件任务。
在执行count时，周期性的返回到事件循环（event loop）提供了足够的机会让JavaScript引擎去响应其它的任务（例如用户的交互）
Use-case 2: 进度指示
拆分大任务的另一个好处是我们可以展示进度
通常当代码执行完毕后，浏览器才会进行渲染。好处是，我们的JS函数可能创建了很多元素，然后一个个把它们加入到文档中，接着改变样式，在任务没有完成时，用户不会看到文档的这些中间状态。
下面是个demo，知道函数count执行完毕后，我们才能看到i的值
<div id=“progress"></div>
<script>
function count() {
for (let I = 0; I < 1e6; I++) {
I++;
progress.innerHTML = I;
}
}
count();
</script>
通过使用setTimeout将大任务拆分成子任务，我们可以在执行的任务的同时展示任务进度。
<div id=“progress"></div>
<script>
let I = 0;
function count() {
// do a piece of the heavy job (*)
do {
I++;
progress.innerHTML = I;
} while (I % 1e3 != 0);
if (I < 1e7) {
setTimeout(count);
}
}
count();
</script>
在事件发生后，执行某个任务
如果我们想在某个事件处理函数（event handler）执行完毕后，再执行某个任务，例如（分发自定义事件（Dispatching custom events）），我们也可以使用setTimeout（延时为0）进行包装
menu.onclick = function() {
// …
// create a custom event with the clicked menu item data
let customEvent = new CustomEvent(“menu-open”, {
bubbles: true
});
// dispatch the custom event asynchronously
setTimeout(() => menu.dispatchEvent(customEvent));
};
Macrotasks(宏任务) and Microtasks（微任务）
宏任务如前文所述是当JavaScript Engine 执行某个任务处于忙状态时，此时其它任务到达时排队形成的任务队列，这些任务包括了：
* 浏览器加载的JS脚本
* 事件处理函数
* 定时任务（setTimout，setInterval ，setImmediate）
* IO处理（网络请求、磁盘读写）
* UI 渲染
微任务仅仅来自于我们的代码。它们通常通过promises创建：
* 执行 .then/catch/finally的处理流程就是一个个微任务。
* await同样也是对微任务的包装
* queueMicrotask(func)函数会将func加入到微任务的队列中执行。
JavaScript 引擎在执行每一个宏任务之后，会立刻执行微任务队列中所有任务之后，再执行宏队列中的其它任务或者进行渲染
举个例子
setTimeout(() => alert(“timeout”));
Promise.resolve()
.then(() => alert(“promise”));
alert(“code”);
以上代码alert的顺序是：
1. code首先被show出
2. 因为then是一个微任务（microtask），所以 promise被show出
3. 最后setTimeout是另一个宏任务（macrotask）。最后被执行。timeout被show出。
下面是另一个例子 说明 宏任务（macrotask）执行后，JavaScript引擎会立即执行微任务，然后再进行渲染或执行别的宏任务
<div id=“progress"></div>
<script>
let I = 0;
function count() {
// do a piece of the heavy job (*)
do {
I++;
progress.innerHTML = I;
} while (I % 1e3 != 0);
if (I < 1e6) {
queueMicrotask(count);
}
}
count();
</script>
因为queueMicrotask将count加入到微任务队列中，所以JavaScript引擎会把所有的count执行完毕再进行渲染，因此用户看到的进度指示是最后的数字，并不会看到中间过程的数字。
