WebCore of WebKit

 

Transferred from: bytes.

The amount of Chrome browser code is actually very huge. To have a deep understanding of it, it is very difficult to compile, debug, and debug it. Let's analyze the main processes and data structures from its main components, such as multi-process management communication, WebKit, V8, skia, WinHTTP, and sanbox, which may achieve twice the result with half the effort, webKit is a very important part of it. It is the core engine of chrome. Other parts are integrated based on it. With a deep understanding of WebKit, the understanding of chrome will be easily solved, besides, WebKit, as a relatively independent browser engine, is applied in Safari, iPhone, Adobe AIR, and so on. It deserves further research.

As mentioned in the previous article, WebKit consists of three parts: WebCore, javascriptcore, and ports. Let's start with WebCore ....

1. Main Content contained in WebCore
1. From the perspective of the source code directory structure
The WebCore directory mainly includes the following directories:
Bindings includes the code that binds Dom to javascriptcore, and automatically generates a script corresponding to the implementation of javascriptcore binding according to the IDL Interface Description file;

Bridge mainly includes npplugin interface access and other content;

CSS mainly includes content related to CSS, such as parsing, definition and implementation of different CSS rules, and interface definition of CSS binding to Js;

Dom mainly includes dom-related content, such as the definition and implementation of different DOM elements, Dom binding interface definition for JS, and so on;

HTML mainly includes HTML-related content, such as the definition and implementation of different HTML elements, htmltokenizer and htmlparser;

Loader mainly includes loading resources such as HTML pages, CSS, JS and image;

Page mainly describes the content involved in a Web page, such as page, frame, frameview, frametree, setting, history, chrome, and chromeclient;

Rendering mainly includes how to use styles, organize la S, and display HTML elements;

Plugins mainly covers how the browser implements npplugin;

SVG mainly includes content related to SVG;

XML mainly includes XML-related content, such as XML parser, XPath, and XSLT;

Platform mainly includes content related to different platforms or external libraries, such as graphics (Graphic Output), Network (network processing), and image-decoders (parsing different image formats;

2. Main Data Structure
To describe the content and process of web pages more simply and effectively, WebKit uses different namespaces, such as WebCore, javascriptcore, and WebKit, to distinguish content from different aspects, the main data structures of WebCore include:
WebCore: Page, WebCore: frame, WebCore: frameloader, WebCore :: frameview, document, domwindow, kjsproxy, documentloader, resourcehandle, resourcerequest, resouceresponse, mainresourceloader, renderobject, and renderview. The main data structure is described as follows:

Relationship between webview and webframe, page, and frame

Figure 1

Class Structure of frameloader, documentloader, and docloader

Figure 2

Main Document Class Structure

Figure 3

Main Structure of the frameview class

Figure 4

In general, webCore includes the core components of the browser engine, such as processing HTML, Dom, CSS, SVG, obtaining resources, rendering page process control, callback/notification shell, and binding with JavaScript;

2. Main process of an HTTP request in WebCore

1. When webkit_web_view_open (URL) is called, core (webview)-> mainframe ()-> loader ()-> load (URI) (call frameloader. load) to initiate an HTTP page request;

Main processing process of frameloader. Load Method

Figure 5

2. Once resourcehandle: Start is initiated, the network library initiates an HTTP request to the Web server;

3. As a resoucehandleclient, mainresourceloader provides callback interfaces such as didreceivedata () and didreceiveresponse () for network libraries to call, once the relevant data is obtained from the Web server, the network library will call related interfaces such as didreceivedata;

4. The main callback processing process of mainresouceloader: didreceivedata is as follows:

Figure 6

5. Call the didreceivedata () method and call the node. Attach () method. This will parse and generate a document and create frameview and domwindow;

6. The created frameview triggers layouttimerfired time timer, and then calls the layout () method to trigger renderobject creation and layout. At the same time, it may be invalidaterect, this triggers the paint message event of the operating system graphics library;

7. The program receives the paint message event cyclically, obtains the corresponding frame, obtains or creates graphiccontext, and then calls frame-> View () -> paint (& CTX ,...), this triggers the corresponding renderobject tree for re-painting, so that a complete page will be gradually displayed.

Iii. Integration of network library, graphics library, and JavaScript with WebCore

To facilitate expansion and modularization, WebCore often uses interfaces similar to Java or gecko during page browsing. Generally, a set of public interfaces or basic classes are defined first, it is then implemented by different modules.

For example, WebCore provides a resourcehandle class for network processing, resourcehandle classes are implemented in different directories, such as CF, curl, QT, soup, and win, with the support of different network libraries, select the implementation under the corresponding directory during compilation. This method is relatively simple from the perspective of architecture, but it is often impossible for programs to use multiple network libraries at the same time, furthermore, the program dynamically switches to different network libraries, while gecko provides support for this extension form based on XPCOM. Chrome implements the resoucehanle Class Based on the WinHTTP network library.

Similarly, WebCore integrates graphics libraries in this way. For example, WebCore provides a graphicscontext class, then, graphicscontext is implemented in different directories, such as Cairo, CG, QT, win, and wx, under the support of different graphic libraries. Chrome implements the graphicscontext Class Based on the skia graphics library.

Dom, HTML, SVG, and CSS implemented in WebCore often need to be output to JavaScript implementations such as javascriptcore and V8 in a certain way, so that JS engineers can understand these DOM elements, the method can also be called. This method is called binding. To facilitate binding of relatively fixed Dom, HTML, SVG, and CSS interfaces in WebCore, webKit is implemented in an extremely efficient and magical way.

First define a set of non-standard IDL interfaces, and then run a set of Perl scripts such as generate-bindings.pl, codegenerator. PM, codegeneratorjs. you can generate a set of script object classes that comply with the specified JavaScript implementation rules according to the definition of the IDL Interface. This greatly reduces developers' investment and coding errors.

This is essentially different from how gecko binds different XPCOM interfaces to JavaScript. In Gecko, xpconnect and a set of classinfo are used to maintain the relationship between native elements and JS objects, the creation of JS objects corresponding to different native elements and the binding of attribute Methods fully depend on the implementation of xpconnect and the definition of classinfo. To delete and modify attributes and methods of binding, you only need to modify classinfo; binding in WebKit is relatively simple and clear. attributes and methods of JS objects corresponding to different native elements are defined by the IDL Interface file, the specific implementation is handed over to the powerful generate-bindings.pl to generate the implementation code, so that the compilation can easily implement binding...

Iv. Reference resources

The WebKit Open Source Project