chrome多进程结构翻译

多进程

This document describes Chromium's high-level architecture.
Problem

It's nearly impossible to build a rendering engine that never crashes or hangs. It's also nearly impossible to build a rendering engine that is perfectly secure.

--几乎不可能建立一个绝对安全、不会崩溃或者挂起的渲染引擎。

In some ways, the current state of web browsers is like that of the single-user, co-operatively multi-tasked operating systems of the past. As a misbehaving application in such an operating system could take down the entire system, so can a misbehaving web page in a modern web browser. All it takes is one browser or plug-in bug to bring down the entire browser and all of the currently running tabs.

在某些方面，现在的浏览器类似与以往的单用户、多任务的老式操作系统。就像一个错误的应用可以是一个操作系统宕机一样，一个错误的网页或者插件错误将导致整个浏览崩溃。

Modern operating systems are more robust because they put applications into separate processes that are walled off from one another. A crash in one application generally does not impair other applications or the integrity of the operating system, and each user's access to other users' data is restricted.

       现代操作系统更加健壮，原因是将应用置于不同的进程中。一个应用的崩溃不影响其他应用和操作系统，并且每个用户访问其他用户的数据受限。

 
Architectural overview

We use separate processes for browser tabs to protect the overall application from bugs and glitches in the rendering engine. We also restrict access from each rendering engine process to others and to the rest of the system. In some ways, this brings to web browsing the benefits that memory protection and access control brought to operating systems.

我们使用多进程来进行浏览器 TAB页的保护，也限制不同进程的渲染引擎之间的访问。这给浏览器带来了内存保护的好处，就像操作系统一样。

We refer to the main process than runs the UI and manages tab and plugin processes as the "browser process" or "browser." Likewise, the tab-specific processes are called "render processes" or "renderers." The renderers use the WebKit open-source layout engine for interpreting and laying out HTML.

主进程运行UI并管理Tab页和插件进程。渲染进程(renderers)使用WebKit开源引擎来解释和展示HTML文件。
Managing render processes

Each render 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 render process, which manages browser state and communication for the renderer. The browser and the renderers communicate using Chromium's IPC system.

每个渲染进程都有一个全局的RenderProcess主线程对象来管理与父进程的通讯并维护全局状态。父进程(browser)维护一个RenderProcessHost来记录子进程，并管理子进程(renderer)的状态和通讯. 父进程和子进程之间通过IPC系统通讯。
Managing views

Each render process has one or more RenderView objects, managed by the RenderProcess, which correspond to tabs of content. The corresponding RenderProcessHost maintains a RenderViewHost corresponding to each view in the renderer. Each view is given a view ID that is used to differentiate multiple views in the same renderer. These IDs are unique inside one renderer but not within the browser, so identifying a view requires a RenderProcessHost and a view ID. Communication from the browser to a specific tab of content is done through these RenderViewHost objects, which know how to send messages through their RenderProcessHost to the RenderProcess and on to the RenderView.

每个子进程(renderer)都有一个或者多个RenderView对象，被RenderProcess管理。每个RenderView对象代表这一个tab页的内容。相应RenderProcessHost维护一个RenderViewHost来对应每个RenderView. 每个View都有一个ID以区分同一renderer中的不同view. ID在renderer中唯一。所以标识一个view需要一个RenderProcessHost和一个view ID. 主进程和tab页的通讯通过RednerViewHost对象完成，它知道如何通过RenderProcessHost发送消息
Components and interfaces

In the render process:

    * The RenderProcess handles IPC with the corresponding RenderProcessHost in the browser. There is exactly one RenderProcess object per render process. This is how all browser ? renderer communication happens.

    * The RenderView object communicates with its corresponding RenderViewHost in the browser process (via the RenderProcess), and our WebKit embedding layer. This object represents the contents of one web page in a tab or popup window

 

In the browser process:

    * The Browser object represents a top-level browser window.

    * The RenderProcessHost object represents the browser side of a single browser ? renderer IPC connection. There is one RenderProcessHost in the browser process for each render process.

    * The RenderViewHost object encapsulates communication with the remote RenderView, and RenderWidgetHost handles the input and painting for RenderWidget in the browser.

 

For more detailed information on how this embedding works, see the How Chromium displays web pages design document.

 

在render进程中

1、  RenderProcess负责与相应的RenderProcessHost通讯.每个render进程有一个RenderProcess.

2、  RenderView对象通过RenderProcess与RenderViewHost通讯

 

在browser进程中

1、  Browser对象代表顶层的浏览器主窗口；

2、  RenderProcessHost对象代表一个IPC连接，每个render进程有一个RenderProcessHost对象与之对应；

3、  RenderViewHost对象封装与远程RenderView的通讯；RenderWidgetHost处理输入和渲染；
1.1.6          Sharing the render process

In general, each new window or tab opens in a new process. The browser will spawn a new process and instruct it to create a single RenderView.

一般来说，当创建一个新的window或者tab页时，browser会创建新的render进程

Sometimes it is necessary or desirable to share the render process between tabs or windows. A web application opens a new window that it expects to communicate synchronously, for example, window.open in JavaScript. In this case, when we create a new window or tab, we need to reuse the process that the window was opened with. We also have strategies to assign new tabs to existing processes if the total number of processes is too large, or if the user already has a process open navigated to that domain. These strategies are described in Process Models.

有时需要在windows和tab页之间共享render进程（估计大部分情况如此，不然一个tab页一个进程，根本受不了）。需要有一定的策略确定render process的共享，这些策略在进程模型中描述。
Detecting crashed or misbehaving renderers

Each IPC connection to a browser process watches the process handles. If these handles are signaled, the render process has crashed and the tabs are notified of the crash. For now, we show a "sad tab" screen that notifies the user that the renderer has crashed. The page can be reloaded by pressing the reload button or by starting a new navigation. When this happens, we notice that there is no process and create a new one.

IPC连接监控进程，如果进程崩溃，将显示sad tab通知用户。
Sandboxing the renderer

Given Webkit is running in a separate process, we have the opportunity to restrict its access to system resources. For example, we can ensure that the renderer's only access to the network is via its parent browser process. Likewise, we can restrict its access to the filesystem using the host operating system's built-in permissions.

In addition to restricting the renderer's access to the filesystem and network, we can also place limitations on its access to the user's display and related objects. We run each render process on a separate Windows "Desktop" which is not visible to the user. This prevents a compromised renderer from opening new windows or capturing keystrokes.
Giving back memory

Given renderers running in separate processes, it becomes straightforward to treat hidden tabs as lower priority. Normally, minimized processes on Windows have their memory automatically put into a pool of "available memory." In low-memory situations, Windows will swap this memory to disk before it swaps out higher-priority memory, helping to keep the user-visible programs more responsive. We can apply this same principle to hidden tabs. When a render process has no top-level tabs, we can release that process's "working set" size as a hint to the system to swap that memory out to disk first if necessary. Because we found that reducing the working set size also reduces tab switching performance when the user is switching between two tabs, we release this memory gradually. This means that if the user switches back to a recently used tab, that tab's memory is more likely to be paged in than less recently used tabs. Users with enough memory to run all their programs will not notice this process at all: Windows will only actually reclaim such data if it needs it, so there is no performance hit when there is ample memory.

This helps us get a more optimal memory footprint in low-memory situations. The memory associated with seldom-used background tabs can get entirely swapped out while foreground tabs' data can be entirely loaded into memory. In contrast, a single-process browser will have all tabs' data randomly distributed in its memory, and it is impossible to separate the used and unused data so cleanly, wasting both memory and performance.
Plug-ins

Firefox-style NPAPI plug-ins run in their own process, separate from renderers. This is described in detail in Plugin Architecture.