跨平台桌面开发,Electron还是WebView2 (上篇)

2022-03-09 14:07:46 浏览数 (1)

我在2020年曾经基于Electron开发过一个跨平台桌面应用,在一定的条件下,Electron是非常好的选择。

去年微软做了一个变更,将它们的一个桌面应用从Electron迁移至自己的WebView2,是不是Webview2是更好的选择?

本次,我与大家聊一聊,跨平台桌面开发,究竟是应该选Electron还是WebView2?

这是上篇。

这个系列主要是讨论Electron以及Webview2,跨平台桌面开发当然还有QT,React Native Desktop,Jetpack compose Desktop以及Tauri等选择,这些技术都有可圈可点之处。但本系列还是专注于Electron以及WebView2这两个跨平台实现的一些对比。

趋势,Electron应用在增加

我认为相当一部分人,包括一些程序员,都没有意识到一个事情,就是那些基于Electron的应用其实是越来越多的。编程领域这个趋势更明显,因为普遍编程的工具有跨平台的需求。毕竟程序员可不是都只用WIN一个系统。

我曾写过一篇文章《一个程序员的正版清单》,在这篇文章中我列举我作为一个全栈式程序员,也就是偶尔搞后台开发,偶尔会搞移动端开发,偶尔又会搞前端开发的这么一个程序员,使用的一些正版软件清单。

当时我其实也没有意识到,后面我才发现,原来有相当一部分应用是Electron开发的。

现在我再把这其中一些基于Electron开发的应用列举出来,让大家意识到,光是在编程行业,究竟有多少应用是基于Electron的。

1.Visual Studio Code

前端开发不会不知道这个吧,前端开发主流IDE,这个就是微软的产品。基于Electron的。

2.Motrix

基于aria2的一个跨平台下载工具,有了它,你可能并不需要迅雷这么个玩意了。是的,它也是基于Electron开发的。

3.draw.io

如果你要画UML图,流程图,还是其它什么,使用draw.io是最正确的选择。它有一个网页版,也有一个桌面版。

这个工具的桌面版就是基于Electron开发的

4.Mongo Compass

Mongo官方的GUI工具。是的,不要怀疑,它也是基于Eelectron

5.迅雷X

我没用过这玩意,但它是基于Electrotn开发的。

6.Slack

国际知名的软件了,就是基于Electron开发的

7.Facebook Messenger

没错,还是Electron开发的

8.石墨文档客户端

其实不太想说这个,一二年前试用过,也是基于Electron的,但基本属于套壳而已。只能说不是非常好的实现。

看到没,这里就列举一些我知道或用过的。可能还有一些我没用过或我没意识到它是基于Electron的应用。

为什么

因为我也基于Electron开发过应用,所以,对于之所以越来越多的应用会选择基于Electron来开发的原因主要在于以下几个原因

•一次开发,支持几乎所有平台•使用前端开发技术栈,团队培养成本低•Chrome内核的性能较好

一次开发,支持几乎所有平台

类似的应用都有一个最大的需求点,就是要支持不同的操作系统。所以这也是为什么有相当一部分编程工具喜欢用Electron的原因所在。

基于Electron的应用它就支持各种系统,什么Windows,MacOS,Linux这三大主流的就不说了。我还适配过国产CPU下的银河麒麟操作系统,也是支持的。

其实本质上,只要是支持Chrome,支持NodeJS语言的系统,都是支持的。

网上我还见过有适配树莓派的文章。

使用前端开发技术栈,团队培养成本低

这也应该是显而易见的吧,前端开发人员不难找吧?

当然,我听朋友说过好的前端人员不好招,我没带过前端团队,不太清楚这是不是事实。但相比其它跨平台开发技术,比如QT或Rust什么,再相比不同操作系统的原生开发工程师来说,还是前端人员好招吧。

因此,从团队成本上考量,显然这个成本更低。招几个好的前端,搞几个月,一个跨平台的桌面应用程序就出来了。还有什么能比这个成本更低?

2020年我做的基于Electron的一个应用。

这个应用,我当时是以一已之力,花费5个月不到开发出来的。

我想问下,还有什么方案能把成本低到这种程度?QT?还是原生开发,你上哪找这么多原生应用开发人员?找到了这种人的工资和前端是一个水平?

Chrome内核性能较好

当然,这是相对的。不要和原生什么去比。之所以Electron能流行起来的另一个重要原因我认为就是Chrome内核的性能这些年不断改进,性能处于一个非常好的状态了。

所以,Electron这种基于Chrome内核开发出来的应用性能某种程度也能接受了。

结合成本与收效考虑,使用Electron确实是一种极佳的选择了。

怎么做到的?

好吧,太长不看,我也无意在这篇文章详细的把Electron的技术整的明明白白,就简明的说下。

之所以Electron能做到上述的这些优点,本质的原因在于它就是:

Chrome内核 NodeJS结合而成的

基于Chrome内核的能力,你能使用各种前端技术来绘制UI。

而借助于NodeJS的能力,你可以和原生操作系统打交道,比如读取文件,读取数据库等,只要NodeJS能做到的,Electron都可以。

举例说明,我2020做的那个应用,就使用了SQLite数据库,所有聊天数据都是存在本地的,从本地读取。有需要才从网络加载。

这几乎已经和普通的原生开发的实现理念一模一样的,对吧。

能做到这样,也完全依赖于NodeJS的能力。

代码语言:javascript复制
    public async deleteMessagesBySession(sessionId: string): Promise<boolean> {
        const deletSQL: string = "delete from message_ where sessionId = $sessionId";
        return await this.getRepository().executeUpdate(deletSQL, {
            $sessionId: sessionId
        })
    }

摘录其中的一些代码来示例。当时是基于TypeScript来做的。

这就是Electron之所以受人欢迎的原因所在。

套壳 VS 尽可能接近原生

使用Electron开发的应用,通常会呈现两种模式。一种是纯套壳模式,另一种是尽可能接近原生的模式。

纯套壳应用

我见过一些这样的实现,这种呢,基本就是把网页静态页面 Electron套个壳做出来的,本质上还是网页应用。

这种我认为纯粹是没有必要的,还不如让用户用浏览器。

尽可能接近原生

网页处理数据和原生处理数据是不同的模式。

对于网页处理数据而言,一个基本的原则是:

所有数据每次都是从服务器全量加载

对吧,除非极个别的,比如登陆信息,或者一些cookies会从浏览器取,其它内容几乎每次访问网页都是全量从服务器取。

客户端应用数据处理的基本原则是:

必要数据尽可能存储到本地(文件或SQLITE数据库),有需要才增量拉取新的数据

所以,我认为选用Electron做开发的,因为大多属于前端技术人员,特别需要对这个原则有所了解。

不要把应用做成套壳应用,这样太LOWER了。

Electron是完全可以读写本地文件,还可以使用SQLITE数据库等的。

Electron的缺点

当然,Electron肯定是有缺点的。我认为最大的几个缺点就是:

1.性能

浏览器就是浏览器,再怎么整也是浏览器,性能上肯定无法和原生相比,没得说。

2.对内存占用相对较高

Chrome是吃内存大户,这个应该是众所周知的吧。那基于Chrome内核整出来的玩意,对内存占用小也小不到哪吧。

所以,相当一部分人对类似的应用不是非常喜欢,有一种好像在电脑上打开一堆Chrome的感觉。

3.体积

由于Electron是采取把Chrome内核打包进应用的模式,理所当然的这玩意体积很大。以最新的版本为例,你如果啥都不干,就呈现一个简单的页面,上百M是少不了的。

终结者,WebView2?

而微软在Twitter上发了一条消息,它们把自己的一个产品迁移使用WebView2,替换掉了Electron,这是怎么一回事?

事实上,WebView2,光是从这名字上看,就知道还是没有脱离浏览器。WebView2是基于微软自己的edge内核,但edge内核只是chrome内核的fork版本而已。

那WebView2究竟有什么优势,它做了什么改变,它会把Electron打败下去么?未来这些基于Electron开发的应用又会纷纷改变自己路线么?究竟桌面跨平台应用还有更具有性价比的选择么?

下篇我们再聊。

0 人点赞