Web worker non-blocking UI technology, HTML5, unfortunately can't dare UI

As weall know, JavaScript is single-threaded , JS and UI updates share the same process in part because of frequent visits between them, but because the sharing of the same process will cause the JS code when the user clicks the interface element without any response to this situation, How could such a bad user experience HTML5 not be revised so that the Web worker was born.

When the Web worker process loads JS, it does not affect the browser UI, nor does it affect the JS code that is loaded by other web worker processes. Because the web worker process loading JS runtime does not affect the browser UI, it also means that the Web worker loading JS can not modify the user interface , and each Web worker has its own global environment, because it loaded JS can not modify the user interface , so the objects it can manipulate consist mainly of the following parts

• A browser object that contains only four properties: Appname,appversion,useragent,platform
• A Location object (as in window, but all of the properties are read-only)
• A self object points to the global web worker thread object
• A importscripts () method enables web worker to load external JS files
• All the ECMAScript objects
• XMLHttpRequest Constructors
• SetTimeout () and SetInterval () methods

Here is a importscript method, which is loaded with the blocking method JS, only after all the files are loaded, the next script can continue to run

In fact,WEB workers are suitable for long-running scripts that are purely data-or that are not related to the browser's UI.

The following is the most basic demo case, I believe you can see the smart

Simply create an HTML page with the page code shown below

<! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 transitional//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">

The code for the Webworker.js code loaded above is as follows:

OnMessage = function (event) {var data = event.data;//This is the received data console.log;//Note that there is no alert to replace Console.log because alert Is blocking the UI so Wobworker does not use the alert permission Oh postMessage (data + '---JS reply to come over the statistics Oh! '); /Here you can pass the data to the main thread oh}; onerror = function (event) {Console.log (' Error: ' + event.filename + ' (' + Event.lineno + '): ' + event.message ');//event.f Ilename Error file name//event.lineno error line number//event.message full error message}

So what is the main use of web workers, and what are the advantages of it, the following summary of HA

• Can load a JS for a large number of complex computations without suspending the main process and communicating through Postmessage,onmessage, using the Ternimate method to stop working
• Additional script files can be loaded in worker via Importscripts (URL)

Where is the main drawback?

• Cannot load JS across domains
• In-worker code cannot access the DOM
• Because it's a new API in HTML5, the browser support is different!

Web worker to load data is still slow, even if it is a large data volume without any advantage, it may be the worker initializes the new thread compared time. There is no advantage other than blocking during the loading process

Here is another example I wrote, mainly to play web worker's expertise

The HTML interface code looks like this

<! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 transitional//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">

The Fibonacci.js code loaded in the above code is shown below

var Fibonacci = function (n) {return n < 2? N:arguments.callee (n-1) + Arguments.callee (n-2);}; OnMessage = function (event) {var n = parseint (event.data), Console.log (' Pass-through value: ' +n '); PostMessage (Fibonacci (n));}; onerror = function (event) {Console.log (' Error: ' + event.filenme + ' (' + Event.lineno + '): ' + Event.message ');}

You can find the results of the chrome console after you run it as shown:

——————————————————————————————————————————————————————

The following example is more classic:

Main.html page is the main thread

<script>

Open a new thread

var worker = new Worker (' worker.js ');

Worker.postmessage (40);

Worker.onmessage = function (EV) {

Console.log (EV);

Worker.terminate ()//terminating a worker thread

};

</script>

The new thread opened by Worker.js

New Thread

Defining Recursive functions

var Fibonacci =function (N) {

return n <2? N:arguments.callee (n-1) + Arguments.callee (n-2);

};

OnMessage = function (EV) {

var param = parseint (ev.data,10);

The calculation of the Ark function is given to the new thread, and the result is passed back to the main course with PostMessage after the calculation is done.

PostMessage (Fibonacci (param))

}

This enables information interaction between the main thread and the newly opened threads. Complex computations are given to the worker.js. The page is not jammed. The new thread will pass the data back to the main thread (the feeling of a little asynchronous request) after processing the calculation.

Summarize our

Web worker non-blocking UI technology, HTML5, unfortunately can't dare UI