页面线程的循环系统是如何工作的，那接下来，我们继续探讨页面线程的一些特征。 页面线程所有执行的任务都来自于消息队列。消息队列是“先进先出”的属性，也就是说放入队列中的任务，需要等待前面的任务被执行完，才会被执行。鉴于这个属性，就有如下两个问题需要解决。
第一个问题是如何处理高优先级的任务。
比如一个典型的场景是监控 DOM 节点的变化情况(节点的插入、修改、删除等动态变 化)，然后根据这些变化来处理相应的业务逻辑。一个通用的设计的是，利用 JavaScript
设计一套监听接口，当变化发生时，渲染引擎同步调用这些接口，这是一个典型的观察者模式。
不过这个模式有个问题，因为 DOM 变化非常频繁，如果每次发生变化的时候，都直接调用相应的 JavaScript 接口，那么这个当前的任务执行时间会被拉长，从而导致执行效率的 下降。
如果将这些 DOM 变化做成异步的消息事件，添加到消息队列的尾部，那么又会影响到监控的实时性，因为在添加到消息队列的过程中，可能前面就有很多任务在排队了。
这也就是说，如果 DOM 发生变化，采用同步通知的方式，会影响当前任务的执行效率; 如果采用异步方式，又会影响到监控的实时性。
那该如何权衡效率和实时性呢?
针对这种情况，微任务就应用而生了，下面我们来看看微任务是如何权衡效率和实时性的。
通常我们把消息队列中的任务称为宏任务，每个宏任务中都包含了一个微任务队列，在执行宏任务的过程中，如果 DOM 有变化，那么就会将该变化添加到微任务列表中，这样就不会影响到宏任务的继续执行，因此也就解决了执行效率的问题。
等宏任务中的主要功能都直接完成之后，这时候，渲染引擎并不着急去执行下一个宏任务，而是执行当前宏任务中的微任务，因为 DOM 变化的事件都保存在这些微任务队列中，这样也就解决了实时性问题。
第二个是如何解决单个任务执行时长过久的问题。
因为所有的任务都是在单线程中执行的，所以每次只能执行一个任务，而其他任务就都处于 等待状态。如果其中一个任务执行时间过久，那么下一个任务就要等待很长时间。可以参考下图:
从图中你可以看到，如果在执行动画过程中，其中有个 JavaScript 任务因执行时间过久， 占用了动画单帧的时间，这样会给用户制造了卡顿的感觉，这当然是极不好的用户体验。针 对这种情况，JavaScript 可以通过回调功能来规避这种问题，也就是让要执行的 JavaScript 任务滞后执行。至于浏览器是如何实现回调功能的，我们在后面的章节中再详细介绍。
总结下今天所讲的内容。
如果有一些确定好的任务，可以使用一个单线程来按照顺序处理这些任务，这是第一版线程模型。
要在线程执行过程中接收并处理新的任务，就需要引入循环语句和事件系统，这是第二版线程模型。
如果要接收其他线程发送过来的任务，就需要引入消息队列，这是第三版线程模型。
如果其他进程想要发送任务给页面主线程，那么先通过 IPC 把任务发送给渲染进程的 IO 线程，IO 线程再把任务发送给页面主线程。
消息队列机制并不是太灵活，为了适应效率和实时性，引入了微任务。
基于消息队列的设计是目前使用最广的消息架构，无论是安卓还是 Chrome 都采用了类似的任务机制，所以理解了本篇文章的内容后，你再理解其他项目的任务机制也会比较轻松。
IO线程，用开负责和其它进程IPC通信的，然后主线程主要跑页面的。
