Google Chrome如何将标签分离成单独的流程,同时看起来像一个单一的应用程序?

基本上,它们使用另一个过程将它们粘合到GUI中。

浏览器:

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

浏览器进程还为正在使用的每种类型的插件(如Flash、Quicktime或Adobe Reader)创建一个进程。这些过程只包含插件本身,以及一些让它们与浏览器和渲染器交互的粘合代码。

资料来源: Chromium Blog: Multi-process Architecture

在这种情况下,基本设计很有趣。

以下是相关的 design documents multi-process architecture

架构概述:

上涨…这似乎是最完整的,对我来说很有意义。

用于整体/每日浏览器(虽然我知道这是怎么(而不是为什么)的 (被问到的问题。)

设计使单个组件的代码在单独的进程中允许 其他未在中明确设计的方式。

在这样的设计中,唯一可以读写共享数据的部分是 设计用于访问该数据的部件,并允许控制 该访问只是“读”访问或“读”和“写”访问,等等,并且 不能违反访问规则。因此,插件和扩展 来自其他作者和公司,在单独的选项卡/流程中运行,无法 彼此分手。

这种设计的效果是将改变的机会降至最低 使代码更加可靠,错误更少。

制造了一种优质的产品(也就是说,作为一名web开发人员,我们仍然必须进行测试 已经存在很长一段时间了,并且拥有一个优秀的web开发人员相关团队 “附加组件”对于某些任务仍有一些优势。)

但是,对于日常的整体浏览器使用,对于几乎所有的任务,Chrome浏览器 (这只是我的意见,当然还有YMMV。)

渲染网页的大部分工作是计算内容的确切位置(即,将每张图片放置在何处,渲染每段文本的颜色)。这项工作是在一个单独的过程中完成的。一旦这个单独的进程确定了所有东西的去向,它就会将这些信息传递到主Chrome进程,主Chrome进程会在屏幕上绘制所有元素。

窗口对象——用于实现窗口小部件的小的、可绘制的矩形区域,而不是用户所看到的窗口——可以使用共享内存或X协议在进程之间完全共享。检查工具箱的文档。