[b]问题：[/b]
（1）建立一个永不崩溃或挂起的渲染引擎几乎是不可能的。
（2）建立一个完全安全的渲染引擎也几乎是不可能的。
在某些方面，现在的浏览器类似过去的单用户、多任务的老式操作系统。再这样的系统中，一个有问题的应用会引起整个操作系统崩溃，在现在的某些浏览器中一个有问题的页面也会引起整个浏览器的崩溃，不管是在某一个页面或者一个插件中的bug。
现在的操作系统已经非常稳健，因为它把应用分别放在不同的进程中。一个应用崩溃不会引起其它应用或操作系统崩溃。一个进程也不允许访问其它进程的数据。
[b]浏览器的架构[/b]
chromium浏览器将每一个浏览器tab的渲染引擎放在不同的进程中，以便保护整个浏览器受到其中某一个tab中ug或故障的影响。chromium浏览器也显示每一个渲染引擎访问其它引擎或操作系统的能力。在某些方面，这种机制使整个浏览器更适合于现在操作系统的内存保护和访问控制。
主进程负责运行UI、管理tab和插件进程，被称作“浏览器进程”或者“浏览器”。
tab进程被称为“渲染进程”或“渲染器”。渲染器使用Webkit开源布局引擎解释和布局HTML。
渲染进程管理
每个渲染进程拥有一个全局的RenderProcess对象负责管理与父进程的通讯和保存全局状态。浏览器进程对每个渲染进程有一个对应的RenderProcessHost对象，负责管理浏览器状态和与渲染器通讯。浏览器与渲染器之间采用Chromium's IPC system通讯。
视图管理
每个渲染器进程拥有一个或多个RenderView对象，由RenderProcess负责管理。每一个视图对应一个一个tab的内容。在浏览器中，每个渲染器对应的RenderProcessHost都有相应的RenderViewHost对应一个渲染器中的视图。每个视图拥有一个视图ID用来区别同一个渲染器中的多个视图。这些ID在同一个渲染器中是惟一的，但是在浏览器中不是唯一。所以要标识一个视图渲染一个RenderProcessHost和一个视图ID。浏览器与tab内容之间的通讯通过RenderViewHost对象，它指导如何发送一个消息通过RenderProcessHost到RenderProcess，直至RenderView.
组件和接口
在渲染器进程中：
- RenderProcess和浏览器中对应的RenderProcessHost维持IPC。每个渲染器进程只能有一个RenderProcess对象。这样才能保证浏览器和一个渲染器进程能正常通讯。
- RenderView对象能与浏览器进程中对应的RenderViewHost通讯（通过RenderProcess），而WebKit只负责布局。RenderView对象描述了tab中的一个页面或一个弹出窗口内容。
在浏览器进程中：
- Browser对象代表顶层窗口。
- RenderProcessHost对象在浏览器中代表一个渲染器，并负责与渲染器的IPC通讯。在浏览器中每个渲染器有一个对应的RenderProcessHost对象。
共享渲染器进程
通常每一个窗口或tab都会打开一个新的进程。浏览器将建立一个新的进程并通知它建立一个单独的RenderView.
有时候在tab或窗口中共享一个渲染进程是有必要的或可取的。一个web应用打开一个新的窗口并同步通讯，例如使用JavaScript语言的window.open打开一个窗口。在这里，当我们创建一个新的窗口或tab时，我们需要复用打开窗口的那个进程。如果打开的进程数量太多，或者一个进程已经处理了同一个域的窗口或tab,我们也需要一些策略将一些新的tab赋给已经打开的进程。这些策略在Process Models里详细描述。
检测崩溃的或错误行为的渲染器
浏览器进程中每一个IPC连接会检测那些渲染器进程句柄。如果这些句柄被发出信号，渲染过程就崩溃了，并通知了标签的崩溃。现在，我们显示一个“sad tab"屏幕去通知用户渲染器已经崩溃。页面可以通过按重载键或打开新的导航去重新加载。当这一切发生的时候，我们要注意没有一个新的进程被创建。
渲染器中的沙箱
既然WebKit运行在一个独立的进程中，我们可以限制它去访问系统资源。例如，我们可以确认渲染器只能通过父进程（浏览器进程）访问网络。同样的，我们可以利用主机操作系统那个内建的权限机制限制它访问文件系统。
附加的，既然能限制渲染器访问文件系统和玩过，同样我们也能限制访问用户显示和相关的对象。我们在一个单独的窗口“桌面”上运行每个渲染程序，这对用户是不可见的。这样可以防止渲染器打开一个新的窗口或截获键盘敲击而带来的危害。
释放内存
渲染器运行在独立的进程中，这就使隐藏低优先级的tab变成很简单。在Windows中最小化的进程会自动把他们的内存放入一个池中“availabel memory"。在一个少内存的环境中，Windows将把这部分内存交换到硬盘上直到变成高优先级内存再给交换出来。这样就会使用户可见的程序响应更快。我们可以
把这个策略应用到隐藏tab中。当一个渲染器进程不在是顶层tab时，我们可以通过提示系统将这部分内存交换到硬盘上来释放这个进程所占的物理内存。因为我们发现减少woking set的大小能降低tab交换的性能，当用户切换两个tab时候，会逐渐释放内存。这意味着，如果用户切换回一个最近使用的标签，该标签的内存更会被页面化相对于最近很少用到的tab。有足够的内存用户运行所有的程序将不会注意到这个过程：Windows只在有需要的时候回收内存，如果有足够的内存就不会有性能损失。
这有助于我们获得低内存情况下更优化的内存占用。与很少使用的背景选项卡相关联的内存可以得到完全换出，而前台tab“的数据可以完全加载到内存中。与此相反，一个单一的进程浏览器将具有所有tab数据随机分布在其存储器，并且它不可能将使用和未使用的数据完全分开出来，浪费内存和性能。
[b]问题：[/b] （1）建立一个永不崩溃或挂起的渲染引擎几乎是不可能的。 （2）建立一个完全安全的渲染引擎也几乎是不可能的。 在某些方面，现在的浏览器类似过去的单用户、多任务的老式操作系统。再这样的系统中，一个有问题的应用会引起整个操作系统崩溃，在现在的某些浏览器中一个有问题的页面也会引起整个浏览器的崩溃，不管是在某一个页面或者一个插件中的bug。 现在的操作系统已经非常稳健，因为它把应用分别放在不同的进程中。一个应用崩溃不会引起其它应用或操作系统崩溃。一个进程也不允许访问其它进程的数据。 [b]浏览器的架构[/b] chromium浏览器将每一个浏览器tab的渲染引擎放在不同的进程中，以便保护整个浏览器受到其中某一个tab中ug或故障的影响。chromium浏览器也显示每一个渲染引擎访问其它引擎或操作系统的能力。在某些方面，这种机制使整个浏览器更适合于现在操作系统的内存保护和访问控制。 主进程负责运行UI、管理tab和插件进程，被称作“浏览器进程”或者“浏览器”。 tab进程被称为“渲染进程”或“渲染器”。渲染器使用Webkit开源布局引擎解释和布局HTML。
渲染进程管理 每个渲染进程拥有一个全局的RenderProcess对象负责管理与父进程的通讯和保存全局状态。浏览器进程对每个渲染进程有一个对应的RenderProcessHost对象，负责管理浏览器状态和与渲染器通讯。浏览器与渲染器之间采用Chromium's IPC system通讯。 视图管理 每个渲染器进程拥有一个或多个RenderView对象，由RenderProcess负责管理。每一个视图对应一个一个tab的内容。在浏览器中，每个渲染器对应的RenderProcessHost都有相应的RenderViewHost对应一个渲染器中的视图。每个视图拥有一个视图ID用来区别同一个渲染器中的多个视图。这些ID在同一个渲染器中是惟一的，但是在浏览器中不是唯一。所以要标识一个视图渲染一个RenderProcessHost和一个视图ID。浏览器与tab内容之间的通讯通过RenderViewHost对象，它指导如何发送一个消息通过RenderProcessHost到RenderProcess，直至RenderView. 组件和接口 在渲染器进程中：
- RenderProcess和浏览器中对应的RenderProcessHost维持IPC。每个渲染器进程只能有一个RenderProcess对象。这样才能保证浏览器和一个渲染器进程能正常通讯。
- RenderView对象能与浏览器进程中对应的RenderViewHost通讯（通过RenderProcess），而WebKit只负责布局。RenderView对象描述了tab中的一个页面或一个弹出窗口内容。
- Browser对象代表顶层窗口。
- RenderProcessHost对象在浏览器中代表一个渲染器，并负责与渲染器的IPC通讯。在浏览器中每个渲染器有一个对应的RenderProcessHost对象。