我们被告知Google Chrome在一个单独的进程中运行每个标签。因此,一个选项卡中的崩溃不会导致其他选项卡中出现问题。
AFAIK,多进程主要用于没有GUI的程序中。我从来没有读过任何可以将多个GUI进程嵌入到单个GUI进程中的技术。
Chrome是如何做到这一点的?
我问这个问题是因为我正在设计CCTV软件,它将使用来自多个摄像头制造商的视频解码SDK,其中一些远不稳定。所以我更喜欢在不同的进程中运行这些SDK,我认为这类似于Chrome。
发布于 2010-01-07 18:25:28
基本上,它们使用另一个过程将它们全部粘合到GUI中。
Google Chrome创建了三种不同类型的进程:浏览器、渲染器和插件。
浏览器:只有一个浏览器进程,它管理标签、窗口和浏览器的"chrome“。此过程还处理与磁盘、网络、用户输入和显示的所有交互,但它不会尝试解析或呈现来自web的任何内容。
渲染器:浏览器进程创建许多渲染器进程,每个进程负责渲染web页面。渲染器进程包含处理HTML、JavaScript、CSS、图像等的所有复杂逻辑。Chrome使用开源的WebKit渲染引擎实现了这一点,苹果的Safari web浏览器也使用了该引擎。每个渲染器进程都在沙箱中运行,这意味着它几乎不能直接访问磁盘、网络或显示器。所有与web应用程序的交互,包括用户输入事件和屏幕绘制,都必须通过浏览器过程。这样,浏览器进程就可以监控渲染器中的可疑活动,如果怀疑发生了漏洞攻击,就会将其杀死。
插件:浏览器进程还会为正在使用的每种类型的插件创建一个进程。这些进程只包含插件本身,以及一些胶水代码,使它们可以与浏览器和渲染器交互。
来源:Chromium Blog: Multi-process Architecture
发布于 2010-01-08 22:48:13
在这种情况下,基本的设计是有趣的。
下面是相关的design documents,特别是multi-process architecture部分。
架构概述:
发布于 2013-12-01 13:04:48
我只是给出了第一个答案(解释“浏览器”、“渲染器”和“插件”的那个uptick...that似乎是最完整的,对我来说很有意义。
我要补充的只是一些关于为什么Google的设计是这样的评论,以及为什么它一直是我的总体/日常浏览器的第一选择。(尽管我意识到问题是怎么问的(而不是为什么)。)
这样的设计使得各个组件在单独的进程中拥有它们的代码,从而允许操作系统“内存保护”进程,使它们不会以非明确设计的方式相互修改。
在这样的设计中,能够读取和写入共享数据的唯一部分是那些被设计为需要访问该数据的部分,并且允许对该访问是仅仅是“读”访问还是“读”和“写”访问等进行控制。由于这些访问控制是在硬件中实现的,因此它们是不会违反访问规则的坚定保证。因此,来自其他作者和公司的插件和扩展,在单独的选项卡/进程中运行,不能相互破坏。
这种设计的效果是,它最大限度地减少了更改某些代码或数据的机会,而这些代码或数据不是设计用于更改的。这是出于安全原因,并使代码更可靠,错误更少。
对我来说,谷歌拥有如此复杂的设计本身就很好地证明了这样一个事实,即谷歌似乎很好地掌握了这些概念,并打造了一款卓越的产品。(也就是说,作为一个web开发人员,我们仍然需要在多个浏览器上测试我们的web代码。而且,像Firefox这样的浏览器已经存在很长时间了,并且拥有一组优秀的与web开发人员相关的“附加组件”,对于某些任务来说仍然有一些优势。)
但是,对于日常的整体浏览器使用,对于几乎所有的任务,Chrome浏览器已经成为我的第一选择。(这只是我的观点,当然还有YMMV。)
https://stackoverflow.com/questions/2019500
复制相似问题