Let's talk about JavaScript threads and JavaScript threads.
Code judgment 1:
<div id="div"> click me</div><script> var div=document.getElementById("div"); div.addEventListener('click',function(){ alert('You have clicked me!'); }); for(var i =0; i<999999999;i++){ console.log(i); }</script>
When executed, all browsers will be stuck, because the preceding for loop is too many times, which consumes CPU resources. Based on the fact that JavaScript is single-threaded, the browser UI rendering is suspended, leading to false positives.
Now the question is, what should I do if I want to implement the above Code?
Concurrent. Thread. js
This class library uses setTimeout to implement a "fake multi-thread ". It was a good choice before HTML5 WebWorker came into existence. For example, to implement the above "code snippet 1", you can write it like this (Click here to download the class library ):
Code snippet 2:
<div id="div"> click me</div><script src="Concurrent.Thread.js"></script><script> Concurrent.Thread.create(function(){ var div=document.getElementById("div"); div.addEventListener('click',function(){ alert('You have clicked me!'); }); for(var i =0; i<9999999;i++){ console.log(i); } });</script>
You can use the create method provided by this class library to create a "new thread ". In addition, setting the type attribute of the script tag to text/x-script.multithreaded-js also achieves the same effect:
Code snippet 3:
<div id="div"> click me</div><script src="Concurrent.Thread.js"></script><script type="text/x-script.multithreaded-js"> var div=document.getElementById("div"); div.addEventListener('click',function(){ alert('You have clicked me!'); }); for(var i =0; i<9999999;i++){ console.log(i); }</script>
WebWorker
In view of the poor user experience caused by the above browser crashes, how can HTML5 become invisible?
Next we will use the classic Fibonacci series for testing:
Code snippet 4:
Home page:
<Div id = "div"> </div> <script> window. onload = function () {var div = document. getElementById ("div"); if (typeof (Worker )! = "Undefined") {// determine whether the browser supports console before creating a WebWorker. log ("Start calculating .... "); var time1 = new Date () * 1; // obtain the current timestamp var worker = new Worker (" fibonacci. js "); // create a WebWorker object and pass the worker path of the script to be executed in the new thread. onmessage = function (e) {// listen to the data div sent from the new thread. innerHTML = e. data; var time2 = new Date () * 1; console. log ("time spend:" + (time2-time1) + "ms");} worker. postMessage (36); // send data to the new thread} else {alert ("Your browser do not supp Ort WebWoker ") ;}}</script> maid. js: var maid = function (n) {return n <3? N :( arguments. callee (n-1) + arguments. callee (n-2);} onmessage = function (e) {var num = parseInt (e. data, 10); postMessage (maid (num); // send data to the home page}
The basic usage has been commented out in the Code. Check the console and you can see that the execution time is printed soon. So we come to the conclusion that WebWorker is suitable for executing complex computing on the front end. It should be noted that WebWorker does not support cross-origin, and http is used for local testing. Do not use the file protocol. Otherwise, a script error is reported because the Worker object cannot be created.
If we need to execute multiple postMessage operations consecutively, we 'd better not keep writing work. postMessage, like this:
worker.postMessage(36); worker.postMessage(36); worker.postMessage(36);
Because there is only one WebWorker instance at this time, the postMessage will be executed in sequence instead of asynchronously, so it cannot fully utilize its performance. You can create multiple WebWorker instances to send data.
Note the following:
1. We observe that WebWorker creates a worker by accepting a url, and jsonp is implemented by dynamically inserting script tags to load data, isn't it better to try WebWorker to achieve the same thing? Because WebWorker is multi-threaded and has no blocking, isn't it beautiful? However, after experiment, we found that WebWorker is not doing well. So this is not what it is good at. We should not make it better.
2. When WebWorker accepts information from other sources, it also brings security risks to the site. If it receives script information from unknown sources, it may cause XSS injection attacks. Therefore, we need to prevent this. In fact, the use of innerHTML in the above example is not safe. You can use innerText or textContent provided by modern browsers to filter out html tags.
I'm tired today. I want to go to bed. Write so much first.