我们被告知 Google Chrome 在单独的进程中运行每个选项卡。因此，一个选项卡中的崩溃不会导致其他选项卡出现问题。
AFAIK，多进程主要用于没有 GUI 的程序中。我从未读过任何可以将多个 GUI 进程嵌入到一个中的技术。
Chrome 是如何做到这一点的？
我问这个问题是因为我正在设计闭路电视软件，它将使用来自多个相机制造商的视频解码 SDK，其中一些远非稳定。所以我更喜欢在不同的进程中运行这些 SDK，我认为这与 Chrome 类似。
问问题
11781 次
5 回答
43
基本上，他们使用另一个过程将它们全部粘合到 GUI 中。
Google Chrome 创建了三种不同类型的进程：浏览器、渲染器和插件。
浏览器： 只有一个浏览器进程，负责管理浏览器的选项卡、窗口和“chrome”。此过程还处理与磁盘、网络、用户输入和显示的所有交互，但它不会尝试解析或呈现来自 Web 的任何内容。
渲染器： 浏览器进程创建了许多渲染器进程，每个渲染器进程负责渲染网页。渲染器进程包含处理 HTML、JavaScript、CSS、图像等的所有复杂逻辑。Chrome 使用开源 WebKit 渲染引擎实现了这一点，Apple 的 Safari 网络浏览器也使用该引擎。每个渲染器进程都在沙箱中运行，这意味着它几乎无法直接访问磁盘、网络或显示器。与 Web 应用程序的所有交互，包括用户输入事件和屏幕绘制，都必须经过浏览器进程。这让浏览器进程可以监视渲染器的可疑活动，如果它怀疑发生了漏洞，则将其杀死。
插件： 浏览器进程还为正在使用的每种类型的插件创建一个进程，例如 Flash、Quicktime 或 Adobe Reader。这些进程只包含插件本身，以及一些让它们与浏览器和渲染器交互的胶水代码。
于 2010-01-07T10:25:28.493 回答
1
我刚刚给出了第一个答案（解释“浏览器”、“渲染器”和“插件”的答案上升了……这似乎是最完整的，对我来说很有意义。
我唯一要补充的是关于为什么谷歌的设计是这样的一些评论，并就为什么它一直是我的整体/日常浏览器的首选给出一个意见。（虽然我意识到被问到的问题是如何（而不是为什么）。）
设计使各个组件的代码在单独的进程中允许操作系统“内存保护”进程免于意外（或故意）以未明确设计的方式相互修改。
这种设计中唯一可以读取和写入共享数据的部分是那些设计为需要访问该数据的部分，并允许控制该访问是否只是“读取”访问或“读取”和“写入”访问等等。而且，由于这些访问控制是在硬件中实现的，它们是不能违反访问规则的坚定保证。因此，来自其他作者和公司的插件和扩展，在单独的选项卡/进程中运行，不能相互破坏。
这样的设计的效果是，它最大限度地减少了更改某些并非旨在更改的代码或数据的机会。这是出于安全原因，并使代码更可靠、错误更少。
对我来说，谷歌拥有如此复杂的设计这一事实很好地证明了谷歌似乎对这些概念有很好的把握，并打造了一款卓越的产品。（也就是说，作为 Web 开发人员，我们仍然必须使用多个浏览器测试我们的 Web 代码。而且，Firefox 等浏览器已经存在了很长时间，并且拥有一组优秀的与 Web 开发人员相关的“附加组件”对于某些任务仍然有一些优势。）
但是，对于日常整体浏览器使用，几乎所有任务，Chrome 浏览器已成为我的首选。 （只是我的看法，当然还有 YMMV。）
于 2013-12-01T05:04:48.063 回答
0
渲染网页的大部分工作是弄清楚事情的确切位置（即每张图片的放置位置，每段文本的渲染颜色）。这项工作是在一个单独的过程中完成的。一旦单独的进程确定了所有内容的去向，它就会将该信息传递给主 Chrome 进程，该进程在屏幕上绘制所有元素。
目前尚不清楚您的视频 SDK 系统是如何设置的。但是您可以有一个解压缩视频的进程和另一个将其呈现到显示器的进程。然而，最有可能的是，您使用的是 opengl 或 DirectX。这些 API 可能会对您在不同进程之间拆分事物的方式施加一些限制。
于 2010-01-08T00:13:11.917 回答
-2
窗口对象 - 用于实现小部件的可绘制的小矩形区域，而不是用户所看到的窗口 - 可以使用共享内存或 X 协议在进程之间完美共享。检查您的工具包的文档。
于 2010-01-09T00:29:50.240 回答