[4] chrome UI rendering 1. Chrome's window control chrome provides its own UI control library. For more information, see here. In Chrome's own words, I felt that the library of the seven million and eight million elements on the market was not easy to use, so I made a great effort to implement one... Even though the advertisement said so, I haven't found anything very special about Chrome's graphical control structure. Chrome controls such as Windows, buttons, and menus are derived directly or indirectly from
View This is the control base class.
Chrome view has a tree structure Which has a sub-view array, which forms a common combination mode of controls... There is a special view subclass called
Rootview As the name suggests, it is the root of the entire view Control tree. In Chrome, a correct tree-like control structure must be rooted by rootview. The reason for this design is that rootview has a special function, that is, sending messages separately... We know that common Windows controls all have an hwnd, which occupies a screen and captures system messages. In Chrome, the view only saves the control information and draws the control. There is no hwnd handle in it, so it cannot capture system messages. In Chrome, the complete control architecture is like this. First,
Viewcontainer Which contains a rootview. Viewcontainer is an abstract class, And a subclass in window is
Hwndviewcontainer At the same time, hwndviewcontainer is a subclass of messageloopforui: observer. If you have read the thread communication content described in the first part of this article, you should remember that the observer is used to listen to system messages in this thread... When a system message enters the message loop of this thread, hwndviewcontainer will listen to this situation. If the message is related to the view, it will call the related methods of rootview and pass it to the control. In the rootview, the controls on the entire control tree are traversed to pass messages to each control. Of course, some messages can be exclusive. For example, if you move the mouse and send messages within the scope of a view, it will inform rootview (return value through method ...), I want this message, then rootview will stop traversing... During design,
View processes messages in a large and comprehensive interface mode. . That is to say, within the view, all possible message processing interfaces are provided and the default implementation is provided. All subclasses only need to overwrite the message processing functions they need. If you know the message ing of MFC, you can know the difference between the two. When designing MFC, we felt that it was impossible to provide a large and comprehensive interface. because there were too many message classes and they were still scalable, we had to map a set of tedious macros to messages. However, Chrome's graphic framework clearly does not have a general framework. Therefore, this policy can be used to make subclass derivation simple and natural... Each view subclass control, such as a button, stores some data, performs some behavior based on the message, and draws itself. In Chrome, the painting class is chromecanvas. inside it,
Draw using skia and GDI . Skia is a cross-platform graphics engine developed by the android team. In Chrome, it is responsible for drawing all content except text. In Windows, the heavy burden of text painting is handed over to GDI. This design will bring some difficulties to the cross-platform. It is estimated that text rendering by skia will be complicated to bring out such a design pattern... Another legacy product of history is the graphical controls in windows, and some are native, that is, the traditional controls with hwnd, which are traces of Chrome's short schedule, with the ample time, such native controls will be eliminated into the garbage bin of history, and all will become controls derived from view... In fact, I am not very familiar with Chrome's control architecture. I guess I will know more thoroughly after I build a plug-in. So I just said something, chat with me... 2. Chrome's page loading and drawing of the above UI controls are used in Windows (such as the browser's external box, menu, dialog box, etc ...). Most of the content we see in the browser is a webpage page. Page rendering (rendering is the process of converting an HTML file into a living page display...). Only half of the wheel is made by Chrome, and part of it comes from WebKit , The Web Renderer created by apple... The reason is that half of the wheel comes from WebKit because WebKit itself contains two main parts: HTML Rendering and JavaScript parsing. In Chrome, only HTML Rendering uses WebKitCodeIn JavaScript, a new Nb-hacking V8 engine was built. . The goal is to use WebKit + V8 together to create a Ferrari for surfing the Internet. From the effect, it is really good... However, chrome and WebKit are both open-source and work together. However, Chrome is still deliberately keeping a distance from WebKit, laying the groundwork for its initial chaos. Chrome encapsulates a layer on WebKit called WebKit glue. In the glue layer, most types of structures and interfaces are similar to WebKit. In Chrome, relying on WebKit components, only WebKit glue layer interfaces are called, rather than WebKit types. According to Chrome's own document, although we use WebKit to implement page rendering, this design (adds an indirect layer ...) to some extent, the coupling with WebKit has been greatly reduced, making it easy to replace WebKit with a better rendering engine that may emerge in the future...
Reuse
In the "Dream code", there is a piece of ridicule and reuse of text. He felt that the difficulty of software reuse came from many changes in the scenario, and it was difficult to design a set of all-encompassing things. On the other hand, it came from people,ProgramPeople always look at the code written by others, and they always like to write a set by themselves...
As a result, there are only two ways to solve the problem of reuse. write the code that the most Nb-savvy and omnipotent, or there are a lot of Nb-code to choose from. Google is undoubtedly doing well in both aspects. A set of things such as map/reduce and big table are powerful enough to be suitable for many scenarios, greatly simplifying the development of N-plus upper-layer applications. For open-sourceExploitationSo that he can pick a giant to stand on his shoulder and dance. Every time he sees such a scene, Ms is estimated to be angry with his chest and vomit blood...
Google has a deep accumulation at the underlying layer of the server. With the development of chrome, Android, and other client applications, the client accumulation has also gradually increased. Maybe, embracing open source is the right way for MS ?...
|
When you type a URL and press enter, Chrome downloads the page resources (including web pages and cookies) corresponding to the URL in the browser process ), Instead of sending the URL directly to the render Process for them to download it on their own (you will find that the render process is definitely 100% of the name, except for the rendering, almost nothing can be done ...). Compared with the websites of various render processes and managing their own resources, this policy seems to increase communication between processes. According to the explanation in this document, there are three main advantages: one is to avoid sub-processes from communicating with the network, so as to keep the permissions of network communication in the hands of the main process, the render process is weak, and the possibility of cracking down on bad things is reduced (the permissions of various render processes can be better controlled ...); another advantage is the sharing of cookie and other persistent resources on different pages. Otherwise, passing cookies in different render processes will make it more troublesome. Another important thing is that, it can control the number of HTTP connections established with the network, and use browser as the representative to communicate with all parties in the network. Various optimization strategies are well developed (such as pooling )... Of course, unified resource management in the browser process means that it is no longer convenient to use WebKit for resource download (WebKit certainly has this capability, but chrome once again abandoned it ...), it relies on WinHTTP. WinHTTP keeps sending data and related messages through IPC to the renderview in the render process that is responsible for drawing the page. . Here, the ID value in the routing message plays a key role. Based on this ID, the system can accurately send the relevant message to the relevant view header, the error message is not the same as that of someone who sent the money to your account, because the process of receiving the error is basically not lucky enough to receive the unexpected visitor, and the light page shows chaos, severe indigestion directly death... When renderview receives page information, it will draw and wait for more resources to arrive. in the user's opinion, the requested page is displayed. Of course, if a message such as the notification transmission start and transmission end is serialized into the message parameters and sent via IPC, the cost is still acceptable. However, if you want to send a message to a large segment of byte stream such as the resource content, it is not appropriate to waste a lot of space and time on both processes. So here we use Shared Memory . The browser process writes the downloaded resources to the shared memory, serializes the handle of the shared memory and the size of the shared area to the render process in the message. When the render process obtains the handle, it can access the shared memory-related areas, read information, and draw. In this way, we can enjoy the advantages of unified resource management, so as to avoid high process communication overhead and make it easy to get started... 3. The message response render process on the chrome page is a charming process, which can be seen from the previous section. It does not download its own resources, but is assisted by the browser process. However, the render process may be more lazy than you think. It not only does not download resources, but even does not receive system messages... The render process does not contain hwnd. When you move the mouse over the page and click it, these messages are actually sent to the browser process, which has the hwnd part of the page. Browser will send these messages to the renderview in the corresponding render process through IPC. In many cases, WebKit will process such messages. When it finds something worth telling the browser process, it returns a packet to the browser process. For example, you open a page and hover your mouse over it. Browser is like a broken mouth at this time. It tells the render process, "the mouse is moving, the mouse is moving ". If render does not care about this information, it will be boring to answer: "Oh, oh" (send a back packet ...). However, when you move the mouse over the link, the render process cannot sit down and will tell the browser process loudly: "change the mouse, change the mouse ~~", After the browser hears it, it will switch the mouse from the arrow to the finger shape, and then continue the above process... The trouble is that the paint message is too frequent to redraw the page. It is impossible to redraw a batch of byte streams at a time. As a result, the policy is clear, that is, the shared memory is still used for reading and writing, and the message sending handle is used. In the render process, there will be a shared memory pool (default value: 2...), with the size as the key, with the shared memory as the value, simple first-in-first-out Elimination Algorithm Use the characteristics of locality to avoid repeated creation and destruction of shared memory (this is different from the transfer of resources, because the transfer of resources can open a fixed size of shared memory ...). The render process picks up a piece from the shared memory pool (two-dimensional byte array ...), it's like taking a screen and trying to draw it up. In order to make render feel a sense of accomplishment at ease, browser will secretly help render to draw the content on the screen, this creates the illusion that the render process directly draws a screen. This is the tool for getting words on the screen, because there is no character information at all on hwnd, it's just a bunch of images, and nothing can be taken. As a result, Google Kingsoft's word overlord and Netease youdao word overlord both use their own wisdom and use chrome to make an advertisement... Why not let the render process own hwnd and manage its own messages, which is fast and convenient. On Chrome's official blog, there is an article to explain, basically this means that the speed must be fast, but it is necessary to give up some speed for user response. After all, no one prefers completely fake browsers. In the browser process, it basically prevents any synchronization of the render process. All operations are completed asynchronously. Because the render process is unreliable and may be sacrificed at any time, synchronizing them often causes the main process to stop responding, resulting in the entire browser to stop or even crash. This price is intolerable. However, Windows has a bad habit of sending synchronous messages to the entire hwnd inheritance system (I am not very clear about this situation, can someone explain it ?...), At this time, if hwnd is in the render process, it must lead to synchronization between the main process and the render process. Chrome cannot control windows, so they can only control render, move their hwnd to the main process to avoid synchronization, in exchange for the speed of user response... 4. Conclusion The UI architecture of Chrome is an issue of permission assignment. We can regard the browser process as a diligent emperor like Zhu Yuanzhang (for details, see those events in the Ming dynasty...). the majority of rights are firmly controlled in the hands. In this way, although browser is very laborious, the overall coordination and synchronization are very smooth. The render process is the puppet Prime Minister under the emperor. He is only responsible for his one mu of land and three sub-regions. He can follow the Emperor's deployment. In such an environment, the life and death of the render process become insignificant, and the death of the render is nothing more than a page-drawing tool. It is also a good strategy in the coding industry to control power in exchange for a peaceful world. However, the only accident comes from plugin. According to the standard, Chrome's plugin can create windows (hwnd), which will inevitably lead to synchronization problems. Chrome cannot solve this problem by controlling power, you can only get some other tricks to make up for it...
