Google Chrome 如何将选项卡隔离到单独的进程中，同时看起来像单个应用程序？
我们被告知 Google Chrome 在单独的进程中运行每个选项卡。因此，一个选项卡中的崩溃不会导致其他选项卡出现问题。
AFAIK，多进程主要用于没有 GUI 的程序中。我从未读过任何可以将多个 GUI 进程嵌入到一个进程中的技术。
Chrome 是如何做到这一点的？
我问这个问题是因为我正在设计闭路电视软件，该软件将使用多个摄像机制造商的视频解码 SDK，其中一些还很不稳定。所以我更喜欢在不同的进程中运行这些SDK，我认为这与Chrome类似。
We have been told that Google Chrome runs each tab in a separate process. Therefore a crash in one tab would not cause problems in the other tabs.
AFAIK, multi-processes are mostly used in programs without a GUI. I have never read any technique that could embed multiple GUI processes into a single one.
How does Chrome do that?
I am asking this question because I am designing CCTV software which will use video decoding SDKs from multiple camera manufactures, some of which are far from stable. So I prefer to run these SDKs in different processes, which I thought is similar to Chrome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
基本上，他们使用另一个过程将它们全部粘合到 GUI 中。
Google Chrome 创建三种不同类型的进程：浏览器、渲染器和插件。
浏览器：只有一个浏览器进程，它管理浏览器的选项卡、窗口和“chrome”。此进程还处理与磁盘、网络、用户输入和显示的所有交互，但它不会尝试解析或呈现来自 Web 的任何内容。
渲染器：浏览器进程创建许多渲染器进程，每个渲染器进程负责渲染网页。渲染器进程包含处理 HTML、JavaScript、CSS、图像等的所有复杂逻辑。 Chrome 使用开源 WebKit 渲染引擎实现了这一点，Apple 的 Safari Web 浏览器也使用该引擎。每个渲染器进程都在沙箱中运行，这意味着它几乎无法直接访问磁盘、网络或显示器。与 Web 应用程序的所有交互（包括用户输入事件和屏幕绘制）都必须经过浏览器进程。这使得浏览器进程可以监视渲染器是否存在可疑活动，如果怀疑发生了漏洞，则将其杀死。
插件：浏览器进程还为正在使用的每种类型的插件（例如 Flash、Quicktime 或 Adobe Reader）创建一个进程。这些进程只包含插件本身，以及一些胶水代码，让它们与浏览器和渲染器交互。
来源：Chromium 博客：多进程架构
Basically, they use another process that glues them all together into the GUI.
Google Chrome creates three different types of processes: browser, renderers, and plug-ins.
Browser: There's only one browser process, which manages the tabs, windows, and "chrome" of the browser. This process also handles all interactions with the disk, network, user input, and display, but it makes no attempt to parse or render any content from the web.
Renderers: The browser process creates many renderer processes, each responsible for rendering web pages. The renderer processes contain all the complex logic for handling HTML, JavaScript, CSS, images, and so on. Chrome achieves this using the open source WebKit rendering engine, which is also used by Apple's Safari web browser. Each renderer process is run in a sandbox, which means it has almost no direct access to the disk, network, or display. All interactions with web apps, including user input events and screen painting, must go through the browser process. This lets the browser process monitor the renderers for suspicious activity, killing them if it suspects an exploit has occurred.
Plug-ins: The browser process also creates one process for each type of plug-in that is in use, such as Flash, Quicktime, or Adobe Reader. These processes just contain the plug-ins themselves, along with some glue code to let them interact with the browser and renderers.
Source: Chromium Blog: Multi-process Architecture
在这种情况下，基本设计很有趣。
以下是相关的设计文档，特别是多进程架构部分。
架构概述：
In this context, the fundamental design is interesting.
Here are the relevant design documents, in particular the multi-process architecture section.
An architectural overview:
我刚刚给出了第一个答案（解释“浏览器”与“渲染器”与“插件”的答案）
上升……这似乎是最完整的，对我来说很有意义。
我唯一要补充的是关于为什么谷歌的设计的一些评论
就是这样，并就为什么它一直是我的第一选择发表意见
对于整体/日常浏览器。 （尽管我意识到这是如何（而不是为什么）
所提出的问题。）
设计使各个组件的代码位于单独的进程中允许
操作系统“内存保护”进程免遭意外（或故意）修改每个进程
其他方式未明确设计。
这种设计中唯一可以读取和写入共享数据的部分是那些
设计为需要访问该数据的部分，并允许控制是否
该访问只是“读”访问或“读”和“写”访问等。而且，因为
这些访问控制是在硬件中实现的，它们是坚定的保证
不能违反访问规则。因此，插件和扩展
来自其他作者和公司，在单独的选项卡/进程中运行，不能
打破彼此。
这种设计的效果是最大限度地减少改变的机会
一些原本无法更改的代码或数据。这是为了安全
原因并使得代码更可靠、错误更少。
对我来说，谷歌拥有如此复杂的设计这一事实就很好地证明了
事实上，谷歌似乎很好地掌握了这些概念，并且已经
打造了卓越的产品。 （也就是说，作为一名网络开发人员，我们仍然必须测试
我们的网络代码适用于多个浏览器。并且，诸如 Firefox 之类的浏览器具有
已经存在很长时间了，并且拥有一支优秀的网络开发人员相关团队
“附加组件”对于某些任务仍然具有一些优势。）
但是，对于日常整体浏览器使用，对于几乎所有任务，Chrome 浏览器
已成为我的第一选择。 （只是我的意见，当然，YMMV。）
I just gave the first answer (the one explaining 'browser' vs 'renderers' vs 'plugins'
an uptick...that seems the most complete and makes good sense to me.
The only thing I'll add are just a few comments more about WHY Google's design
is the way it is, and give an opinion about why it's always been my first choice
for an overall/every-day browser. (Tho I realize that HOW (and not WHY) was
the question being asked.)
Designing so that individual components have their code in separate processes allows
the OS to'memory-protect' processes from accidently (or on purpose) modifying each
other in ways not explicitly designed-in.
The only parts in such a design that can both read and write shared data are those
parts that are designed to NEED to access that data, and allows control on whether
that access is just 'read' access or 'read' and 'write' access, etc. And, since
those access controls are implemented in the hardware, they are firm guarantees
that the access rules cannot be violated. Thus, plugins and extensions
from other authors and companies, running in separate tabs/processes, cannot
break each other.
Such a design has the effect that it minimises the chances of changing
some code or data that wasn't designed to be changed. This is for security
reasons and makes for more reliable, less buggy code.
The mere fact Google has such an intricate design is, to me, good testimony to
fact that Google seems to have an excellent grasp of these concepts and has
built a superior product. (That said, as a web-developer, we still must test
our web code with multiple browsers. And, browsers such as Firefox, having
been around for a long time and having an excellent group of web-developer related
'add-ons' still has some advantages for some tasks.)
But, for everyday overall browser use, for almost all tasks, the Chrome browser
has become my first choice. (Just my opinion, and of course, YMMV.)
渲染网页的大部分工作是弄清楚事物到底去哪里（即每张图片放置在哪里，每段文本渲染什么颜色）。这项工作是在一个单独的过程中完成的。一旦单独的进程确定了所有内容的去向，它就会将该信息传递给主 Chrome 进程，该进程在屏幕上绘制所有元素。
目前尚不清楚您的视频 sdk 系统是如何设置的。但是您可以有一个进程解压缩视频，另一个进程将视频渲染到显示器上。不过，您最有可能使用的是 opengl 或 DirectX。这些 API 可能会对如何在不同进程之间拆分事物施加一些限制。
Most of the work of rendering a web page is figuring out where exactly things go (i.e. where to place each picture, what color to render each piece of text). That work is done in a separate process. Once the separate process has figured where everything goes, it passes that information on to the main Chrome process which draws all of the elements on the screen.
It isn't clear exactly how your video sdk system is setup. But you could have one process that decompresses the video and another process that renders it to the display. Most likely however, you are using opengl or DirectX. Those APIs smay impose some limitations on how you split things up among different processes.
我看到一篇文章，我认为可以回答这个问题：
https://www.chromium.org/developers /design-documents/gpu-accelerated-compositing-in-chrome/
基本上，底层技术是IPC和共享内存。有两种渲染模型：GPU 加速和软件渲染。
GPU 加速
软件渲染
I came across an article, which I think can answer this question:
https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/
Basically, the underlying techniques are IPC and shared memory. There are two rendering models: GPU accelerated and software rendering.
GPU accelerated
software rendering
窗口对象（用于实现小部件的小型可绘制矩形区域，而不是用户所看到的窗口）可以使用共享内存或 X 协议在进程之间完美共享。检查您的工具包的文档。
Window objects - the small, drawable rectangular areas used to implement widgets, not what the user sees as a window - can perfectly be shared between processes, using shared memory or the X protocol. Check your toolkit's docs.