Android4.4 System Browser Chromium Implementation of the loading module and process, android4.4chromium

Android4.4 System Browser Chromium Implementation of the loading module and process, android4.4chromium

This article only describes the information related to Http network requests. The types of Https, Spdy, file, ftp, websocket, and so on only refer to where the link branch appears.

 

The Code Hierarchy Diagram is as follows:

+ -------------------------------------- + | WebView. java (SDK public API) | + connector + | Android & Chromium Wrapper | Java Bridge and encapsulation layer + ---------------------------------------- + | Content Module (Navigation Control) | core layer, loading Process is responsible for various jumps + ---------------------------------------- + | blink public web API (WebView) | web api for external kernel Control + ---------------------------------------- + | WebCore | the header and tail of the original WebCore are cut off to form a blink + platform + | blink public platform API (Network) | platform api requires external implementation + ---------------------------------------- + | Content Module (I/O thread) | Implementation of the upper layer, operate in the IO thread + -------------------------------------- + | Network Stack | Network Library + ------------------------------------------ +

The following is a functional module hierarchy chart (the yellow tag index in the detailed figure ):

+ ------------------------------------------ + | Browser Application | Browser program + -------------------------------------------- + | package android. webkit | sdk api + ---------------------------------------------- + | package com. android. webview. chromium | Android bridge layer + -------------------------------------------- + | package org. chromium. android_webview | Chromium encapsulation layer + -------------------------------------------- + | package org. chromium. content. browser | Chromium Android platform code + handler + | content Module Browser Side | Content Module Browser Side processing + ---------------------- IPC --------------------- + | content Module Renderer Side | Content Module Renderer Side processing + handler + | blink public Web API | + Platform + | WebCore | + Platform + | blink public Platform API | + Platform + | content Module implementation of blink | interface for blink implementation of content + ------------------ IPC ------------------ + | content Module Loading Control | load Process Control + ------------------------------------------ + | net Module public API | external interface layer of the net Library + worker + | Job Factory (Network Protocol) + response + | Transaction & HttpCache | Transaction and HttpCache + response + | Session & Socket Pool | Session and Socket Pool | stream | ----------------------- | stream | DNS & HostCache | + response + | socket | + -------------------------------------------- +

The simplified message stream is as follows:

1. Start WebView. loadUrl In the UI thread of the Browser Process
2. After multi-layer bridging, the class ContentViewCore. java is transferred to the JNI code content: ContentViewCoreImpl.
3. The URL encapsulated by NavigationControllerImpl initiates a C ++ request, and RenderFrameHostImpl converts it into an IPC message and sends it to the Renderer process.
4. After being processed by the IPC Mechanism in the Renderer process, the RenderFrameImpl is reached, the message flows through the blink and WebCore layers, and finally to the WebURLLoaderImpl for actual loading.
5. WebURLLoaderImpl sends an IPC message to the Browser process's I/O thread through IPCResourceLoaderBridge for network data I/O
6. The message is received by ResourceDispatcherHostImpl after being processed by the IPC Mechanism, and then sent to the content: ResourceLoader to control the net Library for network communication to obtain data.
7. After the net Library passes HttpCache (Memory | Disk), DNS (HostCache), connect (SSL handshake), write, and read, the obtained data finally sends an IPC message back to the Renderer process through ResourceMessageFilter.
8. After the WebCore obtains the data, it submits it to the parsing thread for processing through PostTask.

The following is a detailed graph of the inter-class relationship/hierarchy. Figure display prompt:

1. The layer starting with package is a java class
2. The namespace is marked for classes with the same name at different levels, such as ResourceLoader and FrameTree.
3. If a pure virtual class has only one implementation, it is abbreviated as the base class name | Impl
4. From the user's point of view, data streams have always been divided into different levels and modules are grouped by function aggregation (this is my personal understanding, unofficial documentation)
5. If Class A is associated with the base class of Class B, Class B interacts with Class.
6. A horizontal line is used to differentiate functional modules, packages, and namespaces. The yellow rectangle label indicates the function/meaning of this layer. The gray rectangle describes this layer.
7. The first time is to look at the yellow label and know the relationship between the layers. The second time, you can look at the layer you care about, including the description of the layer and the connection between the layer and the upper and lower layers. If you are interested, read the full picture carefully for the third time.

The following is the xmind export diagram of the loading process. It is best to save it as a local image. Figure display prompt:

1. The process of drawing from top down is based on the stack inversion.
2. "..." Indicates that the IPC Mechanism code is omitted.
3. The code of the Callback mechanism is omitted in the figure.
4. The same parent node indicates the execution in order in this parent Function
5. Most of the class names and function names already represent their functions and meanings. You can also view the header file comments of the class to help you understand them, or compare them with the following "Inter-class relationship diagram". Some classes are necessary for specific development, so they are not explained.
6. Several Classes in the process have the same name function doLoop. These classes divide the large process into small operations and internally represent the emun status of the operation steps (the case XXX branch in the figure) in this way, asynchronous processing is implemented and the processing time of the loop is reduced.

The figure is too large and divided into two sections. Click to view the big chart:

Reprinted please indicate the source: http://blog.csdn.net/hursing

Browser Based on chromium Kernel

Your so-called kernel refers to Webkit, which is open-source, so there are countless browsers Based on it. Let's give you some famous ones, including Google Chrome and Apple Safari abroad, in China, there are sogou, roaming, QQ, etc...

Use the Chrome browser to teach me how to use it.

You can simply click chrome web store to access it. Just like online shopping, you can install whatever application you like.
In addition, the most powerful part of chromium is not the plug-in, but the page loading speed and software update speed. It is definitely the benchmark in the industry.