study the usage of
base::Thread Thread pool: Sequence or Virtual thread Task runner
Managing renderer processes
Each renderer process has a global
RenderProcess object that manages communication with the parent browser process and maintains global state. The browser maintains a corresponding
RenderProcessHost for each renderer process, which manages browser state and communication for the renderer. The browser and the renderers communicate using Mojo or Chromium’s legacy IPC system.
In the renderer process:
RenderProcesshandles Mojo setup and legacy IPC with the corresponding
RenderProcessHostin the browser. There is exactly one
RenderProcessobject per renderer process.
RenderFrameobject communicates with its corresponding
RenderFrameHostin the browser process (via Mojo), and the Blink layer. This object represents the contents of one web document in a tab or subframe.
In the browser process:
Browserobject represents a top-level browser window.
RenderProcessHostobject represents the browser side of a single browser ↔ renderer IPC connection. There is one
RenderProcessHostin the browser process for each renderer process.
RenderFrameHostobject encapsulates communication with the
RenderWidgetHosthandles the input and painting for
RenderWidgetin the browser.
Chromium has split out a number of other components into separate processes as well, sometimes in platform-specific ways. For example, it now has a separate GPU process, network service, and storage service. Sandboxed utility processes can also be used for small or risky tasks, as one way to satisfy the Rule of Two for security.
For stability, putting web site instances in separate processes limits the impact of a renderer process crash or hang, allowing other content to continue working. For performance, this allows different web site instances to run in parallel with better responsiveness, at the cost of some memory overhead for each process.
For security, strictly using separate processes for different web sites allows significantly stronger defenses against malicious web sites. In addition to running web content within a low-privilege sandbox that limits an attacker‘s access to the user’s machine, Chromium’s multi-process architecture can support Site Isolation, where each renderer process is only allowed to access data from a single site. Site Isolation involves:
- Locked Renderer Processes: A renderer process can be limited to documents and workers from a single web site or origin, even if such documents are in iframes.
- Browser-Enforced Restrictions: The privileged browser process can monitor IPC messages from locked processes to limit their actions or access to site data (e.g., using ChildProcessSecurityPolicy::CanAccessDataForOrigin). This prevents compromised renderer processes from asking for cross-site data, using permissions granted to other sites, etc.
- Network Response Limitations: Chromium can ensure that locked renderer processes are only allowed to receive sensitive data (e.g., HTML, XML, JSON) from their designated site or origin, while still allowing cross-origin subresource requests (e.g., images, media) as needed for compatibility. This is achieved using Cross-Origin Read Blocking (CORB) or Opaque Response Blocking (ORB).
Principal Instance (implemented by SiteInstance): A principal instance is the core unit of Chromium‘s process model. Any two documents with the same principal in the same browsing context group (see below) must live in the same process, because they have synchronous access to each other’s content
Chrome has a multi-process architecture and each process is heavily multi-threaded. The main goal is to keep the main thread (a.k.a. “UI” thread in the browser process) and IO thread (each process‘s thread for receiving IPC) responsive. This means offloading any blocking I/O or other expensive operations to other threads. Our approach is to use message passing as the way of communicating between threads. We discourage locking and thread-safe objects. Instead, objects live on only one (often virtual — we’ll get to that later!) thread and we pass messages between those threads for communication.
Task : a function pointer with optionally associated state
Cancelling a Task: Using
base::WeakPtr can be used to ensure that any callback bound to an object is canceled when that object is destroyed.
In Chrome this is
base::RepeatingCallback created via
A task is a
base::OnceClosure added to a queue for asynchronous execution.
Task runner: An interface through which tasks can be posted. In Chrome this is
content/ layer of Chromium has a class called
WebContents, which is one of the most basic building blocks of all of Chromium. This document describes how
WebContentses are used to build tabs in browser windows.
WebContents is the core class in content/. A WebContents renders web content (usually HTML) in a rectangular area.
Instantiating one is simple:
// std::unique_ptr<content::WebContents> web_contents( // content::WebContents::Create( // content::WebContents::CreateParams(browser_context))); // gfx::NativeView view = web_contents->GetNativeView();
// Each WebContents has exactly one NavigationController; each NavigationController belongs to one WebContents. The NavigationController canbe obtained from GetController(), and is used to load URLs into the WebContents, navigate it backwards/forwards, etc. See navigation_controller.h
Blink is a rendering engine of the web platform. Roughly speaking, Blink implements everything that renders content inside a browser tab:
Blink is embedded by many customers such as Chromium, Android WebView and Opera via content public APIs.
From the code base perspective, “Blink” normally means //third_party/blink/. From the project perspective, “Blink” normally means projects that implement web platform features. Code that implements web platform features span //third_party/blink/, //content/renderer/, //content/browser/ and other places.
Page, Frame, Document, ExecutionContext and DOMWindow
A Page corresponds to a concept of a tab (if OOPIF explained below is not enabled). Each renderer process may contain multiple tabs.
A Frame corresponds to a concept of a frame (the main frame or an iframe). Each Page may contain one or more Frames that are arranged in a tree hierarchy.
An ExecutionContext is a concept that abstracts a Document (for the main thread) and a WorkerGlobalScope (for a worker thread).
Renderer process : Page = 1 : N.
Page : Frame = 1 : M.
Frame : DOMWindow : Document (or ExecutionContext) = 1 : 1 : 1 at any point in time, but the mapping may change over time. For example, consider the following code:
iframe.contentWindow.location.href = “https://example.com”;
In this case, a new DOMWindow and a new Document are created for https://example.com. However, the Frame may be reused.
Isolate, Context, World
Isolate corresponds to a physical thread. Isolate : physical thread in Blink = 1 : 1. The main thread has its own Isolate. A worker thread has its own Isolate.
Context corresponds to a global object (In case of a Frame, it’s a window object of the Frame). Since each frame has its own window object, there are multiple Contexts in a renderer process. When you call V8 APIs, you have to make sure that you’re in the correct context.
blink::WebLocalFrame* web_frame = render_frame_->GetWebFrame(); v8::Local<v8::Context> context = web_frame->MainWorldScriptContext();
V8 uses handles to point to V8 objects. The most common handle is v8::Local<>, which is used to point to V8 objects from a machine stack. v8::Local<> must be used after allocating v8::HandleScope on the machine stack. v8::Local<> should not be used outside the machine stack:
v8::HandleScope handle_scope(v8::Isolate::GetCurrent()); v8::Local<v8::Context> context = web_frame->MainWorldScriptContext(); v8::Context::Scope context_scope(context);
What is a “tab helper”? It is a
WebContentsObserver owned by the
WebContents itself. Let’s break that down.
WebContentsObserver is a simple interface that allows an object to observe events in the life of a
最后更新于 2023年2月6日 by qlily