高品质的音视频能力是怎样的? | Qcon 全球软件开发大会·上海站邀请函 了解详情
写点什么

仅仅过去 4 年,微软最终放弃了 Electron

  • 2021-10-30
  • 本文字数:2982 字

    阅读完需:约 10 分钟

仅仅过去4年,微软最终放弃了Electron

微软近期宣布,旗下 Teams 应用活跃用户已经达到惊人的 2.5 亿。这让 Teams 成了继 Word 和 Excel 之后,微软 Office 生产力套件中的又一位当红明星。然而,Teams 一直受到性能问题的困扰,疯狂吞噬系统资源,用户们对此吐槽不断。

 

前不久,微软 Teams 高级副总裁宣布,Teams 将放弃 Electron,转而匹配微软自己的 Edge WebView2 渲染引擎以寻求性能提升。官方声称,调整之后 Teams 的内存消耗量将直接减半,并有望以 Teams 2.0 的形象随 2022 年末上市的 Windows 11 一同亮相。

 

据悉,在 Windows 11 中,用户可以通过文字、聊天、语音或视频与联系人即时连接,无论他们使用的是 Windows、Android 还是 iOS。对方即使没有下载 Teams 应用程序,双方也可以通过双向短信联系。Windows 11 还支持立即静音和取消静音,或者直接从任务栏开始呈现 Teams。



追求更低的内存占用

 

对于已经尝试了许多不同技术来减少桌面客户端所需内存的微软来说,这似乎是迈出的很大一步了。有很多网友表示很开心看到这一变化。

 

“Angular 也不见了。我们现在 100% 使用 reactjs。”Teams 工程师 Rish Tandon 在推特上表示。“这些变化听起来很棒!”有人留言道,但对于网友提出的“Win10 和 MacOs 也会有吗?”Tandon 没有回答。

 


根据 Tandon 的说法,这项工作大概花费了 Teams 团队 6 个月的时间,优化后的 Teams 2.0 消耗的内存将只有 Teams 1.0 上相同帐户的一半。

 

时至今日,仍有众多知名应用都选用 Electron 来提供支持。Electron 框架能够帮助 Web 开发者将自己的 Web 应用发布至桌面平台,且不受任何特定平台的复杂性影响。但由于一切 Electron 应用程序后端都要运行只属于自己的 Chrome OS 实例,所以同时运行两个以上此类应用就会疯狂消耗主机资源。

 

于是,在 Electron 之上执行大量处理操作的 Teams 也无法避免地疯狂占用内存、拖慢计算机速度。微软甚至专门发布了文档页面,解释为什么 Teams 的内存占用量如此之高。

 

与 Electron 不同,WebView2 会监控 Chromium 的行为、检测还有多少系统内存可用,从而更有效地利用内存资源优化渲染体验。如果其他应用程序或服务需要系统内存,Chromium 就会将空间移交给这些进程。如此一来,内存容量较小的低端计算机也能带来不错的性能表现。

 

WebView2 更像是一种类似于应用窗口的控件,专门用于渲染 Web 页面。事实上,WebView2 控件还允许在原生应用程序中嵌入 Web 技术(包括 HTML、CSS 与 JavaScript)。所以要想将 Teams 规模的应用程序过渡至 WebView2,开发团队需要对大量由 Electron 提供的抽象进行重写。因此,Teams 在本质上将变得更接近于原生 Windows 应用程序。

 

目前,WebView2 已经被 Outlook 作为微软“One Outlook”项目的组成部分。

 

为什么选 Webview2 ?

 

Teams 需要处理大量音频与视频内容,所以微软认为最好能把一部分工作负载转移给 WebView2 更擅长的原生形式。事实也证明,Electron 抽象并不能有效完成这些处理任务。但从严格意义上来说,Webview2 并不属于 Electron 的替代方案。

 

Webview2 并不是 Electron 那样可以在桌面平台上快速发布 Web 应用的打包器。Electron 与 WebView2 都是以 Chromium 为基础构建而成,但更严格地说,WebView2 继承的是 Edge 源代码,而 Edge 又用到了 Chromium 源代码的一个分支。Electron 则不与 Chrome 共享任何 DLL。WebView2 二进制文件硬链接至 Edge(截至 Edge 90 的 Stable 版本),所以二者使用着相同的磁盘及其他一些工作集机制。

 

Electron 应用会始终捆绑并分发其开发过程中所使用的特定 Electron 版本。相比之下,WebView2 在发布方面则提供两个选项:可以直接捆绑应用开发时所使用的特定 WebView2 库,也可以使用系统上已经存在的共享运行时版本。WebView2 为这两种方法分别提供工具,包括一个防止共享运行时丢失的引导安装程序。而且从 Windows 11 版本开始,操作系统已经内置有 WebView2 运行时。

 

捆绑二者框架的应用程序负责保持框架更新,包括更新各次要安全增强版本。而对于使用共享 WebView2 运行时的应用程序,版本维护则依靠 WebView2 自己的更新程序,会以类似 Chrome 或 Edge 的方式独立于应用程序之外运行。WebView2 更新应用程序的代码或任何其他依赖项仍由开发者负责管理,这一点与 Electron 相同。值得注意的是,Windows 更新管理功能并未覆盖到 Electron 与 WebView2。

 

Electron 与 WebView2 都继承了 Chromium 的多进程架构——即由单一主进程同一个或多个渲染器进程通信。这些进程同系统上正在运行的其他应用程序完全分离,每个 Electron 应用程序都拥有一个独立的进程树,其中包含一个根浏览器进程、部分实用程序进程外加一定数量的渲染进程。与应用套件类似,使用相同用户数据文件夹的各 WebView2 应用程序之间会共享非渲染器进程,但使用不同数据文件夹的 WebView2 应用程序之间则不共享任何进程。

 

ElectronJS 流程模型:

 


基于 WebView2 的应用程序流程模型:

 


Electron 能够为各类常见桌面应用需求提供 API,例如菜单、文件系统访问、通知等等。WebView2 则能以组件的形式集成到 WinForms、WPF、WinUI 或者 Win32 等应用程序框架当中。另外,WebView2 仅通过 JavaScript 提供符合 Web 标准的操作系统 API。

 

Electron 当中集成有 Node.js,因此 Electron 应用程序可以使用来自渲染器及主进程的任何 Node.js API、模块或者 node-native-addon。WebView2 应用程序则不会对应用程序各个部分所使用的编程语言或框架做任何预设,JavaScript 代码必须通过 application-host 进程代理才能访问操作系统。

 

Electron 提供可配置的 Web 内容安全模型,配置范围涵盖完全开放访问到完全沙箱模式。WebView2 内容则始终保持沙箱化。Electron 还提供关于如何选择安全模式的详尽说明文档,而 WebView2 则提供丰富的安全最佳实践。

 

Electron 源代码在 GitHub 上进行维护与交付,各应用程序能够修改并构建属于自己的 Electron 品牌。WebView2 源代码则并未登陆 GitHub。

 

具体差异总结如下:

 

Electron

WebView2

构建基础

Chromium

Edge

源代码是否登陆GitHub

是否共享Edge/Chrome DLL

是(截至Edge 90)

不同应用程序间是否共享运行时

可选

应用程序API

Node.js

沙箱

可选

始终

需要应用程序框架

所支持平台

Mac, Win, Linux

Win (Mac/Linux正在筹备)

不同应用间是否共享进程

从不

可选

框架更新由谁管理

应用程序

WebView2

​性能差异有多大?

 

需要强调一点区别,这也是 Electron 应用程序中的一项重要性能考量因素。

 

在 Chromium 当中,浏览器进程负责充当沙箱渲染器与系统其余部分之间的 IPC 代理。虽然 Electron 支持非沙箱渲染进程,但也有不少应用会选择启用沙箱以提升安全水平。WebView2 则始终启用沙箱,所以对于大多数 Electron 及 WebView2 应用程序而言,IPC 确实会影响到整体性能。

 

虽然 Electron 与 WebView2 的流程模型基本相似,但底层 IPC 却有所不同。JavaScript 与 C++或 C#之间的通信需要经过编组,而且最常见的方法是编组为 JSON 字符串。请注意,JSON 序列化/解析操作的资源成本极高,因此 IPC 瓶颈必然会对性能产生负面影响。因此从 Edge 93 开始,WebView2 将对网络事件使用 CBOR。

 

Electron 则通过 MessagePorts API 支持任意两个进程之间的直接 IPC,其中使用到了结构化克隆算法。利用这项功能,应用程序就能避免在不同进程间发送对象时执行资源成本高昂的 JSON 序列化操作。

 

Electron 与 WebView2 虽然有着不少差异之处,但二者在渲染 Webn 内容方面却高度一致。最核心的影响还是来自应用程序架构与 JavaScript 库/框架在内存与性能层面的影响,毕竟同样师出 Chromium。

 

2017 年时,Electron 可以说是 Web 应用在桌面平台发布的最佳、甚至是唯一选项,但如今它却成了需要被优化淘汰的对象。这可能代表着跨平台框架格局中的一大关键里程碑,也可能仅仅是微软 Teams 做出的一项小小调整。但具体如何,还有待时间的检验。

 

相关链接:

 

https://www.electronjs.org/blog/webview2

 

https://blog.devgenius.io/microsoft-is-finally-ditching-electron-9e081757f9db

2021-10-30 10:1815919

评论 2 条评论

发布
用户头像
优化体验当然是放在第一位的,就像wps内核重构一样,换来的是新生
2021-11-01 23:22
回复
大佬,请问wps内核重构有专门的文章介绍吗?
2021-11-09 11:10
回复
没有更多了
发现更多内容

报名倒计时1天!平头哥、中科院软件所PLCT实验室等技术专家解读最新RISC-V技术

OpenAnolis小助手

报名 risc-v 云栖大会 Workshop 龙蜥峰会

软件测试丨接口测试该怎么做?持证上岗的Charles,可以帮你做什么?

测试人

软件测试 接口测试 charles 测试开发

JUC 浅析(四)

andy

KubeVela 插件指南:轻松扩展你的平台专属能力

阿里巴巴云原生

阿里云 开源 容器 云原生 KubeVela

要努力,但也别焦虑

源字节1号

程序人生

“程”风破浪的开发者|学习中的境界

林冲

学习方法 “程”风破浪的开发者

如何提升研发效能?我们先从指标谈起

Kyligence

数据分析 指标管理

从清华大学到苏州经贸,双一流和普通高校都在使用的数据科学教学实训平台

ModelWhale

大数据 人才培养 数据竞赛 实训 教学

手把手教你从安装CentOS7.4镜像开始,搭建IoT视频监控系统

华为云开发者联盟

后端 开发 华为云 企业号十月 PK 榜

软件要想做的好,测试必定少不了

华为云开发者联盟

测试 开发 华为云 企业号十月 PK 榜

阿里是如何使用分布式架构的?阿里内部学习手册分享

Java全栈架构师

架构 分布式 微服务 后端 高并发

36氪|元年科技发布新版数字化PaaS平台,更新多个组件

元年技术洞察

方舟 PaaS 中台战略 企业数字化

华为数通HCIA小型拓扑综合实验,运用OSPF动态路由协议、ACL访问控制列表,交换机生成树协议,修改交换机根桥、交换机划分vlan、链路聚合等相关数通技术、NAT地址转换以及NAT网络地址转换的配置

Python-派大星

10月月更

数字化时代,企业如何创新自己的客户服务

Baklib

ACL访问控制列表 基础、创建ACL访问控制列表的两种方式、配置ACL访问控制列表规则、修改ACL规则的默认步长。子网掩码、反掩码、通配符掩码的区别和作用。

Python-派大星

10月月更

教你处理数仓慢SQL常见定位问题

华为云开发者联盟

数据库 后端 华为云 企业号十月 PK 榜

区块链≠绿色?波卡或成Web3“生态环保”标杆

One Block Community

区块链 环保 波卡生态

专访韩向东|元年科技:专业与技术并重,赋能财务数字化转型

元年技术洞察

数字化转型 财务数字化

订单中心架构设计与实践

小小怪下士

Java 程序员 系统架构 架构设计

“程”风破浪的开发者|实战工作方法论(干货总结)

ike潮

学习方法 方法论 经验分享 总结思考 “程”风破浪的开发者

对话创始人:团队研发效能应该如何管理和度量?

LigaAI

团队管理 敏捷开发 研发管理 研发效能 企业号十月PK榜

NAT基础:NAT技术原理,静态NAT、动态NAT、NAPT、Easy IP、NAT Server的原理,以及各NAT的配置方法和转换示例。

Python-派大星

10月月更

JUC 浅析(三)

andy

阿里云云边一体容器架构创新论文被云计算顶会 ACM SoCC 录用

阿里巴巴云原生

阿里云 云原生 容器服务

FlyFish一周年,社区大咖邀你共话开源!

云智慧AIOps社区

低代码 可视化 数据可视化 大屏可视化 无代码

仅仅过去4年,微软最终放弃了Electron_前端_electron团队_InfoQ精选文章