本文分享自微信公众号 - 编程微刊（wangxiaoting678）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

JavaScript 一文彻底理解并掌握ES5继承

继承的目的是什么？结果是什么？
子类继承父类，子类实例拥有和父类实例相同的属性

父类实例的属性来自于哪里？

1. 构造函数
2. 原型对象

因此继承的实现应该做到以下两件事情

1. 继承父类构造函数设置的属性： 借用父类构造函数使用apply/call绑定this为子类实例，使得子类实例具有父类实例相同属性
2. 继承父类的原型属性： 将父类的原型属性设置到子类原型上去，通过new关键字调用继承父类原型属性

原型继承

思路是继承将父类实例放在构造函数原型上，父类实例作为子类原型
缺陷是所有子类共用一个原型对象，引用类型属性的地址相同。
只继承了原型属性，但缺失了调用父类构造函数为子类实例设置属性的这一过程，导致继承的属性全部来自于原型

    function object(o){
        function F(){}
        F.prototype = o
        return new F()
    }

    const o = {a:[1,2,3]}
    const newO = object(o)
    newO.a.push(4)
    console.log(newO,o); // [1,2,3,4]
    

组合继承

原型继承+借用父类构造函数设置实例属性
用的最多，缺陷是调用了两次父类构造函数

    function SuperClass() { }
    function SubClass() {
        SuperClass.apply(this, Array.from(arguments)) // 借用构造函数
    }
    SubClass.prototype = new SuperClass() // 继承原型属性

寄生式继承

寄生式继承基于原型继承, 主要体现在给实例做拓展与与增强
缺陷在于增强实例的过程中不能做到函数复用，使得效率降低，这一点和构造函数设置实例属性是一致的

    function object(o){
        function F(){}
        F.prototype = o 
        const obj = new F()
        // 拓展、增强
        obj.fn = ()=>console.log('fn');
        return obj
    }

寄生组合式继承

寄生组合式继承解决了组合继承调用两次父类构造函数使得开销过大的问题

    function extend(SubClass, SuperClass) {
        function F() { }
        F.prototype = SuperClass.prototype
        SubClass.prototype = new F()

        SubClass.prototype.constructor = SubClass
        SubClass.SuperClass = SuperClass
    }

    // 使用
    function Child() {
        Child.SuperClass.apply(this, arguments)
    }
    function Parent() { this.a = 1 }

    extend(Child, Parent)
    console.log(new Child());

总结

原型继承，所有实例共用一个原型对象，继承了原型属性，但缺失了调用父类构造函数为子类实例设置属性的这一过程，导致继承的属性全部来自于原型，缺少了文章开头提到的第1点

组合继承，用的最多的方案，虽然1、2都满足，但是存在调用了两次父类构造函数的问题

寄生式继承，在原型继承的基础上，在实例创建的过程中给实例做拓展和增强，缺陷为并没有调用父类构造函数设置实例属性，复用性差，不满足1

寄生组合式继承，通过一个中间函数F，解决了组合继承中父类构造函数调用两次的问题；在子类实例创建过程中调用父类构造函数，解决了原型继承和寄生式继承中没有用父类构造函数为子类实例设置属性的问题。 1、2都满足。

Javascript中的执行机制——Event Loop

众所周知，Javascript是单线程语言， 这就意味着，所有的任务都必须按照顺序执行，只有等前面的一个任务执行完毕了，下一个任务才能执行。如果前面一个任务耗时很长，后一个任务就得一直等着，因此，为了实现主线程的不阻塞，就有了Event Loop。

1、javascript事件循环

首先，我们先了解一下同步任务和异步任务，同步任务指的是，在主线程上排队执行的任务，只有前一个任务执行完毕，才能执行后一个任务；异步任务指的是，不进入主线程、而进入"任务队列"（task queue）的任务，只有"任务队列"通知主线程，某个异步任务可以执行了，该任务才会进入主线程执行。

为了更好的了解执行机制，看下图

以上图说明主线程在执行的时候产生堆（内存分配）和堆栈（执行上下文），JavaScript是单线程的，意味着当执行环境的堆栈中的一个任务（task）在执行的时候，其它的任务都要处于等待状态。当主进程执行到异步操作的时候就会将异步操作对应的task放到event table,指定的事情完成时，Event Table会将这个函数移入Event Queue。主线程内的任务执行完毕为空，会去Event Queue读取对应的函数，进入主线程执行，因为这个过程是不断重复的，所以称为Event Loop(事件循环)，接下来，我们用几个例子进行分析
eg1:

console.log(1); 
setTimeout(function () { 
    console.log(2); 
})
 console.log(3);
 //执行结果：1、3、2

我们来分析一下这段代码，首先，根据执行上下文可知，执行环境栈中就有了一个task——console.log(1)，输出1。接着往下执行，因为setTimeout是异步函数，所以将setTimeout进入event table，注册了一个回调函数在event queue，我们暂且称为fun1，此时的流程如下图：

接着往下执行，执行环境栈中会创建一个console.log(3)的task，并执行它，输出3，此时，执行环境已经没有任务了，则去Event Queue读取对应的函数，fun1被发现，进入主线程输出2，整个过程已经完成，所以输出的结果是1、3、2。
eg2:

   setTimeout(function () {
      console.log(1)
   }, 3)
   setTimeout(function () {
      console.log(2)
    })
输出2,1

我们再来简单的分析一下这个列子，我们暂且称第一个setTimeout为Time1,第二个为Time2。由于两个都是异步函数，按照执行顺序，先将Time放到event Table，接着将Time移到event Table，因为Time在event Table指定要3秒后才执行，所以Time2先于Time1到注册回调函数到event queue，所以输出的结果是2,1。

2、macro-task(宏任务)、micro-task(微任务)

MacroTask: script(整体代码), setTimeout, setInterval, setImmediate（node独有）, I/O, UI rendering
MicroTask: process.nextTick（node独有）, Promises, Object.observe(废弃), MutationObserver

任务又分为宏任务和微任务两种，在同一个上下文中，总的执行顺序为“同步代码—>microTask—>macroTask”，根据上面event loop的流程图，我们用列子来做进一步的了解：
eg1:

   setTimeout(function () {
       console.log(1);
   },0);
   console.log(2);
   process.nextTick(() => {
       console.log(3);
   });
   new Promise(function (resolve, rejected) {
       console.log(4);
       resolve()
   }).then(res=>{
       console.log(5);
   })
   setImmediate(function () {
       console.log(6)
   })
   console.log(''end'');
    //输出2、4、end、3、5、1、6

本例参考《JavaScript中的执行机制》，里面有详细的解释，大家可以参考下。

3、优先级

我们将上面的例子稍微改一下，将process.nextTick移到promise的后面，看下面的代码：

setTimeout(function () {
       console.log(1);
   },0);
   console.log(2);
   new Promise(function (resolve, rejected) {
       console.log(4);
       resolve()
   }).then(res=>{
       console.log(5);
   })
 process.nextTick(() => {
       console.log(3);
   });
   setImmediate(function () {
       console.log(6)
   })
   console.log(''end'');

按照前面的分析，先执行同步代码，先输出“2,4，end”；然后是微任务promise输出5，process.nextTick输出3；最后的宏任务输出1,6。所以结果为2,4，end,5,3,1,6，然后事实并非如此，结果还是输出2、4、end、3、5、1、6，这是因为process.nextTick注册的函数优先级高于Promise**。
关于Event Loop的其他特殊情况，大家可参考文章一篇文章教会你Event loop——浏览器和Node和Event Loop的规范和实现，里面有更详细的介绍。

4、补充

    console.log(1)
    
    setTimeout(() => {
        console.log(2)
        new Promise(resolve => {
            console.log(4)
            resolve()
        }).then(() => {
            console.log(5)
        })
        setTimeout(() => {
            console.log(999)
        
        })
    })
    
    new Promise(resolve => {
        console.log(7)
        resolve()
    }).then(() => {
        console.log(8)
    })
    
    setTimeout(() => {
        console.log(9)
        new Promise(resolve => {
            console.log(11)
            resolve()
        }).then(() => {
            console.log(12)
        })
    })
    

JavaScript定时器与执行机制

JS执行机制

浏览器（或者说JS引擎）执行JS的机制是基于事件循环。

由于JS是单线程，所以同一时间只能执行一个任务，其他任务就得排队，后续任务必须等到前一个任务结束才能开始执行。

为了避免因为某些长时间任务造成的无意义等待，JS引入了异步的概念，用另一个线程来管理异步任务。

 

JS定时器

JS的定时器目前有三个：setTimeout、setInterval和setImmediate。

定时器也是一种异步任务，通常浏览器都有一个独立的定时器模块，定时器的延迟时间就由定时器模块来管理，当某个定时器到了可执行状态，就会被加入主线程队列。

JS定时器非常实用，做动画的肯定都用到过，也是最常用的异步模型之一。

有时候一些奇奇怪怪的问题，加一个setTimeout(fn, 0)（以下简写setTimeout(0)）就解决了。不过，如果对定时器本身不熟悉，也会产生一些奇奇怪怪的问题。

 

setTimeout

setTimeout(fn, x)表示延迟x毫秒之后执行fn。

使用的时候千万不要太相信预期，延迟的时间严格来说总是大于x毫秒的，至于大多少就要看当时JS的执行情况了。

另外，多个定时器如不及时清除（clearTimeout），会存在干扰，使延迟时间更加捉摸不透。所以，不管定时器有没有执行完，及时清除已经不需要的定时器是个好习惯。

HTML5规范规定最小延迟时间不能小于4ms，即x如果小于4，会被当做4来处理。 不过不同浏览器的实现不一样，比如，Chrome可以设置1ms，IE11/Edge是4ms。

setTimeout注册的函数fn会交给浏览器的定时器模块来管理，延迟时间到了就将fn加入主进程执行队列，如果队列前面还有没有执行完的代码，则又需要花一点时间等待才能执行到fn，所以实际的延迟时间会比设置的长。如在fn之前正好有一个超级大循环，那延迟时间就不是一丁点了。

结果是：setTimeout: 335.187ms，远远不止10ms。

 

setInterval

setInterval的实现机制跟setTimeout类似，只不过setInterval是重复执行的。

对于setInterval(fn, 100)容易产生一个误区：并不是上一次fn执行完了之后再过100ms才开始执行下一次fn。 事实上，setInterval并不管上一次fn的执行结果，而是每隔100ms就将fn放入主线程队列，而两次fn之间具体间隔多久就不一定了，跟setTimeout实际延迟时间类似，和JS执行情况有关。

输出

可见，虽然每次fn执行时间都很长，但下一次并不是等上一次执行完了再过100ms才开始执行的，实际上早就已经等在队列里了。

另外可以看出，当setInterval的回调函数执行时间超过了延迟时间，已经完全看不出有时间间隔了。

如果setTimeout和setInterval都在延迟100ms之后执行，那么谁先注册谁就先执行回调函数。

 

setImmediate

这算一个比较新的定时器，目前IE11/Edge支持、Nodejs支持，Chrome不支持，其他浏览器未测试。

从API名字来看很容易联想到setTimeout(0)，不过setImmediate应该算是setTimeout(0)的替代版。

在IE11/Edge中，setImmediate延迟可以在1ms以内，而setTimeout有最低4ms的延迟，所以setImmediate比setTimeout(0)更早执行回调函数。不过在Nodejs中，两者谁先执行都有可能，原因是Nodejs的事件循环和浏览器的略有差异。

Edge输出：setImmediate: 0.555 毫秒

很明显，setImmediate设计来是为保证让代码在下一次事件循环执行，以前setTimeout(0)这种不可靠的方式可以丢掉了。

 

其他常用异步模型

requestAnimationFrame

requestAnimationFrame并不是定时器，但和setTimeout很相似，在没有requestAnimationFrame的浏览器一般都是用setTimeout模拟。

requestAnimationFrame跟屏幕刷新同步，大多数屏幕的刷新频率都是60Hz，对应的requestAnimationFrame大概每隔16.7ms触发一次，如果屏幕刷新频率更高，requestAnimationFrame也会更快触发。基于这点，在支持requestAnimationFrame的浏览器还使用setTimeout做动画显然是不明智的。

在不支持requestAnimationFrame的浏览器，如果使用setTimeout/setInterval来做动画，最佳延迟时间也是16.7ms。 如果太小，很可能连续两次或者多次修改dom才一次屏幕刷新，这样就会丢帧，动画就会卡；如果太大，显而易见也会有卡顿的感觉。

有趣的是，第一次触发requestAnimationFrame的时机在不同浏览器也存在差异，Edge中，大概16.7ms之后触发，而Chrome则立即触发，跟setImmediate差不多。按理说Edge的实现似乎更符合常理。

Edge输出：requestAnimationFrame: 16.66 毫秒

Chrome输出：requestAnimationFrame: 0.698ms

但相邻两次requestAnimationFrame的时间间隔大概都是16.7ms，这一点是一致的。当然也不是绝对的，如果页面本身性能就比较低，相隔的时间可能会变大，这就意味着页面达不到60fps。

 

Promise

Promise是很常用的一种异步模型，如果我们想让代码在下一个事件循环执行，可以选择使用setTimeout(0)、setImmediate、requestAnimationFrame(Chrome)和Promise。

而且Promise的延迟比setImmediate更低，意味着Promise比setImmediate先执行。

Edge输出：Promise: 0.33 毫秒 setImmediate: 1.66 毫秒

尽管setImmediate的回调函数比Promise先注册，但还是Promise先执行。

可以肯定的是，在各JS环境中，Promise都是最先执行的，setTimeout(0)、setImmediate和requestAnimationFrame顺序不确定。

 

process.nextTick

process.nextTick是Nodejs的API，比Promise更早执行。

事实上，process.nextTick是不会进入异步队列的，而是直接在主线程队列尾强插一个任务，虽然不会阻塞主线程，但是会阻塞异步任务的执行，如果有嵌套的process.nextTick，那异步任务就永远没机会被执行到了。

使用的时候要格外小心，除非你的代码明确要在本次事件循环结束之前执行，否则使用setImmediate或者Promise更保险。

JavaScript定时器与执行机制解析

从JS执行机制说起

浏览器（或者说JS引擎）执行JS的机制是基于事件循环。

由于JS是单线程，所以同一时间只能执行一个任务，其他任务就得排队，后续任务必须等到前一个任务结束才能开始执行。

为了避免因为某些长时间任务造成的无意义等待，JS引入了异步的概念，用另一个线程来管理异步任务。

同步任务直接在主线程队列中顺序执行，而异步任务会进入另一个任务队列，不会阻塞主线程。等到主线程队列空了（执行完了）的时候，就会去异步队列查询是否有可执行的异步任务了（异步任务通常进入异步队列之后还要等一些条件才能执行，如ajax请求、文件读写），如果某个异步任务可以执行了便加入主线程队列，以此循环。

 

JS定时器

JS的定时器目前有三个：setTimeout、setInterval和setImmediate。

定时器也是一种异步任务，通常浏览器都有一个独立的定时器模块，定时器的延迟时间就由定时器模块来管理，当某个定时器到了可执行状态，就会被加入主线程队列。

JS定时器非常实用，做动画的肯定都用到过，也是最常用的异步模型之一。

有时候一些奇奇怪怪的问题，加一个setTimeout(fn, 0)（以下简写setTimeout(0)）就解决了。不过，如果对定时器本身不熟悉，也会产生一些奇奇怪怪的问题。

setTimeout

setTimeout(fn, x)表示延迟x毫秒之后执行fn。

使用的时候千万不要太相信预期，延迟的时间严格来说总是大于x毫秒的，至于大多少就要看当时JS的执行情况了。

另外，多个定时器如不及时清除（clearTimeout），会存在干扰，使延迟时间更加捉摸不透。所以，不管定时器有没有执行完，及时清除已经不需要的定时器是个好习惯。

HTML5规范规定最小延迟时间不能小于4ms，即x如果小于4，会被当做4来处理。 不过不同浏览器的实现不一样，比如，Chrome可以设置1ms，IE11/Edge是4ms。

setTimeout注册的函数fn会交给浏览器的定时器模块来管理，延迟时间到了就将fn加入主进程执行队列，如果队列前面还有没有执行完的代码，则又需要花一点时间等待才能执行到fn，所以实际的延迟时间会比设置的长。如在fn之前正好有一个超级大循环，那延迟时间就不是一丁点了。

(function testSetTimeout() {
const label = ''setTimeout'';
console.time(label);
setTimeout(() => {
console.timeEnd(label);
}, 10);
for(let i = 0; i < 100000000; i++) {}
})();

setInterval结果是：setTimeout: 335.187ms，远远不止10ms。

setInterval

setInterval的实现机制跟setTimeout类似，只不过setInterval是重复执行的。

对于setInterval(fn, 100)容易产生一个误区：并不是上一次fn执行完了之后再过100ms才开始执行下一次fn。 事实上，setInterval并不管上一次fn的执行结果，而是每隔100ms就将fn放入主线程队列，而两次fn之间具体间隔多久就不一定了，跟setTimeout实际延迟时间类似，和JS执行情况有关。

(function testSetInterval() {
    let i = 0;
    const start = Date.now();
    const timer = setInterval(() => {
        i += 1;
        i === 5 && clearInterval(timer);
        console.log(`第${i}次开始`, Date.now() - start);
        for(let i = 0; i < 100000000; i++) {}
        console.log(`第${i}次结束`, Date.now() - start);
    }, 100);
})();

第1次开始 100 第1次结束 1089 第2次开始 1091 第2次结束 1396 第3次开始 1396 第3次结束 1701 第4次开始 1701 第4次结束 2004 第5次开始 2004 第5次结束 2307

可见，虽然每次fn执行时间都很长，但下一次并不是等上一次执行完了再过100ms才开始执行的，实际上早就已经等在队列里了。输出

另外可以看出，当setInterval的回调函数执行时间超过了延迟时间，已经完全看不出有时间间隔了。

如果setTimeout和setInterval都在延迟100ms之后执行，那么谁先注册谁就先执行回调函数。

setImmediate

这算一个比较新的定时器，目前IE11/Edge支持、Nodejs支持，Chrome不支持，其他浏览器未测试。

从API名字来看很容易联想到setTimeout(0)，不过setImmediate应该算是setTimeout(0)的替代版。

在IE11/Edge中，setImmediate延迟可以在1ms以内，而setTimeout有最低4ms的延迟，所以setImmediate比setTimeout(0)更早执行回调函数。不过在Nodejs中，两者谁先执行都有可能，原因是Nodejs的事件循环和浏览器的略有差异。

(function testSetImmediate() {
    const label = ''setImmediate'';
    console.time(label);
    setImmediate(() => {
        console.timeEnd(label);
    });
})();

很明显，setImmediate设计来是为保证让代码在下一次事件循环执行，以前setTimeout(0)这种不可靠的方式可以丢掉了。Edge输出：setImmediate: 0.555 毫秒

 

其他常用异步模型

 

requestAnimationFrame

requestAnimationFrame并不是定时器，但和setTimeout很相似，在没有requestAnimationFrame的浏览器一般都是用setTimeout模拟。

requestAnimationFrame跟屏幕刷新同步，大多数屏幕的刷新频率都是60Hz，对应的requestAnimationFrame大概每隔16.7ms触发一次，如果屏幕刷新频率更高，requestAnimationFrame也会更快触发。基于这点，在支持requestAnimationFrame的浏览器还使用setTimeout做动画显然是不明智的。

在不支持requestAnimationFrame的浏览器，如果使用setTimeout/setInterval来做动画，最佳延迟时间也是16.7ms。 如果太小，很可能连续两次或者多次修改dom才一次屏幕刷新，这样就会丢帧，动画就会卡；如果太大，显而易见也会有卡顿的感觉。

有趣的是，第一次触发requestAnimationFrame的时机在不同浏览器也存在差异，Edge中，大概16.7ms之后触发，而Chrome则立即触发，跟setImmediate差不多。按理说Edge的实现似乎更符合常理。

(function testRequestAnimationFrame() {
    const label = ''requestAnimationFrame'';
    console.time(label);
    requestAnimationFrame(() => {
        console.timeEnd(label);
    });
})();

Chrome输出：requestAnimationFrame: 0.698msEdge输出：requestAnimationFrame: 16.66 毫秒

但相邻两次requestAnimationFrame的时间间隔大概都是16.7ms，这一点是一致的。当然也不是绝对的，如果页面本身性能就比较低，相隔的时间可能会变大，这就意味着页面达不到60fps。

Promise

Promise是很常用的一种异步模型，如果我们想让代码在下一个事件循环执行，可以选择使用setTimeout(0)、setImmediate、requestAnimationFrame(Chrome)和Promise。

而且Promise的延迟比setImmediate更低，意味着Promise比setImmediate先执行。

function testSetImmediate() {
    const label = ''setImmediate'';
    console.time(label);
    setImmediate(() => {
        console.timeEnd(label);
    });
}
function testPromise() {
    const label = ''Promise'';
    console.time(label);
    new Promise((resolve, reject) => {
        resolve();
    }).then(() => {
        console.timeEnd(label);
    });
}
testSetImmediate();
testPromise();

尽管setImmediate的回调函数比Promise先注册，但还是Promise先执行。Edge输出：Promise: 0.33 毫秒 setImmediate: 1.66 毫秒

可以肯定的是，在各JS环境中，Promise都是最先执行的，setTimeout(0)、setImmediate和requestAnimationFrame顺序不确定。

process.nextTick

process.nextTick是Nodejs的API，比Promise更早执行。

事实上，process.nextTick是不会进入异步队列的，而是直接在主线程队列尾强插一个任务，虽然不会阻塞主线程，但是会阻塞异步任务的执行，如果有嵌套的process.nextTick，那异步任务就永远没机会被执行到了。

使用的时候要格外小心，除非你的代码明确要在本次事件循环结束之前执行，否则使用setImmediate或者Promise更保险。

关于一文彻底吃透 JavaScript 的执行机制和javascript的执行原理的介绍已经告一段落，感谢您的耐心阅读，如果想了解更多关于JavaScript 一文彻底理解并掌握ES5继承、Javascript中的执行机制——Event Loop、JavaScript定时器与执行机制、JavaScript定时器与执行机制解析的相关信息，请在本站寻找。

本文标签：

• JavaScript执行机制
• JavaScript原理
• 执行原理
• 代码运行机制