整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

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

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

每一个特定或者特殊的日子里,几乎所有的网站都变成了灰色,那么这种效果是怎么实现的呢?

今天就来简单的实现一下这样的效果。



添加以下全局CSS样式,可以实现此效果:

代码一:

html {
  -webkit-filter: grayscale(100%);filter:progid:DXImageTransform.Microsoft.BasicImage(graysale=1);
} 
<!-- 可以是整个网站变成灰色的  -->


实现网页颜色变灰这个效果,非常简单:

filter: grayscale(100%);

这样一段代码即可实现,放在html和body的css属性里即可实现。

意思是修改所有的颜色为黑白 (100% 灰度):

灰色网站会加入这段代码,你可以按F12,把这段源码删除,即可变成彩色


代码二:

html { 
   filter:progidXImageTransform.Microsoft.BasicImage(grayscale=1); 
}

使用方法:这段代码可以变网页为黑白,将代码加到CSS最顶端就可以实现素装。建议全国站长动起来。为在地震中遇难的同胞哀悼。

如果网站没有使用CSS,可以在网页/模板的HTML代码<head>和</head> 之间插入:

<style>
   html{
     filter:progidXImageTransform.Microsoft.BasicImage(grayscale=1);
  }
</style>

有一些站长的网站可能使用这个css 不能生效,是因为网站没有使用最新的网页标准协议:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

请将网页最头部的<html>替换为以上代码。

有一些网站FLASH动画的颜色不能被CSS滤镜控制,可以在FLASH代码的<object …>和</object>之间插入:

<param value="false" name="menu"/>
<param value="opaque" name="wmode"/>

最简单的把页面变成灰色的代码是在head 之间加

<style type="text/css"> 
html {
   FILTER: gray
}
</style>


代码三:

html{ 
filter: grayscale(100%); 
-webkit-filter: grayscale(100%); 
-moz-filter: grayscale(100%);
-ms-filter: grayscale(100%); 
-o-filter: grayscale(100%); 
filter: url("data:image/svg+xml;utf8,#grayscale"); 
filter:progid:DXImageTransform.Microsoft.BasicImage(grayscale=1); 
-webkit-filter: grayscale(1);
}


总结:

以上几种代码(方法),都是通过CSS的滤镜来控制页面的显示而已,唯一不同的就CSS代码及调用的方式。在css的修饰时还有权重问题,所以有时候css代码不生效的时候可以考虑一下代码的权重问题。

欢迎关注第一山,今后将有更多前端开发技术与大家共同交流学习。

作者 | Lew C 译者 | 弯月

出品 | CSDN(ID:CSDNnews)

以下为译文:

现如今的各个网站,包括你现在正在使用的这个网站,都是通过HTML、JavaScript和CSS编写的。如果要求在创建网站的时候,不要使用这三种技术中的任何一种,你可能就会问为什么。

然而,纵观整个Web开发的发展历史,我们就会发现该领域涌现了很多技术,比如曾经的Flash、Silverlight等,所有具备竞争力的技术都曾尝试在浏览器的市场中分一杯羹,希望开发人员使用不同的技术来创建网站。然而,它们最后的结局大多雷同:出师未捷身先死。而我又凭什么告诉你这片广阔天地中又多了一位竞争对手呢?尤其是该领域的众多技术在经过数年的努力之后,无一能够找到出路。

别着急,我们先来分析一下过去这些技术的共同点:

  1. 这些技术都需要浏览器插件才能运行。通常它们都需要平台特有的浏览器插件才能在目标平台上运行。Silverlight就是一个很好的例子,当时使用Linux的人无法观看Netflix,因为该网站采用了Silverlight(Linux不支持Silverlight)。当然,我们有开源的替代方案,但没有官方解决方案。

  2. 它们引入了安全漏洞。Flash就有此恶名(已知漏洞超过1000个)。浏览器必须加载插件才能显示内容,此时浏览器的安全保护措施不再有效,因为该插件拥有计算机上的所有权限。

  3. 性能比不上纯HTML。就加载插件和显示文本的速度而言,仅使用HTML和CSS的速度肯定超过了加载插件。

  4. HTML 5问世,CSS得到了提升。突然之间,无需大费周折也可以建立美丽又愉悦的体验感。有些浏览器讨厌标准,而且还使用了特别手法或使用了特定于供应商的实现,虽然它们更好用,但是最终还是被干掉了。

如此种种迹象表明,选择原生HTML创建新Web应用更加容易。毕竟,如果创建Web体验所采用的技术被弃用,而且收不到安全修复程序,那么你将别无选择,只能另选一种新的支持语言重新编写应用。但是,为什么如今会是这样一种局面呢?为何HTML成为了蓬勃发展的互联网的支柱呢?


新时代的曙光


1991年8月6日,互联网诞生。随后我们又经历了互联网泡沫。我们来想一想,1991年互联网问世,9年后互联网泡沫破灭,造成了1.7万亿美元的惊人损失。这意味着互联网泡沫造成的损失相当于当年美国GDP的15%。

我们经历了这段历史,因为当时互联网越来越流行,而我们编写网站的方式也越来越标准。随着时间的流逝,我们建立了HTML 4等标准,这些标准可以确保我们编写的HTML可以在绝大多数HTML解释器上运行。级联样式表(Cascading Style Sheets,CSS)也于1996年问世,而在此之前的一年,JavaScript也进入了市场。你见过没有JavaScript或CSS的网站吗?我敢肯定,你的体验一定不怎么愉快。

但是,纵观整个历史,网络的某些方面并没有发生变化。平心而论,很多时候互联网也是迫不得已:如果没有迫不得已的原因,你肯定不想对HTML标准进行重大修改,所以对互联网的工作原理进行大范围修改的事情可能永远都不会发生。于是互联网就成了今天的样子。

文档

当互联网刚问世的时候,人们并不能像如今一样使用应用。可能有人还记得通过瘦客户端,连接到另一端的大型机上。当时的“应用”仅仅是屏幕上的几行文字。人们习惯了将一切都当作文档处理,就像手头可以阅读的纸张一样。因此,HTML页面最初的目的就是生成HTML文档,这一点毫不令人奇怪。如果你曾用过JavaScript,那么肯定对document.getElementById()等函数并不陌生。你在网页上所做的一切操作都是为了生成文档,然后转换文档。

大多数网页都太高,无法容纳到一个窗口中。因此,用户不得不用手指滑动页面,或滚动鼠标。我想不出如今哪个网站可以正好显示在一页之内,因此开发人员必须要处理位于当前可见部分之上或之下的页面。

但是,你仍然希望网页的某些部分保持在特定的位置或以特定的方式对齐,那么就需要使用CSS中的position等来控制元素的布局。CSS有数不尽的属性(确切地说是520个),顾名思义,这些样式会层叠到其子元素中。如果你试图将文章的特定部分显示成特定的样子,那么就会变得非常混乱。如果使用现有的样式框架(比如Angular Material),那么情况也好不了多少,因为你需要覆盖框架自带的CSS,才能实现你想要的布局。当然你可以使用!override来覆盖CSS,但是如此做法不过是引鸩止渴罢了。读到此处,你可能会想,“这个家伙似乎对CSS毫不报希望啊。”没关系,我不会在这一点上与你争论。但是,如果你的设计师对网页外观有一定的要求,那么CSS就会变得非常复杂。

学习语言

为了创建一个简单的网站,你需要使用三种不同的语言,即HTML、JavaScript和CSS,而且这只是针对网站本身的。网页必须美观,但如果你不知道如何编写高效的JavaScript或CSS的样式不好的话,恐怕就很难了。

如果你希望网站执行任何操作,则可以使用Angular或React之类的框架。随着你通过npm引入软件包,应用的规模也会增大,所以你还需要使用打包工具(比如Webpack等),将所有软件包都打包到一起,并适当地缩小规模。Webpack本身就是一个主题(而且还是一个大主题),但它是一个值得考虑的主题,而且相当一部分Web应用都是用它构建的。

打包与转译

在建立网站,并拥有了自己的软件包后,你需要使用打包工具来打包客户端应用,还需要确保能够在浏览器中正常工作。根据使用的浏览器,你还需要添加一些功能,以便用户的浏览器可以使用你的网站。如果你使用的是TypeScript之类的语言,则Webpack还可以将其转译为JavaScript。虽然这没有什么不好,但是这个过程非常复杂,而且还有很多可变因素。如果你的网站崩溃了,那么究竟是哪里出了问题?是代码出了问题,还是在压缩代码的过程中出了问题?是Webpack没有正确打包代码,还是转译的过程出现了问题?这些复杂的流水线会加剧调试或查找根本原因的难度。


Flutter好在哪里?


即便你听说过Flutter,可能也是在移动应用开发的语境下。究竟如何将Flutter应用到Web开发呢?对于普通的HTML网页,你可以将页面作为文档来处理。但在Flutter中,“页面”(或用户与之交互的内容)实际上是绘制到HTML画布上的。Flutter控制着绘制到屏幕上的每一个像素,而且它不使用HTML、JavaScript或CSS来定义外观或逻辑。(从技术的角度来看,原生Dart代码通过dart2js转换成了JavaScript,但业务逻辑实际上并不是用JavaScript编写的。)

这句话让你吃惊的地方可能有两个:首先,没有HTML;其次,所有的内容都是绘制到画布上的。我能理解,这话听起来有点奇怪,至少直接绘制到画布上的性能可不好。下面,让我们进一步研究一下。

绘制到画布而不是文档

首先,我们不使用HTML编写网页,也不会将内容写入文档。初听之下,感觉很奇怪。但是,使用HTML开发网页时,你究竟做了哪些工作?我们在前面就讨论过了,你创建的文档对于用户设备的窗口来说太大了,你需要滚动。你正在阅读的这篇文章,页面的高度就超过了窗口大小,你需要不断向上滚动。

仔细想一想,我们设计的用户界面超过了窗口的纵向大小,用户必须滚动页面才能浏览全部内容,这不是很奇怪吗?如果你希望用户从左到右(不是从上到下)滚动窗口,该怎么办?恐怕在普通网页上可不容易实现。

在Flutter中,如果想让某一部分内容水平滚动,就只需要将小部件包装到SingleChildScrollView。你也可以指定滚动条的方向,无论滚动条是在垂直方向还是水平方向上滚动。

因为Flutter的基本概念是,在单独的小部件中绘制文档,而不是将文档绘制到屏幕上,所以开发人员完全可以控制如何布局应用程序。

只使用一种语言

如前所述,为了创建一个出色的网站,你必须掌握HTML、JavaScript和CSS。这也意味着,你所需的知识无法在这些语言之间融会贯通,例如,你不能在HTML中使用任何JavaScript的知识。HTML纯粹是标记语言,CSS纯粹是样式语法,而JavaScript纯粹是编程语言。这些语言都不包含类型检查等功能,所以虽然CSS看似很完整,但在用户使用页面的时候,就会悄无声息地出问题。

Flutter采用了Dart语言,并使用Dart编写了应用程序的所有外观和业务逻辑。Dart具有静态类型检查,而且即将推出安全性,因此应用程序中的每一行代码,无论是描述应用的外观,提供样式,还是控制业务逻辑,都是类型安全的。

轻松布局

一般来说,网站显示的数据来自其他源头:无论是数据库、API还是其他来源,我们都希望数据能够按照预期显示出来。想象一下,我们有一组从API返回的对象,而你使用了Angular的对象来显示它们。通常,你需要将这些对象加载到支持组件中,然后使用*ngFor迭代所有对象。你需要添加div。但是,这些没有样式的div看起来会过于苍白。如果你希望列表中的各项显示在列或行中,则必须使用CSS或flexbox来实现。

而在Flutter中,你可以使用Column或Row来布局这些数据,Column或Row的children属性可以接受对象数组。仔细想一想,在大多数情况下,你可能会希望对象列显示成一排或一列。在Flutter的帮助下,你可以快速完成视觉上的布局,然后再为列表中的各项设置样式。根据我的经验,你可以更快地完成脚手架和原型制作,同时不影响最终结果。

控制窗口中的每个像素

由于Flutter会将每个像素渲染到屏幕上,因此设计人员和开发人员可以完整地控制自己想要的应用或体验。渲染屏幕上的每个像素听起来会造成巨大的性能损失,但请不要误会我的意思,这种做法当然不如渲染HTML的速度快,但是在GPU的加速下,性能也得到了提升。根据传统的做法,设计HTML的网页意味着,你必须考虑不同的浏览器。然而,在Flutter中,给Text小部件设置的字体无论在何处显示,最后的效果都一样,因为Flutter可以控制每个像素的外观。

再见,Webpack!

由于Flutter使用了Dart,因此在针对目标平台编译Flutter应用时,它会把所有相关的软件包(也是用Dart编写的)都转换成JavaScript。Dart是一种类型安全的语言,不支持反射,因此编译器可以更好地了解应用需要调用什么以及不需要调用什么。这有助于我们进一步将应用的规模降到最小。在Web上构建Flutter应用不需要使用Webpack,因为它不需要Webpack,这是Flutter本身的一大优势(至少在我看来是优势)。并不是说Webpack有问题,Webpack是一款高质量的软件。只不过它是复杂的流水线中的一款复杂的工具。


但是我们的目标还没有实现


Flutter不仅可以提供新潮的网页,引人入胜的动画和精美的体验,而且还可以更进一步。我们需要服务器端渲染(server-side rendering,SSR),以便我们的网页可以被搜索引擎抓取,然后执行搜索引擎优化(SEO)。目前Flutter网站只面向人类用户,不能被搜索引擎解读,因此会对网站搜索和查找信息的方式产生巨大影响。(人们正在就此问题进行讨论,近期内还没有解决方案)。

此外,将所有内容绘制到画布上确实对性能有影响,但没有那么糟糕。我构建了一个测试应用,使用了大量视觉效果,在MacBook上能够以接近60fps的速度运行。在没有经过任何优化的情况下,即使拖动屏幕,也仍然可以正常工作,在性能不足时会逐步降低背后的图像的清晰度。

在被视为Web开发的主流技术之前,Flutter还需要改进几个关键领域。话虽如此,毕竟Flutter诞生才两年,其性能和功能集已经达到了令人惊叹的水平。

如果可以创建一个性能卓越的网站,而且只需一种语言就可以设计、样式化和编写完成Web应用的业务逻辑,你感觉怎样?如果开发流水线无需再使用Webpack呢?如果你能及时获得服务器端渲染,而且基于HTML的传统网站所拥有的SEO优势也统统没落下呢?你会动心吗?

如果所有这些都成为现实,那么Flutter就会赢得整个Web。

原文链接:https://betterprogramming.pub/flutter-is-about-to-win-over-the-web-be0a205af03d

声明:本文由CSDN翻译,转载请说明来源。