本文档描述了Chromium的顶层架构设计问题背景构建一个渲染引擎没有崩溃和挂起基本上是不可能的，构建一个完全安全的渲染引擎基本上是不可能的渲染引擎可能。在某些方面，2006年左右的网络浏览器就像过去的单用户、多任务操作系统。正如某些操作系统中出现故障的应用程序可能会挂起整个系统一样，处理不当的网页也会挂起整个浏览器。单个页面或插件错误可能会导致整个浏览器崩溃并导致所有页面无法使用。现代操作系统相对更健壮，因为它们将应用程序拆分为单独的进程以相互隔离。一个应用程序的崩溃通常不会影响其他应用程序或操作系统，每个用户和其他用户的数据访问也受到限制。架构概述我们为每个浏览器选项卡使用单独的进程，以保护大多数应用程序免受渲染引擎错误和故障的影响。我们还将对每个渲染引擎进程的访问限制为其他渲染引擎进程或系统。这在某种程度上允许浏览器受益于对操作系统的内存保护访问。我们将运行UI并管理选项卡和插件进程的主进程称为“浏览器进程”或“broswer”。同样，具体的tab进程称为“renderprocess”或“renderer”。渲染器使用开源布局引擎Blink来解析HTML布局。管理渲染进程每个渲染进程都有一个全局RenderProcess对象，用于管理与父浏览器进程的通信并维护全局状态。浏览器维护着每个渲染进程对应的RenderProcessHost，用于管理浏览器状态与渲染器之间的通信。浏览器和渲染器通过ChromiumIPC系统进行通信。管理视图每个渲染进程都有一个或多个RenderView对象，由RenderProcess管理，对应于各个选项卡的内容。对应的RenderProcessHost维护着一个RenderViewHost对应于每个渲染器的视图。每个视图都分配了一个ID，以区分同一渲染器中的多个视图。这些ID在同一个渲染器中是唯一的，但在浏览器中不一定是唯一的，所以识别一个视图需要同时使用RenderProcessHost和视图ID。浏览器通过RenderViewHost对象与特定的tab内容通信，通过RenderProcessHost向RenderProcess再向RenderView发送信息。组件和接口在渲染进程中：RenderProcess处理IPC和浏览器进程中对应的RenderProcessHost之间的通信。每个渲染进程只有一个RenderProcess对象。这就是浏览器?渲染器的通信方式。RenderView对象与浏览器进程中相应的RenderProcessHost通信（通过RenderProcess），以及我们的嵌入式WebKit层。该对象表示网页或弹出窗口的内容。在浏览器进程中：Browser对象代表一个顶层浏览器窗口，RenderProcessHost对象代表浏览器端的一个浏览器?渲染器通信IPC连接。每个渲染进程和浏览器进程之间都有一个RenderProcessHost对象。RenderViewHost对象包含与远程RenderView的通信。RenderWidgetHost处理输入并在浏览器中绘制RenderWidget。更详细的工作原理可以参考《Chromium如何显示网页》设计文档分享渲染过程。通常，每一个新的窗口或选项卡都会在一个新的进程中打开。浏览器会打开一个新的进程并创建一个单独的RenderView。但有时候，tab和window之间需要共享渲染过程。Web服务器将打开一个新窗口并希望同步通信，例如，使用Javascript中的window.open。在这种情况下，当我们创建一个新的窗口或标签时，我们需要重用上一个窗口已经打开的过程。当进程过多时，我们也有一些策略，将打开的渲染进程分配给新标签页，或者如果用户已经打开了该域名下页面创建的进程。该策略在流程模型中。检测崩溃或故障的渲染器会监听与浏览器进程通信的每个IPC连接的进程处理程序。如果这些处理程序收到一条消息并且渲染器进程崩溃，则这些选项卡将收到崩溃通知。目前，我们会在屏幕上显示一个“sadtab”，告诉用户渲染进程崩溃了。可以通过按刷新按钮重新加载此页面。这个时候我们也会通知没有进程，需要新建一个进程。渲染沙箱针对的是一个独立的进程，我们使用沙箱来限制对系统资源的访问。比如我们可以保证渲染器只能通过父浏览器进程访问网络。同样，我们也可以利用操作系统内置的权限来限制其对文件系统的访问。除了限制渲染器对文件系统和网络的访问，我们还可以限制访问用户的显示相关权限。我们在用户不可见的单独Windows桌面上运行渲染过程。这可以防止呈现过程打开新窗口或捕获击键。回收内存并让渲染器在单独的进程中运行自然会降低隐藏选项卡的优先级。通常，内存减少的进程会自动将内存分配给“空闲内存”池。在低内存模式下，Windows会在切换到高优先级模块内存之前将此内存交换到硬盘上，以便用户可见的程序可以更快地响应。我们可以将相同的策略应用于隐藏的选项卡。当一个渲染进程没有最高优先级的tab时，我们可以在需要的时候先将这个进程的“workingset”大小从系统内存中释放到硬盘中。因为我们发现减小工作区大小也会降低用户从2个选项卡切换的切换性能。但是当用户有足够的内存来运行他们的程序时，进程不会收到通知：Windows只会在真正需要时回收数据，因此当有足够的内存时不会有性能损失。插件和扩展Firefox风格的NPAPI插件在它们自己的进程中运行，独立于渲染器，如插件架构中详细描述的那样。站点隔离项目在渲染器之间提供更多隔离，包括在单独进程中的Chrome的HTML/Javascript上下文扩展。
