跨平台桌面开发，Electron还是WebView2 （上篇）
我在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的。
- Visual Studio Code
前端开发不会不知道这个吧，前端开发主流IDE，这个就是微软的产品。基于Electron的。
- Motrix
基于aria2的一个跨平台下载工具，有了它，你可能并不需要迅雷这么个玩意了。是的，它也是基于Electron开发的。
- draw.io
如果你要画UML图，流程图，还是其它什么，使用draw.io是最正确的选择。它有一个网页版，也有一个桌面版。
这个工具的桌面版就是基于Electron开发的
- Mongo Compass
Mongo官方的GUI工具。是的，不要怀疑，它也是基于Eelectron
- 迅雷X
我没用过这玩意，但它是基于Electrotn开发的。
- 阿里云盘桌面端
阿里前段时间出了个云盘，我还用了下，后面还出了个桌面版，也是基于Electron的
- Slack
国际知名的软件了，就是基于Electron开发的
- Facebook Messenger
没错，还是Electron开发的
- 石墨文档客户端
其实不太想说这个，一二年前试用过，也是基于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的能力。
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肯定是有缺点的。我认为最大的几个缺点就是：
- 性能
浏览器就是浏览器，再怎么整也是浏览器，性能上肯定无法和原生相比，没得说。
- 对内存占用相对较高
Chrome是吃内存大户，这个应该是众所周知的吧。那基于Chrome内核整出来的玩意，对内存占用小也小不到哪吧。
所以，相当一部分人对类似的应用不是非常喜欢，有一种好像在电脑上打开一堆Chrome的感觉。
- 体积
由于Electron是采取把Chrome内核打包进应用的模式，理所当然的这玩意体积很大。以最新的版本为例，你如果啥都不干，就呈现一个简单的页面，上百M是少不了的。
终结者，WebView2?
而微软在Twitter上发了一条消息，它们把自己的一个产品迁移使用WebView2，替换掉了Electron，这是怎么一回事？
事实上，WebView2，光是从这名字上看，就知道还是没有脱离浏览器。WebView2是基于微软自己的edge内核，但edge内核只是chrome内核的fork版本而已。
那WebView2究竟有什么优势，它做了什么改变，它会把Electron打败下去么？未来这些基于Electron开发的应用又会纷纷改变自己路线么？究竟桌面跨平台应用还有更具有性价比的选择么？
下篇我们再聊。