Has written an article before Js deep analyze the running mechanism, is primarily concerned with Js Event Loop mechanism (the Event Loop), from now, can’t say the wrong, but also absolutely not “deep” has not been young (who?), in the era of Js multi-homing today, it is necessary to stand in the perspective of a higher around each other
First, the home of the host
The host here refers to the running environment of JS. At present, the mainstream running environment of JS includes browser, Node and RN/Weex
This article describes the event cycle mechanism is basically clear, but does not peel out Js itself and the host part. Until now, most of our discussion of Js has been browser-based (by default), and it doesn’t seem to matter if we don’t peel it off. Today, if we want to extend our Js capabilities to back-end nodes, RN/Weex, and peel it off, it will give you a sense of control
Start with a comparison of the basic components of each host environment
In my last two articles, I have made a comparison of the three host environments (and probably more detailed), which can be summarized from the vantage point of this article:
Each host contains a javascript engine for executing JS, v8 being the most widely used, and each reads IO through an intermediate layer. In the front end (browser /RN/Weex), each host also contains an interface rendering engine, that is, the basic language capabilities of JS, Mainly supported by Js engine (V8 /javascriptCore, etc.), such as array, function, object and other basic syntax; IO read and write, interface rendering Api, all belong to the host extension, coordinated by the host scheduling
For example, in the browser, Js can call Dom Api to manipulate THE Html Dom, thus affecting the rendering tree, which is actually the browser extension of Js Api, and through the middle layer to coordinate the communication between THE Js engine and the rendering kernel; In Node, there are no Dom APIS and window objects. In Node, there are no Dom apis and window objects. Because Node hosts the backend, there is no interface rendering engine at all
For the communication between the host shell and Js engine, take Node as an example, Node environment written by C/C ++, which embedded a Js engine V8 (of course V8 is written with C/C ++), the whole communication process, is c++ on v8 call process. To support asynchronous I/O reading and writing of Js, the host also builds an event loop and thread pool for it, which will be explained later
Two, read and write IO
A computer can be abstracted into a computing unit (CPU) and an input/output unit (IO). Browsers, Nodes, and RN/Weex all need to schedule CPU and IO usage to maximize efficiency. If the front-end rendering elements as read and write to the graphics card, then the difference between each host can actually be abstracted to IO capability support
Javascript IO read and write ability depends on the host of the sandbox to its extension, browser extension Dom Api can make Js easy to operate rendering elements, and in the disk read and write above, Node is much more convenient than the browser; Node can control the network card to open an Http Server, but the browser does not provide this capability. Really, it’s not that complicated
The difference between hosts is mainly reflected in the expansion of IO read and write capabilities
No matter blocking OR non-blocking IO, there is a thread waiting process, every second of waiting is a huge waste of CPU, so almost all high-level languages in the IO read, will create a special listening thread for WAITING for THE IO read. However, you must have heard that Js is a single-threaded language, but its asynchronous mechanism is a good solution to the IO waiting process. In fact, this single thread only means that Js has a unique user thread, that is, the piece of Js code thrown into V8 is single threaded, and the host environment has created a thread pool so that Js can use the CPU more efficiently during the IO reading process. The use of event loop mechanism to support the asynchronous ability of Js, at this point, each host between the same path ~~
3. Realization mechanism of asynchrony
A similar diagram was drawn in the article on how Js works, with a few minor changes, enclosing the thread pool and the Js engine section (see the previous article for more details on event loops).
We say at ordinary times the Js is single-threaded, is it only a single thread of execution (user thread), which is above the lower right corner of Js engine parts, but from the entire host level, also need to maintain a thread pool, asynchronous I/o calls, every time will be posted in a thread pool to find an available thread, used to monitor and wait for the IO read, After the IO is read, the callback function is pushed into the event loop, and the Js execution thread pops the callback function and its execution context one at a time to execute
In particular, in addition to the IO reading is asynchronous, timing functions (such as setTimeout) are also asynchronous, the timing thread needs to timely press the callback into the event loop, after the Js execution thread completes the current task, and then pop out of the event loop to execute. So setTimeout is not always that punctual
Four,
Technically, if you limit yourself too much, you will always have a feeling that you are only in the mountain. If you sublimate it and look at it from a distance, you may see it more comprehensively
Feimai front end is a knowledge community to let knowledge go deep into the principle, we have knowledge planet, public account and group, welcome to add micro hook up: Facemagic2014