微软要放弃Electron了???聊聊WebView2

有好几个公众号发文说“微软要放弃Electron了”,实际情况是微软旗下的Teams产品打算把Electron框架换成WebView2而已。接下来我就聊一下这个事情:

微软要放弃Electron了???聊聊WebView2

 

微软不会放弃Electron

 

第一:Electron是GitHub的产品,GitHub是微软的子公司,WebView2是Edge团队的产品(是Edge的副产物),Edge团队是微软直属的团队,所以事情就是:Teams打算切换一下自己的底层框架,而且这两个框架都是自己公司的产品,并不是放弃自己公司的框架,用了其他公司的框架。

 

第二:微软内部有很多软件都是基于Electron开发的,比如VSCode和GitHubDesktop,不仅仅是只有Teams这么一个产品在用它,非但微软内部,包括Facebook、MongoDB、twitch、Slack、迅雷、字节跳动、阿里、拼多多、京东等大企业都在用这个框架,这么一个好东西,微软怎么会放弃它呢?

 

第三:Teams之所以要把Electron换成WebView2,并不是因为Electron不好,而是因为Electron不称手,就像一个木匠换个锤子敲钉子一样普通,对于那些Electron的从业者,或者想进入Electron这个领域的开发者,没什么好担心的。

 

具体的技术细节

 

第一:开发者是没有办法只用前端技术基于WebView2开发桌面应用的。开发者要满足类似:读写文件、访问剪切板、设置托盘图标这类系统级需求,就必须自己写C++或者C#代码来实现。而这对于Electron的开发者来说,只要写JavaScript就可以了。

 

第二:WebView2目前是没跨平台能力的,也就是说基于WebView2开发的桌面应用仅能在Windows操作系统下运行,无法在Mac或者Linux下运行,即使将来WebView2提供了跨平台能力,那么开发者写的C++代码就要考虑如何在不同的平台下调用不同的系统API,如果开发者写的是C#代码,那么就要考虑如何把.NET框架分发给他们的用户了。显然Teams产品是一个跨平台的产品,他们财大气粗,很有可能Windows系统用WebView2实现,其他系统用原生技术实现,或者与系统API有关的C++代码写3次也没问题。我们普通开发者就很难这么做。

 

第三:WebView2要求开发者使用C++或者C#实现系统级需求,这就给了开发者精细化控制的能力,我想这也是Teams团队看中的东西,然而要想获得这种能力为什么不直接选Qt的QWebEngin或者cef呢?毕竟他们和WebView2一样都是对Chromium内核的封装,很显然微软的团队是不能做这种决定的,因为Qt有版权的问题,cef也不是自家的东西。相对来说我们普通开发者在这种选择上就自由很多。

 

第四:WebView2目前还很不成熟,我上次调研它时,它还不支持自定义Scheme(如果它不支持,开发者很难通过C++或C#代码让应用具备这方面的能力的),甚至连PrintToPdf这类API也还是几个版本前才提供出来的。

 

第五:WebView2的生态很不好,想想看:你如何在应用中自如的使用Sqlite(能获得类似Knex.js这样的支持吗)、如何让你的应用读取并显示一个本地大文件(大概率要自己实现流式读取的机制,要把文件数据Chunk转成ArrayBuffer再交给界面的Js,涉及到各种编解码及进程间通信的问题)

 

第六:WebView2是不开源的,这更加恶化了WebView2的生态;而且对于一些疑难杂症来说,开发者也很难进行源码级别的调试。有些开发者可能会认为这或许有利于保护源码,估计这些开发者不知道怎么让Electron保护自己的源码,这里说一下思路:开发者可以把Electron源码拉到本地,修改asar拆包封包的逻辑,然后再自己编译一下Electron,这样就可以保护应用的源码了。

 

第七:WebView2的性能提升或资源消耗削减可能并没有那么明显,我们都知道,只要使用Chromium,就难逃多进程架构,WebView2也不例外,它的进程甚至比Electron的进程还要多一个。多进程才是资源消耗高的症结所在。它的优势就是可以和其他应用共享进程。但假设用户也没开Edge,也没打开其他WebView2应用呢?这种优势还体现的出来吗?因为要自己实现系统级需求,不再需要加载Node框架,性能提升或许有一些(这取决于开发者的能力),但为了这些性能提升舍弃的东西也太多了,我们普通开发者难以承受。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zgzwpw.html