Google Chrome如何将选项卡隔离到单独的进程中，同时看起来像一个单一的应用程序？

Question

我们听说Google Chrome在单独的进程中运行每个选项卡，因此一个选项卡的崩溃不会影响其他选项卡。

据我所知，多进程大多用于没有GUI的程序。我从未读过任何技术可以将多个GUI进程嵌入到一个进程中。

那么，Chrome是如何做到这一点的？

我提出这个问题是因为我正在设计CCTV软件，该软件将使用来自多个摄像机制造商的视频解码SDK，其中一些SDK远非稳定。因此，我更喜欢在不同的进程中运行这些SDK，我认为这类似于Chrome。

- faceclean

---

下载源代码并查看！如果您需要类似的解决方案，这将对您非常有益。 Google Chrome是开源的。 - Conor

我的Chromium源代码检出大小为19.7 GB，包含545,764个文件。点击上面高亮的链接可以更快地浏览！ - Janik Zikovsky

Answer 1

基本上，他们使用另一种方法将它们全部粘合在GUI中。

谷歌 Chrome 创建了三种不同类型的进程：浏览器、渲染器和插件。

浏览器：只有一个浏览器进程，负责管理浏览器的选项卡、窗口和“chrome”。此进程还处理与磁盘、网络、用户输入和显示的所有交互，但不会尝试解析或呈现来自Web的任何内容。

渲染器：浏览器进程创建许多渲染器进程，每个进程负责呈现 Web 页面。渲染器进程包含处理 HTML、JavaScript、CSS、图像等所有复杂逻辑。Chrome 使用开源的 WebKit 渲染引擎实现这一点，该引擎也被苹果的 Safari Web 浏览器使用。每个渲染器进程都运行在沙盒中，这意味着它几乎没有直接访问磁盘、网络或显示器的权限。所有与 Web 应用程序的交互，包括用户输入事件和屏幕绘制，都必须通过浏览器进程进行。这使得浏览器进程可以监视渲染器以寻找可疑活动，如果怀疑发生了漏洞利用，则杀死它们。

插件：浏览器进程还为每种使用的插件（如 Flash、QuickTime 或 Adobe Reader）创建一个进程。这些进程只包含插件本身以及一些粘合代码，以让它们与浏览器和渲染器进行交互。

来源：Chromium Blog: 多进程架构

- Daniel Vassallo

---

我不明白。这些选项卡似乎属于浏览器进程，但是这些渲染程序如何在属于另一个进程的选项卡上绘制图片和文本呢？ - faceclean

它们并不属于浏览器进程。浏览器进程仅仅是管理它们（创建、停止和监控）。浏览器进程也创建了浏览器GUI，但标签页的内部逻辑（容易崩溃的风险部分）由单独的渲染进程处理（每个标签页一个）。 - Daniel Vassallo

很好的总结！还有一件事要补充，每个Chrome扩展都在它们自己的进程中运行。如果你想知道进程之间如何通信，请查看Chromium源代码库中的IPC部分。 - Mohamed Mansour

嗯，有趣。我可以看出HTML、CSS、图像等渲染器可能以某种方式将绘图信息序列化到浏览器进程中，以便它可以在正确的窗口中绘制。但是对于插件输出的图形，不能说同样的话。不知道他们是否只是让插件呈现到一个离屏表面，然后将其复制到浏览器窗口上 - 但那似乎会太慢了。而且视频播放也不会太好。也许我们需要查看源代码！ - Raj

它并没有完全回答渲染过程是如何工作的问题。渲染过程是否在屏幕上绘制？如果是，它如何与屏幕的“chrome”部分同步，这部分是单独渲染的？渲染过程是否通过RPC传递图像数据以供浏览器进程实际绘制？那似乎会非常慢。如果你有选项卡等由一个进程渲染，而另一个进程渲染“内容”，那么这似乎很奇怪。 - jomamaxx

Answer 2

在这个背景下，基本设计非常有趣。

以下是相关的设计文档，特别是多进程架构部分。

架构概述：

- Nickolay

---

一张图片胜过千言万语！ - Neeraj

Answer 3

我刚刚给出了第一个答案（解释“浏览器”与“渲染器”与“插件”的答案），并获得了一些赞同...这似乎是最完整的，对我来说很有道理。

我要补充的是关于为什么Google的设计是这样的，以及为什么它总是我首选的综合/日常浏览器的看法。（尽管我意识到问题是如何而不是为什么。）

设计使得单独的组件在不同的进程中具有其代码，可以使操作系统从意外地（或故意地）修改未明确设计的方式中“内存保护”进程。

在这样的设计中，唯一能够读取和写入共享数据的部分是那些需要访问该数据的部分，并且允许控制是否只是“读取”访问或“读取”和“写入”访问等。由于这些访问控件是在硬件中实现的，因此它们是不能被违反的坚定保证。因此，其他作者和公司的插件和扩展，运行在单独的标签/进程中，不能互相破坏。

这种设计的效果在于最大限度地减少更改某些未设计更改的代码或数据的机会。出于安全原因，这使得代码更加可靠，错误更少。

谷歌拥有如此复杂的设计，这对我来说是一个很好的证明，证明谷歌似乎非常了解这些概念，并构建了一款优秀的产品。（也就是说，作为 Web 开发人员，我们仍然必须使用多个浏览器测试我们的 Web 代码。而像 Firefox 这样的浏览器已经存在了很长时间，并且拥有一组优秀的与 Web 开发相关的“附加组件”，对于某些任务仍然具有一些优势。）

但是，对于日常的整体浏览器使用，几乎所有任务，Chrome 浏览器已成为我的首选。 （仅代表个人观点，当然，你的情况可能有所不同。）

- David

Answer 4

大部分渲染网页的工作是找出所有元素的确切位置（即放置每个图片的位置，渲染每块文本的颜色）。这项工作是在一个单独的进程中完成的。一旦单独的进程找到了所有元素的位置，它就会将这些信息传递给主要的Chrome进程，该进程会将所有元素绘制在屏幕上。

您的视频SDK系统的设置并不清楚。但是您可以有一个解压缩视频的进程和另一个将其呈现到显示器的进程。然而，最可能的情况是您正在使用OpenGL或DirectX。这些API可能会对如何将事物分配给不同的进程施加一些限制。

- speedplane

---

关于您的第一段，我意识到Chrome没有这样做，但该技术与OLE并没有太大区别。您有一个嵌入Excel文档的Word文档。通过右键单击Word中的电子表格并选择“打开”，启动Excel进程以在单独的进程中编辑文档。现在，如果您在Excel中输入内容，您将实时在Word侧看到更改。其工作原理是，在Word内部运行了一个特定于Excel的渲染器，它使用COM IDataObject进行进程间通信以获取要绘制的数据。 - zumalifeguard

OLE是一种远程过程调用（RPC）架构。RPC确实是两个进程在同一台机器上相互通信的一种方式（然而，在过去几年中，它已经不再流行）。 - speedplane

Answer 5

我看到了一篇文章，我认为可以回答这个问题： https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/ 基本上，底层技术是IPC和共享内存。有两种渲染模式：GPU加速和软件渲染。

GPU加速

客户端（在渲染器或NaCl模块中运行的代码）不直接调用系统API，而是将它们序列化并放入环形缓冲区（命令缓冲区），该缓冲区驻留在其与服务器进程之间共享的内存中。

服务器（在较少限制的沙盒中运行的GPU进程，允许访问平台的3D API）从共享内存中获取序列化的命令，解析它们并执行相应的图形调用。

软件渲染。

这是旧的软件渲染模型，在该模型中，渲染器进程通过 IPC 和共享内存将页面内容的位图传递给浏览器进程进行显示。

- Sun Rui

Answer 6

窗口对象 - 用于实现小部件的可绘制矩形区域，而不是用户看到的窗口 - 可以使用共享内存或X协议在进程之间完美共享。请查阅您工具包的文档。

- Tobu

---

每个HWND都属于特定的进程。 - zumalifeguard

@zuma，那并不与我所写的相矛盾。 - Tobu