The idea of the document begins with the design of the requirements and chromium the main design features. There is never a complex design, and they can all be converted into simple descriptions. Hope to solve the chromium design points from the study.
(The article is still being perfected ...). ）
Classification of requirementsChormium The application requirements of the Page view class into two categories(refer to the first paragraph of this article for instructions:Content Module):
. Web Platform Features
A. Ability to parse and render pages under multiple processes.
B. Html/html5/css3
. Application Features(for Chrome, Chrome Features)
A. Extensions
B. Autofill
c. Pre-render
d. safe-browsering
E. Translate
chromium The structure of the Division from the Chromium project, the content that is responsible for providing the Web Platform features is its core, which can be used to construct a complete browser application. The upper-level caller, called Embedder, is an application layer that provides the application Features. Different applications, for their different user scenarios, there will be different needs. In addition to the typical browser, there are other apps that have built-in page browsing features, such as help, previews, and even games. They all have different application-class requirements (application Features).
The following shows several typical embedder of the Chromium project, the first three of which are Google products.
key points of the chromium architecture Chromium Architecture features in addition to multi-process, the most obvious is to solve the dependency problem, the continuous development of high cohesion, low-coupling levels and components, and the use of deps to protect.
The following summarizes the key points of the chromium architecture:
1. Hierarchical DesignThe current hierarchical design is evolving, not one step in place. The main two phases are as follows:
I. First phase, in order to maximize compatible webkit, a glue layer is introduced between Chormium's own business logic and WebKit to isolate WebKit and chromium's own implementation of the business, such as multi-process architectures. After the change WebKit to blink, independent evolution, glue layer renamed to blink public API.
Ii. in the second phase, when Chromium's business logic becomes more and more, in order to avoid introducing unnecessary dependencies, destroying the original design, and also providing the function of page browsing for third-party applications, chromium divides the requirements into two categories and will be responsible for the Web Platform The features function is extracted from the content layer. (Refer to content Module)
here is the current full hierarchy of chrome:
2. Multi-Process ArchitectureA multi-process architecture is implemented by the content layer, which internally becomes the interface for two process interactions:
Renderwidgethost/renderwidget is a division of two processes (Browser & Renderer) that are connected to each other through the IPC.
Child processes are created by the browser process and interact with each other in a ipc&shared memory manner.
3. Modular Design The components are most visible everywhere:
A. Extension
B. BrowserComponents
its goal is to continually component the chrome-level code (IE, chrome Features), which extracts the content layer as a result.
c. Layered Component (modularity in the component)
is a special type of browser components. this was due to iOS restricting the use of third-party browser cores, chromium to allow Chrome features to use a variety of components compatible with iOS, avoid that part of the functionality of the repeated development, thus introducing layered component mode. The basic idea is to divide component into core (content free) that is not dependent on the content layer, and driver that are responsible for interacting with content or iOS under UIWebView. For details, please refer to: Layered components Design Document.
d. Blink componentization
in order to optimize its internal dependencies, the continuous refinement of functions .... See:Core/module componentization.
but more than that, the next step with Blink is fully merged into Chromium, and its dependencies will change further. SeeBlink componentization after Chromium-blink repository merge.
4. Blink toward micro-core developmentThe Following is a description of chromium:
If Core has too many code and too complex dependencies, it's very difficult to understand and update (including Maintaining existing features, fixing bugs, adding new features and so on) core.
Blink's goal continues to converge in the direction of the micro-core, and two relatively large changes are observed:
. With the Blink Platform API, the implementation of the H5 feature is extracted.
. With slimming Paint, the composition transactions in the rendering are further concentrated on the Chromium compositor (cc) of the content.
This blink is responsible for the core of the logical control, typesetting, output some intermediate results, and then collaborate with other modules to do further processing.
Chromium The essentials of Android webview architecture
the difference at the level based on the core features of the content layer, providing an alternative to Android before using the WebKit WebView, is called the Chromium Android WebView, abbreviated CAW.
As shown, AOSP WebView is part of the Android code, and chromium Android WebView belongs to the Chromium project.
From Bottom to bottom:
Android.webkit.WebView is still an implementation based on the WebView definition.
WebView Glue is to bridge the implementation of WebView to chromium Android WebView. These are the implementations of Java.
Chromium Android WebView provides a package of content, with some embedder behavior.
Android WebView also integrates some browser components, such as AutoFill, or even pdf exporter.
differences in process and rendering architecturesThe Chromium Android WebView goal is to provide a webview capability to the outside, in line with the Android view standard implementation. These also limit the use of a single-process architecture and make changes to the rendering schema.
The GPU process becomes inprocgputhread, and the renderer process becomes inprocrendererthread. (InProc-In process, which represents a single process.) )
The most obvious changes are visible on the GPU, and chromium has made two core changes to a single-process architecture:
compositor
* In addition, the compositor Main thread interacts with the IMPL thread to introduce Singlethreadproxy, which is also to accommodate this change.
GPU
key points in the design decisionThe aim is to reduce development costs and increase productivity, including:
A. Developers have a clear understanding of design and code.
B. Reduce the cost of change to better support functional evolution and multi-team collaboration.
C. Reduce the likelihood of making mistakes.
D. Speed up compilation.
key points in the design1. High cohesion, low coupling. Simplify dependencies while avoiding false dependenciesBlink Componentization is a typical representative. Do not have a ring dependency (cyclic dependencies) First, and then simplify the dependency.
In particular, chromium introduced Deps to help the team manage.
2. Avoid expansion of the interface bloating! Chromium repeatedly stressed the need to maintain a streamlined interface, do not easily increase the interface, more use of the extension mechanism provided by chromium. For details, see:
How to extend the interface of each layer of chromium .
3. Transfer the necessary datareferring to law of Demeter, it is also advantageous to simplify the dependency relationship and reduce the coupling. The so-called Lod is to do the necessary interaction with only the necessary classes, which can reduce interdependent classes and the interfaces they provide externally.
4. Don't let a class do too much (SRP)and don't let an interface function do too much of it.
5. Clear functions to avoid misinterpretation A class, a module, a level of functional responsibility must be clear, to avoid ambiguity. This is a design problem and a management issue.
6. When the middle tier needs wrapper
"Any computer problem can be solved by introducing a middle tier." ”
The middle tier application is very wide, Bridge, Wrapper, Adaptter, Glue, Proxy, COM + are all in this column. But adding a layer of cost is also some, not all the scenes have to add a layer to solve. For example, chromium in layered compontents design adaptation is to increase the interaction of driver, and not let the content API to implement a wrapper for compatibility processing, there is a possibility, but now will not do. (see:http://www.chromium.org/developers/design-documents/layered-components-design Faq:will there be a Wrapper API around the content API and the IOS API? )
Here is a decision-making problem with an add layer. Layer architecture design separates different business implementations, reduces mutual dependencies, and facilitates the team's understanding of the architecture, thus avoiding some error implementations. However, the disadvantage of the layer is that the execution path is extended, and even unnecessary data conversions may occur. For example, the OSI defines a 7-layer protocol for the network architecture, whereas a truly widespread application is a 4-tier structure.
Perhaps the introduction of the middle tier can solve any problem, but the cost is sometimes very high. Refer to the anti-pattern discussion about layers in detail.
7. Interface-orientedthe Content API is the best example. In order to encapsulate internal changes, lower the burden on the top developer and increase the interface layer to isolate. This is also an application of the middle tier.
8. Separation of strategies and capabilities for content, Blink provides the ability to complete the core business logic and is a real engine. Content, however, is responsible for providing the context in which it provides the blink needed, and makes business decisions about what to do. While content is the core of Embedder, providing external HTML page rendering and GPU rendering capabilities, Embedder is responsible for building its own applications based on this ability.
As such a layer of wrapping, the inside of the module to provide capacity, the above module to drive the internal module to do things.
9. Balancing Maintenance costs recommend a concise and effective solution.
Continuous Refactoring chromium, whether in blink componentization, layered Component Cookbook, or Warden Project, embodies the idea of continuous refactoring.
This is a development issue and a management issue.
When a new feature relies on a feature, or when a feature accumulates a bug, it's a good time to refactor. For example, chromium learned that the planning of the Blink-chromium merge code warehouse has begun to plan the interface layer design of the refactoring Content-blink. See Blink componentization after chromium-blink repository merge.
Reprint Please specify source: Http://blog.csdn.net/horkychen
Reference Blink componentization after the Chromium-blink repository merge
Browser Components Design Document
Layered Components Cookbook
Summary of design principles of chromium
