How chrome displays Web pages

How chrome displays Web pages

 

• How chromium displays Web pages
  • • Conceptual Application Layer
    • WebKit
    • WebKit Port
    • WebKit Adhesive Layer
    • Browser Process
    • Underlying browser process object
    • High-level browser process object
    • Demo
    • Process of "set cursor" Message Processing
    • Click Message Processing

Whzeng@126.com

 

This document describes the Chrome Web page from the underlying layer to the upper layer. Are you sure you have monthly multi-process architecture? . You will be particularly interested in the main component blocks. You may also be interested in learning about Multiprocess resource loading? To learn how to download a webpage from the Internet.

Conceptual Application Layer

Each box represents a conceptual layer. It is possible to build different browsers by selecting or replacing layers above each layer. Therefore, no layer should depend on any layer that is higher than its level or require higher level of information.

• WebKit? : Rendering engine for Safari, chromium, and any other WebKit-based browsers. Port is a part of WebKit. It is integrated with platforms dependent on system services, such as resource loading and graphics.
• Glue: converts the WebKit type to the chromium type. This is our WebKit embedded layer. It is the basic part of chrome and test_shell (allowing us to test WebKit) browsers.
• Render/render HOST: This is the multi-process embedding layer of chromium. It can penetrate the process boundary to proxy various notifications and commands. You can imagine that another multi-process browser is using this layer. It should depend on other services of the browser.
• Tab contents: the content of a tag at a specific layer of the browser. It is bound to the historical system and password management login application service. It should not, and should never be assumed that it is embedded in a chromium browser window (it can also be used by other browser components like HTML dialog boxes ).
• Broeser: indicates a browser window. It is embedded with multiple tabs (tabcontentses? ).

WebKit?

We use WebKit Open-source engineering to deploy webpages. These codes come from Apple and contain the/third_party/WebKit directory. WebKit consists of WebCore, which represents the kernel layout function, and javascriptcore, which executes Javascript. We only run javascriptcore for testing. We usually replace it with our higher-performance V8 engine. We do not actually use the layer that Apple calls WebKit. This layer is an API embedded between WebCore and The OSX application safari. For convenience, we refer to the code at the Apple layer as WebKit.

WebKit? Port

At the bottom layer, we have our WebKit port. This is our implementation of the platform-independent WebCore code interface on a specific platform. These files are located in/WebKit/port and are similar to the WebCore directory hierarchy. Most of our ports are irrelevant to the actual OS: You can consider them chromium port's WebCore. The processing of a few image fonts is different on each platform.

• Load through multi-process resources? The system processes network resources and responses. Instead of directly handing over the render process to the OS for processing.
• Use the skia graphics library developed for Android. This is a cross-platform graphics library that can process many images and basic graphic elements except text. Skia is located in/third_party/skia. The main graphic operation portal is/WebKit/port/platform/graphics/graphicscontextskia. cpp. It is also used by many other files in the same directory, such as/base/GFX.

WebKit Adhesive Layer

Chromium applications use different types, code styles, and code la s instead of third-party WebKit code. The WebKit adhesive layer provides many convenient embedded APIs for WebKit to use Goole code for convenience and type conversion (for example, we use STD: string to replace WebCore: String, gurl to replace kurl ). The adhesive layer is located in/WebKit/glue. All adhesive objects are similar to WebKit objects, but are prefixed with "Web. For example, WebCore: frame programming webframe.

WebKit? The adhesive layer isolates chromium-based code libraries and WebCore data types, so that modifications based on chromium code can minimize the impact on WebCore. Based on the time, The WebCore data type is never directly used in chromium. All APIs are added to the WebKit adhesive layer to facilitate chromium (when it needs to poke at some WebCore? Object ).

The test_shell application lacks the web browser skeleton and is used to test our WebKit port and Adhesive Layer Code. It uses the same glue interface as chromium to communicate with WebKit. It does not have many complex browser features, threads, and processes, but provides a simple method for developers to test new code. This application is also used to automatically run the WebKit test.

The chromium rendering process uses the glue interface to embed our WebKit port. It does not contain a lot of code: its main task is to become the IPC channel for the Renderer to connect to the browser.

The most important class in the Renderer is renderview, which is located in/Chrome/Renderer/render_view.cc. This object represents a webpage. It processes all browser-related commands. It is driven by renderwidget, which provides rendering and event processing. Renderview communicates with the browser process through the Global (one for each rendering process) renderprocess object.

FAQ: What is the difference between renderwidget and renderview? Renderwidget maps an abstract interface called webwidgetdelegate on the glue layer to a WebCore: widget object. Basically, it can be thought of as receiving input events on the screen and the windows we need to draw. Renderview inherits the renderwidget and contains labels or pop-up window content. It processes browsing commands and input events for plotting and widgets.

Each Renderer has two threads (see chrome multi-process architecture? In the figure or the chroimum thread? ). The Renderer thread executes main objects such as renderview and all WebKit code. When it communicates with the browser, the message is first sent to the main thread, and the main thread sends the message to the browser process separately. In addition, this method allows synchronous messages sent from the Renderer to the browser. This method allows the browser to continue after a set of operations on the Renderer are completed. A simple example is when JavaScript reads cookies. The Renderer thread will be blocked and the main thread will post all received messages until the correct response is received. Normally, messages are sent to the Renderer sequentially once the main thread receives them.

Browser Process

Underlying browser process object

All communications with the Renderer process are completed by browser I/O threads. Does this thread process all network communication at the same time? This also maintains interaction with user interfaces. When the main thread (the user interface is executed here) initializes renderprocesshost. Renderprocesshost creates a new Renderer process and channelproxy object (communicates with the Renderer through a famous pipeline ). Renderprocesshost is executed in the browser's Io thread. It also listens to the data of the famous pipeline from the Renderer and automatically notifies all the messages to renderprocess In the UI thread. Resourcemessagefilter is installed in this channel, which can find a message (such as a network request) that needs to be processed directly in the IO thread ). Resourcemessagefilter: onmessagereceived: filters messages.

The renderprocesshost of the UI thread is responsible for distributing view-related messages to the appropriate renderviewhost (which processes limited non-View-related messages ). Renderprocesshost: onmessagereceived distributes these messages.

High-level browser process object

When a view-related message enters renderviewhost: onmessagereceived, most of these messages are processed at the same time, and the remaining messages are delivered to the class that integrates renderwidgethost for processing. The Renderer corresponds to the renderview and renderwidget respectively (for more information about these objects, see the Renderer process ). On Microsoft Windows, we associate each renderwidgethost with renderwidgethosthwnd. Renderwidgethost manages events and draws them to the local hwnd. For other systems, we use similar classes to manage local input and drawing.

The webcontents object is built on the renderview/widget. Most messages actually end with function calls on this object. Each webcontents indicates the content of the network data label. It is subject to the common tabcontents class (there are many other tabcontents specifications, such as history and download .) Driver. Webcontents is a switching point for most browser and top-layer browser UI updates.

FAQ: Why does webcontents and renderviewhost be separated? These two objects provide different functional levels. You can think of renderviewhost as the multi-process embedding layer of chromium. The renderviewhost object can be used (not actually) to render other parts of the content. For example, you can imagine a dialog box with a Web View. It can use renderviewhost to manage the rendering and communicate with the rendering process, but it cannot have labels or common browsing commands. Renderviewhost uses the abstract interface renderviewhostdelegate to forward many messages to webcontents. Webcontents processes the browsing status and any operations related to the web browser UI. We assume that the dialog box does not need any of these functions. You only need to implement some interfaces of renderviewhostdelegate that it cares about.

Demo

Other examples about browsing and starting are getting Chrome source code? .

Process of "set cursor" Message Processing

Setting the cursor is a typical message sent by the Renderer to the browser. Process in the Renderer as follows:

• Set the cursor message to be generated inside WebKit. Typically, it is a response to input events. Set the cursor message to be sent by renderwidget: setcursor (Chrome/render/render_widget.cc.
• It will call renderwidget: Send to split and send messages. This method is also used by renderview to send messages to the browser. Then call renderthread: Send.
• Next, call IPC: syncchannel to implement the internal proxy message to deliver the message to the main thread of the Renderer at the same time to the named pipe that sends the message to the browser.

Then the browser takes over the message:

• Renderprocesshost? The IPC: channelproxy receives messages from all browser I/O threads. It first sends them to rendermessagefilter, which distributes network requests and related messages directly in the IO thread. Since our message is not filtered out, it will continue to be submitted to the UI thread of the browser (this is implemented internally by IPC: channelproxy ).
• Renderprocesshost? : Onmessagereceived (Chrome/Browser/render_process_host.cc) gets messages for all views that respond to the Renderer process. It processes several types of messages directly, and responds to messages from renderview for the remaining forward notifications corresponding to renderviewhost.
• The message arrives at renderviewhost: onmessagereceived (Chrome/Browser/render_view_host.cc ). Many messages are processed here, but the message with the cursor set is not here, because it is a message from renderwidget and should be handed over to renderwidgethost for processing.
• All unprocessed messages of renderviewhost are automatically forwarded to renderwidgethost, including setting the cursor message.
• The message ing in Chrome/Browser/render_widget_host.cc finally receives the renderwidgethost: onmsgsetcusor and calls the appropriate UI function to set the mouse cursor.

Click Message Processing

A mouse message is a typical message sent from a browser to the Renderer.

• The UI thread of the browser receives window messages through renderwidethosthwnd: onmouseevent, and then calls forwardmouseeventtorenderer.
• This forward notification function wraps the input event into a cross-platform webmouseevent and sends it to the relevant renderwidgethost.
• Renderwidgethost: forwardinputevent creates an IPC message viewmsg_handleinputevent and serializes it into webinputevnet. Then, call renderwikiethost: Send to send the message.
• This will forward the event to the renderprocesshost: Send function, which passes the message to IPC: channelproxy in order.
• Internally, IPC: channnelproxy will proxy this message to the browser's Io thread. Then write the name pipeline of the corresponding Renderer.

Note: many other types of messages created by webcontents, especially those for browsing functions, are also transmitted from webcontents to renderviewhost in a similar process.

The Renderer then takes over the message.

• The IPC: Channel of the main thread of the Renderer reads messages sent by the browser, and the IPC: channelproxy acts as a proxy to the rendering thread.
• Renderview? : Onmessagereceived. Many types of messages are processed directly here. But clicking a message does not mean that it will continue (together with all other unprocessed messages) through this to the renderwidget: onmessagereceived (It notifies renderwidget: onhandleinputevent in order ).
• The input event is finally sent to webwidgetimpl: handleinputevent. This function converts it to the platformmouseevent class of WebKit and submits it to the WebCore: widget class in WebKit for processing.