试着讲清楚：js代码运行机制

一、 js运行机制

js执行引擎

经常看文章的说到js是带线程的，其实这个说法非常的模糊，准确的是js执行引擎是单线程的，js执行引擎就是js代码的执行器，有了这个概念就可以下来说说js是如何运行的了。

js代码如何运行？

在js代码执行的时候，js的代码是按照顺序执行的，从上到下，这个时候是同步的，不过，有几个例外：

• 异步的网络请求
• 事件绑定、事件监听器
• 时间触发函数

我们模拟一下，js引擎遇到这三类代码的情况：

1. js执行的好好的，正在顺序执行代码，这个时候呢，遇到了异步的网络请求的代码，这个时候，直接js代码调用之后，就继续执行之后的js代码了，并没有等待网络请求的结果，js代码执行是单线程的（不考虑h5），那么肯定异步网络请求调用之后，肯定不是js执行引擎管理了，问题一：谁在等待，谁之后通知js执行引擎结果，毕竟是js代码就得js引擎是执行。

2. 有了第一个问题，我们已经知道肯定有其它的东西参与了上面的事情了，先放着，之后呢js有欢乐的往下执行，遇到了事件绑定和事件监听函数，哦，这个js调用之后，也是继续往下走的，并没有调用那些函数之类的，我们知道，事件函数只有在事件触发的时候会起作用，js代码js执行引擎执行。那么问题二：谁把事件关联的函数保存的，以便接收事件触发选择正确的事件处理函数，通知js执行引擎？

3. js在遇到setTimeout和setInternal函数的时候，也是不直接执行，然后处理之后的代码的，那么问题三：谁在监视时间流逝选择合适的触发函数通知js引擎执行的？

以上3点是在自己学习js的运行机制和js执行引擎的时候，遇到了3个问题，那么3个问题其中的js执行js代码，但是监视肯定不是js执行引擎，答案如下：

1. 异步网络请求线程
2. 事件触发线程
3. 定时触发器线程

以上3个线程是独立于js引擎之外，帮助处理这3类代码的，所以啊，千万不要认为js引擎什么都做，加上gui渲染线程，js执行引擎线程，5个线程齐了。

以上我们了解了js执行的代码和3个额外的线程协助下，js执行代码构建了完备的环境了，但是js执行引擎是如何执行这3类线程给的函数的，答案是队列（暂且叫做Message Queue），3个线程选择好了需要执行的函数之后，会进行包装成一个结构（消息），放到队列里面，js执行玩代码之后，会循环的在这个队列里面取消息，取到了，那么就执行，取不到了就等待。

以上的一个执行结构，那么我们就可以得出一个结论，js在遇到3类代码的时候，一定滞后于同步代码的，因为同步代码执行完成之后，js才会从队列中取一条消息，来执行，并且执行完成之后才会再取一条。

以上也就是为什么时间处理函数总是在同步代码之后执行的原因，异步网络请求的回调函数也在同步代码执行完成之后调用的原理，就是因为这3类函数被3类线程放到了队列里了，而队列里面的代码在js执行完同步代码之后才能执行。

setTimeout为什么不能恰到好处的执行呢，这是因为定时触发器线程只是在时间到了之后，把应该执行的函数进行封装放到队列里面而已，具体什么时候执行还得看之前队列含有多少消息没有被处理。

二、gui渲染线程与js执行引擎的交互机制

上面说了3个执行线程与js执行引擎的交互，这个基本上没有问题了，这下说说渲染与js代码之间的交互。

在写js代码初期，肯定遇到过js代码执行性能问题，然后页面直接就不动弹了，这个时候其实可以得出来一个结论，js执行的时候，渲染线程是阻塞的，之后查了资料，发现这个定义更准确的说法是：js执行引擎的线程和gui渲染线程是互斥的。

这也能解释为什么js执行时间长后渲染不动的问题了。那么一个新的问题来了，如果是这样的话，那么渲染引擎肯定就不能渲染，至少在js队列不空的情况下，根本没有机会渲染的，那么就可以做一个代码不断的使用setInternal不断的往队列里面填消息。事实真的是这样吗？

肯定不是这样的，实际的浏览器没有是这样的，那么到底是哪块让js引擎和gui执行引擎的线程进行切换的，同步代码肯定不行，那么就是队列这块了，肯定不是队列为空的情况切换的，因为实际的js代码在改了之后基本上就渲染了，那么基本上确定，是在每一次消息之间执行的，因为js代码在执行的时候是同步的，做了这个假设之后，再查了大量的资料，有一篇文章是这样描述的，在每次执行完一个消息之后，马上切换到渲染线程执行渲染效果，然后渲染完成再切换js代码执行取下一个消息。

至此渲染和js代码执行的交互就了解了。（渲染线程是每次都需要切换的吗？这个已经属于性能优化内容了，就暂时不了解了）