Webview2 vs 对比 Electron

前不久微软Teams团队宣布他们将放弃使用Electron转而使用基于Edge的Webview2组件来重新实现Teams程序，目的是在于减少软件所占用的内存。对于开发者来说，微软内部团队的这个决策给外界的感觉是Electron的寿命即将到头了，他们后续将重点发展和使用Webview2来进行开发。那究竟是不是这样呢？其实在7月份的时候Electron的官方博客已经对此进行了说明，并在文章中把Electron和Webview2进行了对比。接下来我们来一下原文，看看Electron团队对这个事情的看法。

---

以下是原文翻译：

背景

在过去的几周我们收到了非常多关于 WebView2 和 Electron之间有什么差异的问题。

两个团队都致力于把使用Web技术开发桌面应用的开发体验和性能达到极致，现在大家都在公开且全面的讨论这两个技术究竟有什么不同。

Electron和Webview2都是持续且快速迭代的项目。我们基于它们现有的功能，收集了它们之间的相似之处和差异，在下面的内容中进行展示。

架构概览

Electron和Webview2都是基于Chromium开源项目的源码来实现Web内容渲染的。严格来说，Webview2基于Edge项目的源码，但是Edge也是基于Chromium源码fork出来的一个分支。Electron并不与Chrome共用任何DLL文件。Webview2的二进制文件跟Edge有比较强的依赖，因此它们会共享磁盘和一些工作集。可以在下面的链接中查看更多相关信息：Evergreen distribution mode

Electron应用会打包和分发我们在开发中使用的版本，如Electron v15.x。应用的版本不会受到运行环境的影响，而Webview2在发布的时候提供了两个选择。你可以使用你在开发时使用的Webview2版本，或者你可以使用运行环境中已经存在的Webview2版本。Webview2提供了工具来支持这两种选择，包括在安装时会检测当前环境是否有Webview2，在没有的情况下会自动进行安装。在新的Windows 11操作系统中将会默认带上Webview2组件。

应用程序本身需要负责更新它所使用到的框架，其中包括一些小的安全性更新。使用Webview2的应用会共享环境中的Webview2上下文，Webview2与Chrome和Edge有类似的升级机制，会独立运行并升级，与应用本身无关。而使用Electron开发的应用需要自己把控依赖的升级。

Electron和WebView2的架构都继承至Chromium的多进程架构（一个主进程与多个渲染进程，它门之间通过IPC进行通信）。这些进程与其它应用的进程是分开运行的。每一个Electron应用都是单独的进程树，它包含一个位于根的浏览器进程，一些公共进程和多个渲染进程。WebView2应用使用相同的用户目录来共享处渲染进程以外的进程。但是，使用不同目录的WebView2应用不会共享进程。

Electron的进程模型：

Webview2应用的进程模型：

Electron提供了一些API来让开发者实现入菜单、访问文件系统、系统通知以及其它本地相关的功能。Webview2仅仅只是一个被集成到WinForms、WPF等应用框架中的组件，就像是在Android App中嵌入webview组件来渲染网页一样。Webview2不提供操作系统的本地API，仅提供标准的Javascript API。

Electron中集成了Node.js。Electron应用可以在主进程或者渲染进程中使用Node.js提供的API、模块以及node-native-addon。使用Webview2开发的应用并不关心应用的剩余部分是用什么语言或框架开发的，如果想要访问本地能力，需要通过Javascript和本地代码进行对接来实现。

Electron可以配置从完全的访问权限到完全的沙箱的安全级别，这意味着开发者可以实现一些原来在浏览器沙箱中无法实现的功能，而Webview2的上下文只能运行在沙箱环境中。

下面我们通过一个表格来看下它们两个的差异总结：

关于性能的讨论

无论是在Electron、Webview2还是其它基于Chromium实现的渲染器中渲染页面，我们认为它们之间的性能差异是非常小的。我们为那些对这方面性能差异感兴趣的开发者制作了不同技术组合的Demo，便于它们研究性能差异点，项目链接为https://github.com/crossplatform-dev/xplat-challenges。从Demo运行的结果来看，渲染页面的性能差异确实是非常小的。

IPC通信

目前只有一个差一点我们需要重点提一下，这点也是一个Electron应用经常需要考虑的性能点。

在Chromium中，浏览器进程充当渲染器和系统其它部分之间的IPC通信代理的角色。虽然Electron支持不开启沙箱模式，但很多应用基于安全的考虑还是会使用沙箱机制。Webview2无论在任何情况下都会开启沙箱机制，因此，对于大多数Electron和WebView2应用程序来说，IPC可能会影响整体性能。

尽管Electron和WebView2具有类似的进程模型，但底层IPC的实现有所不同。在JavaScript和C++或C#之间通信需要进行编码，最常见的是JSON字符串。JSON的序列化和解析是一个非常昂贵的操作，IPC产生的瓶颈会降低应用的性能。从Edge93版本开始，Webview2开始该用CBOR技术来在进程间传输数据。而在Electron中，开发者也可以使用MessagePorts技术来避免JSON的序列化和解析操作，MessagePorts底层采用的是结构化克隆技术。

总结

Electron和WebView2虽然有很多不同之处，但它们在渲染Web内容的方式方面没有太大差异。总的来说，应用程序的架构和JavaScript库/框架对内存和性能的影响比其它任何东西都要大，这些才是影响性能最主要的因素，因为无论在它们在哪里运行，都还是在Chromium中运行。