[Chrome浏览器] 关于Edge浏览器基于Chromium重构的看法以及期望

源文链接： https://quan.ithome.com/0/358/886.htm

关于Edge浏览器基于Chromium重构的看法以及期望

这几天微软有几个引发大地震的动作，开源WPF，Edge浏览器改用Chromium重构，尤其是后者，趁此机会，我想写篇文章来讨论一下这件事。浏览器是互联网的入口，作为一个浏览器重度用户，这多年来，我尝试了好几种浏览器。先说说我的历程以及选择原因。


最初用的IE，这个没什么好说的，那个时候IE就是最佳的。后来有了Firefox，但试验过一段时间后，因为有太多问题，还是回归IE，直到Mozilla开发Firefox 3.0的时候说将会使用SQLite数据库管理书签（即收藏夹），我就非常期待，毕竟我是浏览器重度用户，收藏夹的数量很庞大。在3.0的某个alpha版终于引入了这个改进的时候，哪怕远远还没到正式版，我就迫不及待地开始以Firefox 3.0 alpha版作为我的主力浏览器，现在大家在各种浏览器都常见的地址栏的星星按钮就是Firefox 3.0首创的，直观地指示出用户当前的网页是否已被收藏，同时也可以方便地收藏、修改或移除收藏（包括重复的），基于关系型数据库的威力，即使用户拥有庞大的书签，都能快速的确定用户是否收藏了当前网页，更关键的是，基于数据库后，赋予了用户更好的书签管理特性，比如为书签添加标签（Tag），并且聚合相同Tag的书签的速度相当快，这个特性也是Firefox的书签管理至今为止独一无二的特性。


此后我一直是以Firefox作为主力浏览器，不过Firefox也并非完美的，过高的CPU占用（相比之下，当时的IE的CPU占用率真的很低很低）、内存泄漏问题一直困扰着我，但我还是坚持用着。直到我越来越疯狂，开网页越来越多的时候，单进程架构的浏览器已经满足不了我，网页开得越多，切换标签页越卡顿，而且单进程架构的内存释放也不彻底，开了大量网页之后，即使你后来关闭了很多，浏览器进程的内存占用实际并没有完美释放。


虽然IE是第一个搞多进程架构，但IE真的太渣了，终于，我转投了以前我并不喜欢的Chrome浏览器。以前因为Chrome无论开多少标签页，标签栏的标签都只会不断压缩，而不能滚动，以及书签管理和扩展不及Firefox强大，所以一直看不上眼。但好使的多进程架构浏览器就只有Chrome一个了，我也不得不用了。用着用着，中间因为某原因（后面我会提及）又改用了第三方的64位版Firefox——waterfox，然后又回归了Chrome，然后一直用到现在。


微软的新浏览器Edge我一直有关注，也试用过很多次，但真的太渣，那到底渣在哪里？Edge到底存在什么问题导致这么失败？让我来说说。

Edge的问题

把自己当新手

Edge最大的问题就跟Windows Phone一样，明明自己是个老手，做个新产品，却把自己当成新手似的去做，明明经验老到，却要重新调研需求，最终导致功能残缺，用户一看立马弃。真的，微软到今天还不知道WP是怎么死的，更不知道Edge是怎么失败的。

你做个新产品，好，你做旧产品的时候已经充分调研够了，用户需要什么功能你还不知道还不了解么？为什么做个新的浏览器，连很多最基本的浏览器功能都没有呢？为什么非要用户不断反馈，反馈支持数达到你认为足够多的时候才去做呢？

真不知道微软到底是得了什么神经病，突然就变得这么蠢了。Edge的功能少得连IE都不如。

前进后退按钮连弹出菜单之间前进或后退到指定历史页都不支持（后期的版本才有的）；

不支持一键收藏当前所有标签页（也是最近1、2个版本才加入的）；

不支持一键打开收藏夹里某个文件夹里的所有网页（也是最近几个版本才加入的，而且不好用，bug还多）；

右键菜单功能大量缺失：不支持复制图片地址、不支持“显示图片”（这个本来是IE独有的，网页单独一张图片没成功加载的情况下，可以通过这个显示图片功能单独重新下载，而不用刷新整个网页）、选定一段网址的文本不能直接跳转到该网址等等；

不能保存网页；

收藏夹管理功能太弱；

下载管理器不支持复制下载地址；

做个功能极度简陋的新产品，抛弃以前的经验，重新调研，逐点逐点根据积极用户的反馈去补齐功能，进度比乌龟还慢，很好，你成功地吓跑了大量对这个浏览器有兴趣的用户了！

用户愿意花时间去反馈还稍微好点，像我这种直接就懒得鸟你了，到最后你因为少了什么功能而死的都不知道。

在竞争激烈的环境下慢慢玩重新调研，装作自己不懂用户的需求，微软，是谁给你的勇气这么玩的？

最差的多进程架构

IE8是第一个提出多进程架构的浏览器（有证有据，不用跟我争论了），然而却是架构最渣的那个。种种表象显示，Edge直接沿用IE的多进程架构。

我来说说IE的多进程架构到底渣在哪里：

1. 过多的User对象和GDI对象消耗

Windows系统有三大对象：Kernel对象、User对象、GDI对象。由于历史原因，这三大对象都存在数量限制，Kernel对象可以忽略不用管，GDI对象一般的Win32图形界面软件都必须要用到，用来绘制界面和文字的，User对象我还不是太明白它的作用，貌似主要用于处理鼠标键盘的交互。User对象和GDI对象的系统总数量限制都是65535个。

然后，这些对象消耗过多达到系统限制的时候，会发生什么呢？拿GDI对象来说，如果整个系统消耗的GDI对象达到限制的话，你会无法正确打开新的程序，已经打开了的程序（包括还在使用GDI绘制的系统界面）也会出现绘图错误的问题，甚至就这样搞死了你的系统。

IE从IE9开始就实现了完全的硬件加速架构，为了实现硬件加速渲染，IE9以上的IE抛弃了GDI来绘制网页，而改用从Win7开始引入的新绘图API——Direct2D和DirectWrite。这些新绘图API是全新设计的，相比GDI，对象限制什么的可以忽略不计，不过，IE由于右键菜单还是GDI绘制等原因，页面进程还是会消耗一点GDI对象的，大约30多个，而Edge由于基于UWP构建，占用更少，大约一个页面进程消耗7个。但User对象的消耗量还是比较多。

相比之下，同样是多进程架构的Chrome又如何呢？Chrome的User对象控制得比较好，老架构的Chrome的User对象主要集中在主进程，页面进程只消耗1个，但总消耗量相比IE或Edge的总消耗量要少很多。而GDI对象，在Chrome使用DirectWrite渲染网页文字之前，Chrome在Windows下是使用GDI来绘制的，所以老版Chrome的页面进程GDI对象消耗非常庞大，如下图所示：

网页开得足够多的时候，Chrome就会爆掉系统的GDI对象限制，然后系统就死了。所以有段时期我改用了第三方64位版的Firefox——waterfox作为主力浏览器，当时的Firefox还没有64位版，网页开多了会突破32位的单进程内存限制，所以用了这个第三方的，而同时由于Firefox是单进程架构，以及Firefox也很早就跟进IE使用了Direct2D和DirectWrite来实现网页的硬件加速渲染，所以GDI对象占用并不多。

后来从Chrome 42开始，Chrome终于用了DirectWrite来绘制文字，页面GDI对象一下子缩减到只有4个，我才回归了Chrome，然后Google继续改进架构，发展到今天，Chrome的页面进程已经实现User对象和GDI对象的零占用，只在主进程和GPU进程需要消耗，而且数量很少。如下图所示：

我对User对象和GDI对象的占用有苛刻的要求，Chrome做得让我很满意，最新的Firefox Quantum的表现也很好，优于Edge。

2. 一次性打开大量网页的性能太差

IE的多进程架构存在设计缺陷，从收藏夹一次性打开某个收藏文件夹里的所有网页，也就是一次性打开大量网页的话，无论你打开的是多少网页，IE都只会创建一个页面进程，然后在这个唯一的页面进程的内存占用到1G多点的时候，IE就会一直无响应甚至自动崩溃。如下图所示：

前面提到的对象消耗还可以说仅仅是我个人的极致追求，而这个问题就是IE多进程架构真正渣的原因所在。

一次打开大量网页只开一个页面进程，还可以解释成设计策略，虽然这个策略很糟糕，但仅仅1个多G的内存占用，还不足以达到32位单进程的内存限制，你就崩了，那这就不是策略问题这么简单了。当时同样单进程的Firefox不见得会崩？

忍无可忍之下，我录制了几个视频（特意用无加载项的模式演示），专门上Microsoft Connect的IE板块反馈了这个问题，而微软仅仅是随便的答复就了事。

不过似乎微软也不是完全忽略了我的反馈，前面我也提到，作为全新开发的Edge浏览器，最初居然连一键打开收藏夹里的文件夹的所有网页的功能都没有，原因可能是微软正努力地解决我反馈的那个问题（嗯，缓慢地努力），直到Edge终于有这个功能的时候，一次性打开大量网页终于产生了很多个页面进程出来了，然而，是缓慢地产生！逐个逐个网页地加载，而不是像IE或者Firefox和Chrome那样并发地加载，我不知道微软是不是在用这种方式避开什么问题，我的PC的机能完全可以并发打开，为什么要像单任务那样逐个来？无论什么原因，我只会认为你微软无能！

基于糟糕的UWP框架

基于微软的通用应用策略，Edge是一个UWP应用，而UWP应用的窗口管理是由系统的ApplicationFrameHost.exe进程实现的。然而这个ApplicationFrameHost可是问题多多，导致Edge的标签页拖出来以及合并回去经常出现各种问题，而且操作体验也不好，标签页之间的位置移动的体验也没有做好。

甚至有时候标题栏莫名其妙就会出bug。通常来说Windows的标准窗口分为标题栏部分和被称为客户区的部分，标题栏部分也叫做“非客户区”，一般来说，程序员在一个标准窗口上面画界面（放控件）是不能画到标题栏区域的，直到Vista开始伴随着DWM的引入才终于能够做到这一点，而在Vista以下的系统，开发者是通过一种取巧方法来做的，构建一个没有标题栏的窗口，然后自己画一个标题栏，假装有标题栏。而DWM这个新API特性，从一开始就很完美很稳定，所有用了这个API的应用都没出过问题，前面说了，UWP应用的窗口由ApplicationFrameHost管理，而UWP应用也一样支持将客户区域扩展到标题栏的非客户区域，从而可以在上面放控件，实现原理按说也应该是用的DWM API，然而同样的API，ApplicationFrameHost却做得问题多多，经常出现绘制问题，Edge偶尔就因为这个而出问题，不过可惜我手上没图，就以Photos应用出现标题栏bug的截图来给大家看看：

本应该被扩展了的标准标题栏，此时居然突然出现，变成了双标题栏，而且三个窗口控制按钮还出现了绘制问题。这个ApplicationFrameHost真是一堆bug。

而且这个ApplicationFrameHost还有一个大问题，一旦这个进程被结束，所有UWP应用都会马上崩溃！

一个战略性的新产品搭上了这么一个不成熟的框架，不失败，难道还会成功？

一堆Bug

Edge的bug之多，相信大家也知道了。就我所知道的，比如地址栏的地址有时候会复制不了，也粘贴不了。或者打开的网页明明就没有任何广告，而Adblock Plus扩展却显示屏蔽了几个广告，说明浏览器引擎或者扩展API存在问题。以及前面连续好几个大版本的地址栏星星按钮都无法准确反映出当前网页是否已被收藏等。至于大量网友提到的容易卡死的问题，虽然我真的从来没遇到过，但既然这么多人说有，就证明是有这个问题。做来做去仍然一堆Bug，让人怎么用？

基于Chromium重构的期望

整合Edge原有的渲染优势

Edge那种非常爽的平滑滚动和响应灵敏的网页缩放，相信所有人都服，不过也导致文字在滚动的时候会一闪一闪的，可能是显示器响应速度不够导致，但滚起来的手感确实很爽的。这应该得益于微软的完全硬件加速的架构，特别是滚动这一块，应该是深度利用了DWM的，希望新的Edge能整合这个架构。

保持使用Chromium的多进程架构

正如我前面说的，Chrome的多进程架构是最优的，应该直接保持使用，希望不要再用渣渣的IE多进程架构了。

收藏夹改用SQLite数据库并加强收藏夹管理功能

当前Edge的收藏夹采用微软自家的ESENT数据库来储存，我真不知道这货相比SQLite有什么优势而不去用SQLite？明明自家的Sticky Notes都很乐意地使用了SQLite。而Chrome的书签是用文本文件以JSON的文本数据形式储存的，也不好。

虽然Chrome本身的书签管理比Edge强，但还是显得很弱，好好参考Firefox的设计，做好收藏夹管理器吧，特别是引入Tag支持。

Suspend（挂起）机制

如果你跟我一样是一个浏览器重度用户，自然就会在CPU资源占用这个问题上有深刻体会。现代的网页很复杂（大量应用JS、动画等等），在完全加载完毕之后仍然会消耗不少CPU资源的，有很多时候你不能马上关闭网页，你等下还需要看，或者等有空的时候再从一堆网页中采集有用的资料，这时候你往往很无谓地浪费了很多CPU资源和电费（如果你真是重度用户，你自然体会到，哪怕是Core i7都不够一个浏览器吃）。

此时Suspend（挂起）机制就很重要了，UWP应用都自动实施了这个机制（最小化窗口后自动挂起），这个机制本来是我对Edge浏览器最感兴趣的地方。早期的Edge，最小化所有窗口后，就会自动挂起所有Edge页面进程和主程序进程，实现零CPU消耗。后来一堆人反馈说Edge最小化后不能在线听歌（那是当然的，最小化后进程都挂起了），微软为了迎合这些用户，做了很糟糕的决定，取消了Suspend机制，直到最近不知道是哪个版本开始，才以另一种形式让这个机制回归，现在的Edge是基于某个逻辑自行将部分后台页面进程Suspend的：

但这个逻辑并不好，实际效果远远达不到期望值，希望基于Chromium重构的同时，保留并改进Suspend机制，最理想的就是自动Suspend所有没有后台活动（比如播放音乐）的页面进程。

而且UWP的Suspend机制也有另一个优点，Edge会根据内存剩余量来自动结束掉部分后台页面进程，直到用户再次切换到该标签页后再重新加载，这是很重要的，用户不再需要因为拖延症而担心内存不够用。

AppContainer沙箱

AppContainer沙箱，是从Windows 8开始引入的，专为Metro应用而设计。当前的Edge也使用了AppContainer沙箱。虽然本身Chrome就有沙箱，但再结合AppContainer沙箱，应该会更好。事实上，Google曾经在Chrome 44.0.2403.89这个版本试验性地在页面进程使用AppContainer沙箱，但很快又在下一个版本取消掉了，不知道当中究竟是有什么原因，直到现在Google都不再尝试搞了。希望微软能帮一把手。

跟IE一样的标签页拖放/合并的体验

标签页的拖放和合并，体验做得最好的就是IE，拖动的时候窗口内容还是可以动的，操作感也好。预计新版Edge将会抛弃UWP框架，那么做起来就不难了，希望能还原IE的体验：

硬件加速渲染的UI

我认为一个现代的浏览器，其界面也应该是硬件加速渲染的。既然微软要拓展Edge到多个平台，那么最近开源了的WPF应该是不错的选择。我个人期望是这样。另外，希望Win10专版通过XAML Host来使用WinRT的XAML，实现Fluent Design。

以上就是我对将会新生的Edge浏览器的期望，希望能让微软中国看到，再传达到微软美国总部吧。这是我对这个浏览器的最后一丝留恋了，再做不好，我就回归Firefox了（Chrome现在不让拖放安装扩展了，而且Firefox Quantum也焕然一新了，开大量网页后切换标签页终于不卡了）。