企业在业务安全与数据合规过程中有哪些实践与挑战?戳此了解 了解详情
写点什么

仅仅过去 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:1815168

评论 2 条评论

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

🏆【Alibaba中间件技术系列】「RocketMQ技术专题」RocketMQ消息发送的全部流程和落盘原理分析

浩宇天尚

RocketMQ 消息队列 Apache RocketMQ 12月日更

安全漏洞之任意文件上传漏洞分析

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

语音信号处理 4:汉语中语音的分类及韵律特性

轻口味

28天写作 12月日更

[架构实战营] 模块七作业

张祥

架构实战营

飞桨EasyDL桌面版正式发布 本地数据、本地网络、本地算力也能高效建模

科技热闻

致敬全新的未来!创业邦100未来独角兽峰会暨2021创业邦年会成功举办

创业邦

「Oracle」数据库字符集编码修改

恒生LIGHT云社区

数据库 oracle

恒源云(GPUSHARE)_[文本分类] 文本数据增强1(论文笔记)

恒源云

深度学习 语音识别

微服务架构 | 如何利用日志链路追踪程序执行的慢SQL?

码农架构

性能分析 微服务治理 慢SQL 链路分析

一站式云安全保障,就用行云管家!完美保障!

行云管家

云计算 云安全 企业上云 云资源 云管理

如何跟踪log4j漏洞原理及发现绕WAF的tips

H

网络安全 漏洞

2021低代码平台推荐,每一个都具有10年行业开发经验!

J2PaaS低代码平台

低代码 低代码开发 低代码开发平台 地代码平台

如何在 GitHub 上高效阅读源码?

AlwaysBeta

GitHub 源码 源码分析 源码阅读 源码解析

重点人员管控系统开发搭建,指挥调度平台建设方案

电微13828808271

模块7作业

Asha

CRM系统如何帮助企业改变销售周期

低代码小观

程序员 销售管理 销售 CRM CRM系统

干货分享!边云融合的时序时空数据库实践详解

百度开发者中心

物联网 时序数据库

把酒言欢话聊天,基于Vue3.0+Tornado6.1+Redis发布订阅(pubsub)模式打造异步非阻塞(aioredis)实时(websocket)通信聊天系统

刘悦的技术博客

tornado 实时通信 Vue 3 web socket redis'

区块链数字收藏品平台开发,数字藏品交易平台搭建

电微13828808271

Log4j2 Zero Day 漏洞 Apache Flink 应对指南

Apache Flink

大数据 flink log4j2

CameraX ImageAnalysis

Changing Lin

12月日更

“有创业者的地方,创业邦一直都在” 创业邦100未来独角兽峰会暨2021创业邦年会圆满落幕

创业邦

智慧社区小程序搭建,智慧平安社区解决方案

电微13828808271

全球IT服务将增1.3万亿美元,联想持续布局智慧服务能力

科技大数据

波卡生态的去中心化存储Crust Network | Hoo虎符研究院

区块链前沿News

波卡生态挖矿 Hoo虎符 虎符交易所 虎符研究院 去中心化存储

由IDC余热回收创新技术实践引出的跨界合作探讨

OPPO数智技术

算力 碳中和 节能 跨界合作

情报信息分析研判系统搭建,情指勤一体化平台建设开发

电微13828808271

如何开始移动网站测试

FunTester

测试 web测试 FunTester 移动端测试 响应式网页

优酷 Android 构建速度优化实践

阿里巴巴移动技术

android App Gradle 移动开发 客户端

WAVE SUMMIT 2022 深度学习开发者峰会

WAVE SUMMIT 2022 深度学习开发者峰会

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