为什么electron不做成独立的runtime？

首先我们要为Runtime使用者提供一个专有的打包工具&＃xff0c;我们就叫它&＃xff1a;打包工具。这个打包工具还内置了几个可执行程序&＃xff0c;我们给他们起个名字&＃xff0c;分别叫&＃xff1a;

1. 最终安装程序

2. 最终执行程序

3. 最终卸载程序

因为electron是可定制的&＃xff0c;每个项目都可以根据自身需求做出微调&＃xff0c;最终就产生了不同修改的运行时&＃xff0c;而你看锁定在系统里不可定制的webview2&＃xff08;基于msedge&＃xff09;&＃xff0c;就可以很方便地不带runtime分发。

打包工具的职责&＃xff1a;

1、按Runtime使用者的要求修改最终执行程序的图标、应用签名、版本、版权、文件名等资源信息。

2、按Runtime使用者的要求修改最终卸载程序的图标、应用签名、版本、版权、文件名等资源信息。

3、把最终执行程序、最终卸载程序与Runtime使用者开发好的HTML/CSS/JS等静态文件放到一起&＃xff0c;压缩成一个压缩包&＃xff0c;我们叫他&＃xff1a;资源文件

4、把这个资源文件以资源的形式封装到最终安装程序中&＃xff1b;按Runtime使用者的要求修改这个最终安装程序的图标、应用签名、版本、版权、文件名等资源信息。

很多linux发行版就是把electron打包成独立的runtime啊。但是electron的迭代太快了&＃xff0c;导致比如vscode从来都落后官方1到2个大版本号&＃xff0c;所以就算是独立打包你还是会得到electron全家桶。而且electron小版本很多&＃xff0c;独立打包要解决小版本共存问题。而且vscode的非oss版本也只能把electron打包进去。

简单来说就是&＃xff0c;就是时代变了&＃xff0c;软件分发策略也变了。macOS和linux就是两种策略的典型代表。Linux提倡模块化共享&＃xff0c;每个软件都显式声明依赖关系&＃xff0c;再配上包管理机制&＃xff0c;基本上可以做到缺什么库就自动下载什么库。这样的好处就在于如果多个软件依赖同一个版本的库&＃xff0c;那么系统就只安装一份这样的库&＃xff0c;从而避免了不必要的空间消耗。

 macOS及同类风格的iOS提倡“整体打包”&＃xff0c;每个软件及其依赖的第三方库全部放在一个Bundle里&＃xff0c;所谓的app本质上就是Bundle文件夹。这样做的优点就在于安装简单&＃xff0c;直接复制即可&＃xff0c;系统整体上没有什么耦合性&＃xff0c;反正app各管各的。缺点是软件体积大&＃xff0c;文件重复率高。

Windows下两种策略都有&＃xff0c;但由于没有统一的包管理机制&＃xff0c;多数情况下还是得需要用户提前安装相关的依赖。有的软件做了比较完善的安装程序&＃xff0c;则由安装程序负责维护相关依赖。

整体上看&＃xff0c;随着生产成本降低&＃xff0c;存储空间变大&＃xff0c;读写和传输效率提高&＃xff0c;相比于上个世纪&＃xff0c;人们越来越不在意空间浪费的问题&＃xff0c;更愿意拿空间换时间&＃xff0c;近些年的技术发展无不在证明这一趋势。因此&＃xff0c;整体打包的分发策略可能终将占领上风TG&＃xff1a;li9047。