在js任务循环机制中，为什么会有宏任务与微任务之分？
是不是大都数前端开发者都会有这样的疑惑，确实，我自己在开发的过程中每次碰到promise，setTimeout，requestAnimationFrame都会去想，在这个执行的过程中到底发生了什么？
解析：
在前端执行一系列任务的时候，渲染进程会创建一个消息队列，在这个消息队列里存放着待执行的任务函数，按照先进先出的原则，依次执行任务函数。因此只要消息队列里有任务，JS执行主线程就会不断的执行消息队列里的任务。这便是js单线程执行js代码的简单原理，当然涉及的深的话，应该还要有IO线程，专门处理新加进来的任务，以及其它进程过来的任务。
但是js执行过程作为一个单线程的执行过程，其实是有缺点的。上面说过了，消息队列是“先进先出”的属性，也就是说放入队列中的任务，需要等待前面的任务被执行完，才会被执行。鉴于这个属性，那js是如何处理高优先级的任务？
js是如何处理高优先级的任务？
比如一个典型的场景，DOM节点的变化，增、删，改，如果页面上的一个输入框状态需要实时的映射到页面上。一个通用的设计的是，利用 JavaScript 设计一套监听接口，当变化发生时，渲染引擎同步调用这些接口，这是一个典型的观察者模式，即给这个输入框添加一个变化事件的监听。
但是这个模式有一个问题，就是如果当前的DOM变化非常的频繁，都去执行js任务的话，会导致当前在执行的js任务被延长，从而导致执行效率的下降;如果把这些任务添加到消息队列的尾部，则无法及时响应用户的操作。要想兼容这两种情况，微任务便应运而生了。
通常我们把消息队列中的任务称为宏任务，每个宏任务中都包含了一个微任务队列，在执行宏任务的过程中，如果 DOM 有变化，那么就会将该变化添加到微任务列表中，这样就不会影响到宏任务的继续执行，因此也就解决了执行效率的问题。
等宏任务中的主要功能都直接完成之后，这时候，渲染引擎并不着急去执行下一个宏任务，而是执行当前宏任务中的微任务，因为 DOM 变化的事件都保存在这些微任务队列中，这样也就解决了实时性问题。
这便是在js执行过程中为什么会有微任务与宏任务之分的原因。
文章转自 浏览器执行js原理 , https://www.xiaye0.com/articlejs?id=40
