动机

使 Firefox 在单独的进程中运行内容的主要原因：性能、安全和稳定性。

性能

Mozilla 在过去两年对性能的工作重点是浏览器的响应速度。目标是减少 “jank”—在加载大的页面时、表单中输入、或者滚动时，浏览器暂时性失去响应。响应问题在当今较高吞吐量的网络上日益显著。这些工作大部分已被 Snappy 项目完成。主要的重点在：

• 将运行时间长的操作移入单独的线程，使主线程可以继续向用户做出响应。
• 异步或者在其他线程进行 I/O，使主线程不必等待磁盘。
• 将运行时间长的代码拆分成较短片段，并且在事件循环之间运行。增量式垃圾收集就是一个例子。

大部分能轻易做到的事情在这些领域已经完成。剩下的问题比较难以解决。举例来说，JavaScript 执行和布局都发生在主线程，并且阻挡着事件循环。在单独的线程中运行这些组件是困难的，因为它们访问数据，像是 DOM，它们不是线程安全的。作为替代方案，我们已经考虑让事件循环运行在 JavaScript 执行的中间，但这样做会毁掉大量 Firefox 其他地方做出的假设（更不用提附加组件）。

在一个单独的进程中运行网络内容，是这些方法的一个不错的替代品。类似线程的方式，Firefox 可以在 JavaScript 和布局在内容进程中运行时运行事件循环。但是不同于线程，用户界面（UI）的代码不能访问内容 DOM 或者其他内容的数据结构，因此没有必要进行锁定或者线程安全。而不足之处是，理所当然的，任何在 Firefox UI 进程中运行的需要访问内容数据的代码，都必须明确的通过消息传递的方式来访问内容数据。

我们觉得这种权衡有道理，有几个原因：

• Firefox 代码访问内容 DOM 并不是很常见。
• 与 Firefox OS 共享的代码已经使用消息传递。
• 在多进程模型中，使用消息传递访问内容失败的 Firefox 代码将明显的失败，一致的方式。在线程模型中，没有适当锁定的访问内容的代码将以微妙的方式失败，很难调试。

安全

目前来说，如果某人发现了一个 Firefox 中的可利用漏洞，他们能够接管用户的计算机。有很多种技术来缓解这种问题，但其中最强大的是沙盒。从技术上讲，沙盒不需要多个进程。但是，涵盖沙盒的单进程 Firefox 并不会很有用。沙盒能阻止进程执行，一个乖巧进程绝不会做的操作。遗憾的是，乖巧的 Firefox 进程（尤其是已安装附加组件的 Firefox）会访问很多网络和文件系统。因此，对单进程的 Firefox 沙盒不能限制太多。

在多进程 Firefox 中，内容进程将被沙盒化。一个乖巧的内容进程不会直接访问文件系统；它必须询问主线程来执行请求。在那时，主进程可以验证请求是否安全和合理。因此，对内容进程的沙盒化可以是相当严格的。我们希望这样的布局可以使 Firefox 更难被安全漏洞所利用。

稳定性

目前来说，在网页中运行的代码出现崩溃将导致整个浏览器崩溃。而多进程 Firefox 中，只有崩溃的内容进程会被终止。