Chromium kernel resource loading, parsing, and three-Tree Synthesis analysis (chromium39)

Chromium kernel resource loading, parsing, and three-Tree Synthesis analysis (chromium39)

Every time I try to see the implementation of the specific logic in chromium kernel, I will spend some time to read the code and find the logic. Of course, I can refer to a lot of materials on the Internet, but every time I read these materials, I will ask: Is that true? Is the logic of the new version of kernel changed?

Therefore, in order to let yourself explain, you still need to go to the source code and view the call stack a little bit. Then we can understand the principle of the kernel as a whole.

Recently I looked at the web page loading, html parsing, and merging logic of the blink kernel part in chromium kernel. Here, we will summarize and continue our in-depth research in the future.

> Differences between chromium kernel and blink kernel

When I first came into contact with the chromium project, I often had a question: What is the difference between chromium kernel and blink kernel in the browser kernel?

First, we need to explain that blink (google branch of webkit) is the rendering kernel, which is part of chromium kernel. Provides the basic webpage loading, parsing, and rendering mechanisms, and provides ports for different browser Kernels to implement.

Chromium kernel is a browser kernel that encapsulates and extends blink layers before implementation. chromium kernel not only provides webpage loading, parsing, and rendering functions, it also provides forward, backward, and refresh tabs, multi-tab management, historical records and bookmarks, and various callback interfaces. In addition, you can implement some blink kernel functions, such as rendering.

Therefore, blink kernel is the heart part of chromium kernel.

 

> Load

In the previous blog, we summarized the download logic of resources during webpage loading. I will not go into details here.

To sum up, webpage resources are loaded in multiple threads.

The loading process starts when the primary resource is loaded. After the entire primary resource is downloaded, a string (or several strings) is formed and parsed to form a dom tree, in this case, the corresponding sub-resource loading process is started when you encounter tags to be loaded, such as img and srcipt.

 

> Dom Parsing

The main resource is downloaded as a string and then tagged. For more information about the parsing syntax, see the online article.

DOM Tree, Render Tree, And RenderLayer Tree are created in parallel, and their creation is parallel to the loading of sub-resources.

> Relationship between the three trees

For the parsing process from Dom tree to RenderTree, refer to the article: online article.

In Dom tree synthesis, HTMLTreeBuilder. cpp is a key object. The method HTMLTreeBuilder: constructTree is to build the dom tree by parsing all the tokens in the previous step.

Here, the building Stack from the web page string to the dom tree is pasted:

 

W/WebKit  ( 7420): BackgroundHTMLParser::appendDecodedBytesW/WebKit  ( 7420): BackgroundHTMLParser::pumpTokenizer()W/WebKit  ( 7420): BackgroundHTMLParser::sendTokensToMainThread()W/WebKit  ( 7420): BackgroundHTMLParser::pumpTokenizer()W/WebKit  ( 7420): HTMLDocumentParser::didReceiveParsedChunkFromBackgroundParserW/WebKit  ( 7420): HTMLDocumentParser::pumpPendingSpeculations()W/WebKit  ( 7420): HTMLDocumentParser::processParsedChunkFromBackgroundParserW/WebKit  ( 7420): HTMLDocumentParser::constructTreeFromCompactHTMLTokenW/WebKit  ( 7420): HTMLTreeBuilder::constructTree

The Node of the Dom tree is a Node class. You can view the code on your own for the logical relationships of node types and subclass inheritance.

 

The root node of the RenderTree is the RenderView class, and each node is RenderObject. For details about each node in the RenderTree, you can view the code by yourself. There are many subclasses of RenderObject.

Multiple RenderTreeBuilder objects will be created during RenderTree construction.

 

The node of RenderLayerTree is the RenderLayer object.

 

Here, part of the formation logic from the renderLayer is pasted:

 

W/WebKit  ( 5275): Element::attach W/WebKit  ( 5275): RenderTreeBuilder::RenderTreeBuilderW/WebKit  ( 5275): RenderTreeBuilder::createRendererForElementIfNeeded()W/WebKit  ( 5275): RenderObject::setStyleW/WebKit  ( 5275): RenderBlock::styleDidChangeW/WebKit  ( 5275): RenderLayerModelObject::styleDidChangeW/WebKit  ( 5275): RenderLayerModelObject::createLayerW/WebKit  ( 5275): RenderLayer::RenderLayer

RenderLayer Tree is an important component for displaying web pages.

 

For analysis of the three NLP processes, see blog: online articles.

Then, if you have time, go to the next step to look at the rendering logic of the web page.

 

Blink kernel's webpage download, parsing, and merging logic are also complicated, with many details. Here is a summary of the logic of the code I recently read. If you have time in the future, you need to study it in depth. See how to operate the dom tree (adding or deleting nodes) in the kernel.