Please read the following code and guess the execution result:
var start = new Date;setTimeout(function(){ console.log('Time passes:'+(new Date - start)+'msec');}, 200); while (new Date - start < 1000) {}console.log(1);function doSoming(){ setTimeout(function(){ console.log('Time passes again:'+(new Date - start)+'msec'); },10);}doSoming(); while (new Date - start < 2000) {}console.log(2);turn out:
Output after about 1 second: 1,
After about 1 second, the output is: 2.
Then immediately output: Time passed: 2002 milliseconds
Last output: Time passed again: 2003 milliseconds
Have you guessed it right?
Here, all functions that delay execution by setTimeout are pushed to the end before execution;
The principle is as follows:
In the existing browser environment, the Javascript execution engine is single-threaded. The main thread's statements and methods will block the run of the timing tasks. Outside the Javascript execution engine, there is a task queue. When the setTimeout() method is called in the code, the registered delay method will be hung to other modules in the browser kernel for processing. When the delay method reaches the trigger condition, that is, the set delay time reaches the set, the module will add the method to be executed to the task queue of the module. This process is independent of the main thread of the execution engine. The execution engine will extract tasks from the task queue of the module in sequence to execute when the main thread method is executed and reaches the idle state. The time during this period may be greater than the delay time set when registering the task;
When the browser is idle, it will constantly try to extract tasks from the module's task queue, which is called the event loop model;
Let’s look back at the previous code. The delay time of the second setTimeout() delay method is 10 milliseconds, which is triggered earlier than the first one! Why is the execution result behind? Because it was blocked by the previous code for about 1000.5~1001 milliseconds (depending on the browser's processing speed), when it hangs to the processing module and when the trigger time is added to the task queue, the first setTimeout() delay method has long been added to the module's task team, and the main engine thread is obtained in order, so, you should understand, right?
Now, if you change the above while (new Date - start < 1000) {} to while (new Date - start < 189) {} or while (new Date - start < 190) {}, what is the result? I won't say much! Refresh the browser 20 times each and see the results yourself!
The setInterval() method and setTimeout() have the same status. When the setInterval() method is called, the registered delay method is hung to the module for processing. Whenever the trigger time arrives, the method to be executed is added to the task queue once;
Let’s take a look at the syntax of setTimeout:
var timeID = window.setTimeout(func,delay,[param1,param2,...]);
var timeID = window.setTimeout(code,delay);
setTimeout and setInterval are methods of Window objects (window can be omitted). The second optional parameters (not supported by IE9 and old versions) are parameters passed to func. Each time they are called, a numeric ID will be returned (it is just a number printed in the browser, but I printed it in webstorm and found that it is actually an object with many attributes). This ID maintains the relevant information of its corresponding setTimeout or setInterval, and is mainly used to clear (or close) them in the middle module and the task queue (using the methods clearTimeout(ID) and clearInterval(ID)).
If you need to pass a parameter into your callback function, the following is the IE-compatible writing method
if (document.all && !window.setTimeout.isPolyfill) { var __nativeST__ = window.setTimeout; window.setTimeout = function (vCallback, nDelay, param1, param2, param3) { var aArgs = Array.prototype.slice.call(arguments, 2); return __nativeST__(vCallback instanceof Function ? function () { vCallback.apply(null, aArgs); } : vCallback, nDelay); }; window.setTimeout.isPolyfill = true;}A common error occurs when using closures in a loop
for(var i =0; i <10; i++){ setTimeout(function(){ console.log(i); },1000);}The above code will output the number 10 ten times. Why? Closure!
When console.log is called, although the anonymous function maintains a reference to the external variable i, the for loop has ended at this time and the value of i is modified to 10.
To get the desired result, a copy of the variable i needs to be created in each loop.
In order to get the loop number correctly, it is best to use an anonymous wrapper (actually what we usually call self-executing anonymous functions).
for(var i =0; i <10; i++){ (function(e){ setTimeout(function(){ console.log(e); },1000); })(i);}The external anonymous function will be executed immediately and i will be used as its parameter. At this time, the e variable in the function will have a copy of i.
When the anonymous function passed to setTimeout is executed, it has a reference to e, and this value will not be changed by the loop.
There is another way to do the same job; that is to return a function from an anonymous wrapper. This works the same as the above code.
for(var i =0; i <10; i++){ setTimeout((function(e){ return function(){ console.log(e); } })(i),1000)}Another important application: function throttle and function debounce
Please see some information I collected from the Internet:
JavaScript - Performance optimization function throttle and function debounce
Reference link:
https://developer.mozilla.org/zh-CN/docs/Web/API/Window/setTimeout
http://www.alloyteam.com/2015/10/turning-to-javascript-series-from-settimeout-said-the-event-loop-model/#prettyPhoto
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.