Firefox 64bit 多进程

由于Firefox在高分屏上的完美表现和Chrome的差强人意，我重新开始使用Firefox。

 

Firefox的优点自然不用多说，强大的插件系统。但问题也十分显著，就是捉急的性能。不过我找到了解决方案。Firefox发展这么多年，终于提供了64bit和多线程的实现。64bit不用多提，去年底Firefox开始提供官方64位版本，直接可以下载。

 

对于多线程，这是一个尚在测试中的特性，需要安装开发者版本才能开启。在官网上下载Developer Edition后安装，默认开启该特性。

多线程解决了什么样的问题？在Mozilla官网有如下说明：

 

动机

在本文章中

1. 性能
2. 安全
3. 稳定性

使 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中，只有崩溃的内容进程会被终止。

 

来自 <https://developer.mozilla.org/zh-CN/Firefox/Multiprocess_Firefox/Motivation>

 

上面说的这些动机早已在Chrome中用了很久了，Firefox想必是因为历史遗留代码问题太多，修改起来太过麻烦，所以到现在e10s项目才基本成熟。不过话说回来，开始了多进程后，Firefox完全没有了之前的在加载大的页面时、表单中输入、或者滚动时，浏览器暂时性失去响应的问题。举个栗子，之前Firefox开一个Flash的直播页面几乎就要卡死了，现在不管怎么开网页都如丝滑般顺畅。

 

不过目前这个特性和accessibilityfeatures有冲突，会导致多进程选项被关闭并且无法启用，这个时候只能重置一下Firefox，然后重新同步插件。