|
阅读：2930回复：5
e10s 多进程功能的发展路线综述
Firefox 在 2017 年一个重要的开发项目就是继续提升乃至完善 e10s 多进程功能。e10s 初次引入是在 Firefox 48.0 版本，之后每个新版本都继续扩大 e10s 测试规模，直到目前超过 60% 的用户已经默认开启 e10s。下面详细描述一下 e10s 从初次引入到未来发展的路线。
Firefox 48： 初次引入 e10s，41% 的用户默认开启。默认开启需满足以下条件：1、未安装任何附加组件。2、未启用任何易用性 accessibility 的工具，如触摸屏。3、不使用从右向左书写的语言。4、不使用 Windows XP 或 Apple OS X 10.6～10.8 及以下的操作系统。 Firefox 49： 安装了特定扩展的用户也可默认开启 e10s，这份白名单包括：
Firefox 50： 到了这个版本，e10s 测试范围继续扩大。安装上述列表以外扩展的用户也有可能开启多进程，只要这些扩展的开发者在扩展文件里面明确标注扩展兼容 e10s 即可。但有一个例外，那就是 Tab Mix Plus，即使扩展开发者标注为兼容 e10s，Firefox 也会阻止安装此扩展的用户默认开启多进程。 使用从右向左书写语言的 Windows 和 Mac OS X 用户已经可以默认开启 e10s 了。默认不开启 e10s 的限制依然包括：1、启用任何易用性 accessibility 的工具，如触摸屏。2、使用 Windows XP 或 Apple OS X 10.6～10.8 及以下的操作系统。3、使用从右向左书写语言的 Linux 用户。 Firefox 51（当前版本）： 除了 Firefox 49 和 50 的要求以外，Firefox 51 额外将 773 个附加组件标记为兼容 e10s，安装以后依然可以默认开启 e10s。 而默认不开启 e10s 的限制依然包括：1、启用任何易用性 accessibility 的工具，如触摸屏。2、使用 Windows XP 或 Apple OS X 10.6～10.8 及以下的操作系统。3、使用从右向左书写语言的 Linux 用户。 Firefox 51 的 e10s 依然是 chrome 界面一个进程，所有标签页共享一个 content 进程，还有一个独立的插件进程。 
Firefox 52： 该版本下，原本使用从右向左书写语言的 Linux 用户也可以默认开启 e10s 了。此外，该版本首次支持 userContent.css 文件，如果不使用 Stylish 只希望简单添加 CSS 修改网页样式的用户就可以正常编辑 userContent.css 文件了。userChrome.css 还不支持。 至于附加组件方面，Fiefox 52+ 基本上还是和之前几个版本一致，但 Tab Mix Plus 不会作为例外条件了，也就是安装该扩展的用户也可以默认开启 e10s 了。 那 Firefox 52 ESR 这个特殊版本呢？我们知道 Firefox 52 ESR 的前一个版本是 Firefox 45 ESR，那时还未开启 e10s。但 Firefox 52 ESR 就会对部分用户开启 e10s 了，但开启的规模和条件还停留在 Firefox 50 版本。Firefox 51 和 52 的不会纳入 ESR。此外，俄语用户也还无法开启 e10s。 还要提一些 Windows XP 下的 Firefox 用户。我们之前提到过 Firefox 52 将是最后一个支持 Windows XP 的版本，从 Firefox 53 开始就不支持 XP 了。所以 Windows XP 下的用户会自动更新到 Firefox 52 ESR 版本，并至少可以支持到 2017 年 9 月的 ESR 安全性修复版本。当然，XP 用户依然无法享受到 e10s。 Firefox 53： 对于 Windows 系统的用户，该版本会新增一个 GPU 的进程，这是因为 Quantum 项目将引入一个合成器 Quantum Compositor，据说可以大幅提高 Firefox 的性能和用户感知。由于显卡 GPU 驱动是导致 Firefox 崩溃的一大原因，因此 GPU 进程会独立出来，提高浏览器稳定性。 至于附加组件，Firefox 53 开始，AMO 官方附加组件中心只支持新的 WebExtensions 扩展的提交，不接受任何新的传统扩展的提交。但传统扩展的更新版本仍会接受提交。传统扩展可使用到 Firefox 57 版本。 Firefox 54： 该版本将首次支持 a11y，也就是易用性 accessibility 工具。这些 a11y 工具包括：屏幕放大镜、屏幕朗读器、触摸屏设备。在网页开发方面，e10s 开启后，用户和开发者可以使用 CSS 来修改 <select> 元素的单选复选按钮了，原来 e10s 开启时是不支持使用 CSS 修改的。 Firefox 54+ 版本会启用更多的 content 子进程，一开始会是 2 个 content 子进程。后续版本可能会添加到最多 4 个 content 子进程。
在 content 进程里面也会真正应用上所谓的 sandboxing 沙盒技术。沙盒可以分级别执行网页代码，相比于以前所有代码执行都在一个进程里面，在实现多进程以后，代码执行只在 content 子进程里发生，并且受到沙盒安全级别的严格限制。 后续版本的沙盒限制会更加严格，用户也可以修改沙盒的安全级别。
Firefox 57： 该版本将是首个只支持 WebExtensions 附加组件的版本，所有传统的附加组件都将无法使用，传统附加组件包括：XUL Overlay 扩展、bootstrapped 扩展、Add-on SDK 扩展、嵌入式 WebExtensions 扩展、完整主题。而词典、语言包、OpenSearch 搜索插件、轻量主题、只支持 Thunderbird 和 Seamonkey 的扩展则不属于传统附加组件。所以哪怕传统附加组件之前兼容了 e10s，但没有使用 WebExtensions 来编写，也一样无法在 Firefox 57 上安装和使用。 Firefox 57 的 Nightly 测试版本推出时候不仅默认全部开启 e10s，而且无法禁用。但目前还不清楚 Firefox 57 正式版是否也会如此，具体还是要看相关 bug 是否基本解决，或到时候会有多少用户默认开启了 e10s。 关于 Firefox 其他的一些进程： Firefox 53 Nightly 版本正在测试使用独立的进程打开本地文件，凡是使用 file:// 协议打开本地文件都会启动新的一个 firefox.exe 进程。其主要原因是考虑到安全，阻止第三者使用盗用的 Firefox 进程来访问用户的本地文件。具体来说就是这个用于打开本地文件的进程只有只读（read only）权限，不具有修改权限。 目前也还不知道会是哪个正式版会默认开启这项特性。 此外，Mozilla 也正在研究将 WebExtensions 附加组件独立成新的进程，这可以进一步增强浏览器的稳定性和安全性。但更多的网页 content 子进程和附加组件 content 子进程势必会带来更多的资源占用，尤其是内存占用方面。但我们有理由相信 Mozilla 会做好这块工作，在启用更多子进程的同时尽可能优化资源占用，因为本身 Mozilla 在 2017 年的开发都围绕着 Go faster 计划，而且 Firefox 也是目前所有浏览器中最节省资源的。
相关阅读：2017 年 Firefox 附加组件路线图 2017 年 Firefox 会主要开发的一些功能 https://www.soeren-hentzschel.at/firefox/so-geht-es-weiter-mit-dem-multiprozess-firefox-2/ |
|
|
|
1楼#
发布于：2017-02-23 06:20
https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/
这篇Blog的评论栏里，Jorge Villalobos这样说： “I fully admit the timing was bad. The opportunity and resources to launch WebExtensions came up when we were already into the initial e10s migration process, and the plans for Firefox also shifted in a way that WebExtensions can be the only path forward. We can’t support legacy add-ons for 2 years more because the APIs they rely on won’t exist then. Supporting them for longer only means extending the frustration of constant breakage, both for developers and users.” 这种神逻辑简直是太离谱了。 |
|
|
2楼#
发布于：2017-02-23 11:09
|
|
|
|
3楼#
发布于：2017-02-23 11:35
|
|
|
4楼#
发布于：2017-02-23 21:59
jiagm：https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/这也没错 是从谋智公司自己的利益出发 但如果谋智真的有考虑到扩展开发者的话 就应该在决定往 servo、webext 演进的时候 停止要求传统扩展支持 e10s 转而直接要求它们移植到 webext 现在这么做 可以提早大范围启用 e10s 只是让原来的扩展开发者太寒心而已 反正谋智根本不在乎啊 就等着 webext 能吸引到 chrome 的开发者呢 |
|
|
|
5楼#
发布于：2017-02-24 01:30
|
|
