浏览器是多线程的，它们在内核制控下相互配合以保持同步。一个浏览器至少实现三个常驻线程：
JavaScript引擎线程，GUI渲染线程，浏览器事件触发线程。我们在学习浏览器的执行机制前，首先要了解浏览器的线程和线程之间的关系；
1.浏览器的线程有哪些？
- GUI 渲染线程
- 负责渲染浏览器界面，解析 HTML，CSS，构建 DOM 树和 RenderObject 树，布局和绘制等；
- 当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，该线程就会执行；
- 注意：GUI 渲染线程与 JS 引擎线程是互斥的，当 JS 引擎执行时 GUI 线程会被挂起（相当于被冻结了），GUI 更新会被保存在一个队列中等到 JS 引擎空闲时立即被执行。
- JS 引擎线程
- JS 引擎线程也称为 JS 内核，负责处理 Javascript 脚本程序，解析 Javascript 脚本，运行代码；
- JS 引擎一直等待着任务队列中任务的到来，然后加以处理，一个 Tab 页（renderer 进程）中无论什么时候都只有一个 JS 线程在运行 JS 程序；
- 注意：GUI 渲染线程与 JS 引擎线程的互斥关系，所以如果 JS 执行的时间过长，会造成页面的渲染不连贯，导致页面渲染加载阻塞。
- 事件触发线程
事件触发线程很重要，它是event loop的实现的核心之一；因为有了事件触发线程的协助，协调其他线程（定时器线程，http 线程），才会有 task queue 的入栈，当一个事件被触发时该线程会把事件添加到任务队列的队尾，等待 JS 引擎的处理。
- 归属于浏览器而不是 JS 引擎，用来控制事件循环（可以理解，JS 引擎自己都忙不过来，需要浏览器另开线程协助）；
- 当 JS 引擎执行代码块如 setTimeOut 时（也可是来自浏览器内核的其他线程,如鼠标点击、AJAX 异步请求等），会将对应任务添加到事件触发线程中；我理解是：任务分发
- 当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待 JS 引擎的处理；
- 注意：由于 JS 的单线程关系，所以这些待处理队列中的事件都得排队等待 JS 引擎处理（当 JS 引擎空闲时才会去执行）；将回调函数压入任务队列
- 定时器触发线程
- 即 setInterval 与 setTimeout 所在线程；
- 浏览器定时计数器并不是由 JS 引擎计数的，因为 JS 引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确性；
- 因此使用单独线程来计时并触发定时器，计时完毕后，通过事件触发线程，添加到事件队列中，等待 JS 引擎空闲后执行，所以定时器中的任务在设定的时间点不一定能够准时执行，定时器只是在指定时间点将任务添加到事件队列中；
- http 请求线程
- XMLHttpRequest 连接后通过浏览器新开一个线程请求；
- 检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将回调函数放入事件队列中，等待 JS 引擎空闲后执行；
- web Worker 线程
HTML5 提出 Web Worker 标准，允许 JavaScript 脚本创建多个线程，但是子线程完全受主线程控制，且不得操作 DOM。所以，这个新标准并没有改变 JavaScript 单线程的本质。
2.任务（消息）队列（task queue）
以下摘自 阮一峰 文章—JavaScript 运行机制详解：再谈 Event Loop
单线程就意味着，所有任务需要排队，前一个任务结束，才会执行后一个任务。如果前一个任务耗时很长，后一个任务就不得不一直等着。
如果排队是因为计算量大，CPU 忙不过来，倒也算了，但是很多时候 CPU 是闲着的，因为 IO 设备（输入输出设备）很慢（比如 Ajax 操作从网络读取数据），不得不等着结果出来，再往下执行。
JavaScript 语言的设计者意识到，这时主线程完全可以不管 IO 设备，挂起处于等待中的任务，先运行排在后面的任务。等到 IO 设备返回了结果，再回过头，把挂起的任务继续执行下去。
2.1 异步任务和同步任务
所有任务可以分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。同步任务指的是，在主线程上排队执行的任务，只有前一个任务执行完毕，才能执行后一个任务；异步任务指的是，不进入主线程、而进入"任务队列"（task queue）的任务，只有"任务队列"通知主线程，某个异步任务可以执行了，该任务才会进入主线程执行。
具体来说，异步执行的运行机制如下。（同步执行也是如此，因为它可以被视为没有异步任务的异步执行。）
（1）所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。
（2）主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。
（3）一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。
（4）主线程不断重复上面的第三步。
下图就是主线程和任务队列的示意图。
能看到与 I/O 相关的任务都会进入任务队列（task queue 或者叫做 event queue）,所以，你觉得xmlhttprequest是微任务还是宏任务？
答案是宏任务，因为xmlhttprequest是网络的 I/O；
2.2 异步任务与回调函数
“任务队列"是一个事件的队列（也可以理解成消息的队列），IO 设备完成一项任务，就在"任务队列"中添加一个事件，表示相关的异步任务可以进入"执行栈"了。主线程读取"任务队列”，就是读取里面有哪些事件。
“任务队列"中的事件，除了 IO 设备的事件以外，还包括一些用户产生的事件（比如鼠标点击、页面滚动等等）。只要指定过回调函数，这些事件发生时就会进入"任务队列”，等待主线程读取。
所谓"回调函数"（callback），就是那些会被主线程挂起来的代码。异步任务必须指定回调函数，当主线程开始执行异步任务，就是执行对应的回调函数。
"任务队列"是一个先进先出的数据结构，排在前面的事件，优先被主线程读取。主线程的读取过程基本上是自动的，只要执行栈一清空，"任务队列"上第一位的事件就自动进入主线程。但是，由于存在后文提到的"定时器"功能，主线程首先要检查一下执行时间，某些事件只有到了规定的时间，才能返回主线程。（我的理解，定时器在定时器线程执行完之后才会通过事件触发线程压入任务队列）
2.3 Event Loop
主线程从"任务队列"中读取事件，这个过程是循环不断的，所以整个的这种运行机制又称为 Event Loop（事件循环）。
上图中，主线程运行的时候，产生堆（heap）和栈（stack），栈中的代码调用各种外部 API，它们在"任务队列"中加入各种事件（click，load，done）。只要栈中的代码执行完毕，主线程就会去读取"任务队列"，依次执行那些事件所对应的回调函数。
执行栈中的代码（同步任务），总是在读取"任务队列"（异步任务）之前执行。请看下面这个例子
var req = new XMLHttpRequest();
req.open("GET", url);
req.onload = function() {};
req.onerror = function() {};
req.send();
上面代码中的 req.send 方法是 Ajax 操作向服务器发送数据，它是一个异步任务，意味着只有当前脚本的所有代码执行完，系统才会去读取"任务队列"。所以，它与下面的写法等价。
var req = new XMLHttpRequest();
req.open("GET", url);
req.send();
req.onload = function() {};
req.onerror = function() {};
也就是说，指定回调函数的部分（onload 和 onerror），在 send()方法的前面或后面无关紧要，因为它们属于执行栈的一部分，系统总是执行完它们，才会去读取"任务队列"。
看到这里，我想到了之前遇到的一个问题:关于 canvas.toDataURL 在 iOS 运行失败的问题
问题原因：就是 img 的 crossOrigin 属性与 src 属性赋值的顺序问题；在安卓和 windows 上，src 在 crossOrigin 属性之前赋值，画布是可以加载跨域图片的，而在 IOS 手机上，src 在 crossOrigin 属性之前赋值是无法加载的；
当时我还没理解为什么 src 一定要在 crossOrigin 之后赋值 IOS 才会加载跨域图片，画布成功画出图片；现在感觉有点思路，安卓和 IOS 微信浏览器基于的内核不同，导致对图片 src 的加载时机也不同。
在安卓手机上,src 赋值相当于 XmlHttpRequest 的 send，是一个异步事件，不管 crossOrigin 是在它之前还是之后赋值，它都会在执行栈执行完后执行；
而在 IOS 手机上，src 相当于一个同步事件，立即执行；
还是有很多疑惑，对这个解释还是有点牵强，希望哪位大佬可以指正下。
扫一扫
3180
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
