王森的博客

因为 wadesk 开发了本地 http 服务，http 本地服务是运行在 electron-main 的纯 node 环境中的，这个之前探讨了 node 下怎么使用 fetch 时就提到了一个 https-proxy-agent 库，这次使用 axios，发现 axios 自带 proxy 配置项，就没有多想，造成了 4 个小时的时间浪费，此次排查应该作为一个反思例子对待。

背景electron 主渲进程的打包，以及 preload 的打包，还有注入脚本的打包，这些东西 webpack 本身是自带的，这里主要讲一下 target: node 模式

electron-vue npm run build 打包超级慢的原因不是最终electron-builder环节的问题，而是webpack打包渲染进程的问题，今天经过与ChatGPT一起优化，终于把速度降了大概5倍左右，直接让文件打包速度快了很多。

因为组员对于 Electron 打包过程存在比较迷糊的状态，且自己也没主动探索 Electron-vue 打包细节，导致每次打包过程都消耗 5-6 分钟的时间，在需要测试生产打包时，极其浪费时间，为此针对 Electron-vue 打包的几个环节进行拆解，来减少打包时间，提高开发效率。

在开发 Electron 过程中，我们想知道 Electron 打包的最终形态是什么样的，以便我们能更好的理解 Electron 打包的过程，以及逆向来快速追踪一些问题，例如下面这个报错，以前这类报错都是靠猜，现在则可以快速定位，找到源码问题发生点

目前谷歌扩展有 50W 之多，覆盖面比较广，而 Electron 又是基于谷歌浏览器内核开发的，如果将两者结合，那么就能大大节省很多开发时间，开发出来的客户端功能却更加丰富，不过 Electron 并没有完美支持谷歌扩展，尤其是谷歌扩展 MV3 版本中提供的大量的 API，Electron 本身都是不支持的，这就给开发者一种误导，Electron 不支持 MV3 的扩展。

自从2022年底chatgpt上线后，sse就进入了大众的视野，之前是谁知道这玩意是什么？但是打字机的效果看起来是真的很不错，一度吸引了很多人的趋之若鹜，当然了这个东西的确挺好用，而且实现很简单，之前我用python的demo讲了一下SSE的概念，看起来有很多人看，但是并没有说明白这个原理，这次再彻底把这个原理给说明白，而且我发现通过node.js 的Express框架来说明这个概念更加简洁，所以今天就用Express框架来说明SSE概念，这样对前端同学更加友好。

经过通信层面的优化后，我们不再走 Electron 提供的内置进程间通信 IPC，改为利用 Express 提供的 Http 本地服务来进行多处直达通信机制，同时利用本地 Sqlite 来保存大量数据，但 Express 提供的本地服务是支持并发请求的，而 Sqlite 是不支持行锁的机制，一旦有写入操作，Sqlite 都是直接锁库，除了采用单表单库减少锁库问题外，另外就是走队列的方式来逐个入库，避免写锁问题。

这个东西可能是我十几年前最开始接触的东西，第一次web开始，就是要做登录注册的功能，当时就涉及到cookie和session，用的还是Java，Java 来做Web本身就够晦涩难懂的了，跟更古老的C做Web开发差不了多少（已C语言的方式做了一个Html的字符串输出的模板引擎），即使现在有了SB好了很多， 但也高度封装了底层代码，甚至好多现在Java开发连servlet是啥东西都不知道了。这篇文章是写给新人的，当然很多老开发者看似懂了，其实也只不过是唯手熟尔，对于底层到底发生了什么，自己能否手敲实现相关的

之前写了一篇Electron通信的方式，讲述了一下三者之间的通信机制，比较恶心，后来发现有个@electron/remote，可以让渲染进程直接访问主进程，但遗憾的是，preload.js无法使用这个库，webview更是不可能直接触达主进程，总要通过preload.js绕一圈才能找到渲染进程。为此，我们需要一个新的方式，来解决所有通信链路的问题。

remote是个老库，早期Electron版本中有个remote对象，这个对象可以横跨所有进程，随意通信，后来官方认为不安全，被干掉了，之后有人利用Electron的IPC通信，底层通过Promise的await能力，模拟了一个类似的remote对象，即@electron/remote没有当年的remote那么强大，但是也很好用，当然，若觉得自己生命值较长，可以不屑一顾，自己再造轮子。

在调研浏览器多开的过程中，electron 有自带的 browserview，webview，但是上面两个受制于 electron 内核版本限制，升级不够灵活，对新版的网页支持可能不及时，甚至不兼容，必须通过发布新的客户端版本才能解决，此外，这两个组件本身也不稳定，经常内存溢出，如果能改为 chrome 自己开发的浏览器内核来运行，则以上问题解决起来都不会特别吃力，所以才有了对 Electorn 控制浏览器多开的技术调研。下载好之后，找到路径，在地址栏输入 cmd，按回车，即可打开控制台。

​写客户端多分身本地数据交替升级解决方案 - 绝对干货全网难找-CSDN博客发现需要不同的代码库依赖同一个github升级库，这样就能保证主线版本的升级，大家都在一个分支上，并且也方便查看升级代码，比较升级代码，也方便主线代码的升级过程，非常Nice，为此，这里特意进行一个Demo实现。

开发客户端时，为了应对不同客户的不同需求，大杂烩的客户端往往使得代码非常凌乱，补丁代码越堆越多，但是这并不能让产品的付费转化提高，每个用户都有自己的需求偏重，同时也更在意自己的需求的体验和稳定性，不断地增加更多功能，会使得系统过于庞大，同时还降低了系统的稳定，互相影响是难免的。但如果抽离不同功能形成新的版本，就会出现分裂，渐渐地就会出现底层数据结构的分裂，一旦分开就有走得快的，走得慢的，慢的和快的就会产生结构的不同，为了应对这种结构的自然变化，以及使用者的不可控（对方可能一直用着旧版本），这就造成了版本

程序员编码的最大问题是受制于最初c++面向过程的思维引导，导致后续所有的代码里面，if...elseif...非常多，同时想要让自己的一串代码尽可能处理更多可能的场景，此外，还想将公共逻辑抽出，我们最喜欢做的事情就是，先设置几个变量，然后不断地分析逻辑，不断地追加变量的值

开发过程中，有些时候，要访问公司内网服务器，提供的一些服务啥的，但是问题的关键是用户使用的网络各不相同，所以就要动态地使用系统代理来访问，但是主进程默认为控制台级别的请求，不走系统网络，除非你代码中指定走系统代理，这个就有了这篇内容

Franz是Electron开发中一个比较深度的开源代码，但因含有大量的基础知识，导致早期我没有花费时间来倒腾这个，这次采用按图索骥地方式，借助AI的提示，一点点地将启动过程搞出来，这估计是官方故意搞得一个坑，大概意思时 ，连运行起来的本事都没有，就别看代码了，看也白看！

electron 这东西文档乱七八糟，版本迭代飞快，里面技术还多得不得了，但强大是真的强大，好用是真的好用，头疼是真的头疼，搞不好就内存泄漏了，问题多多，踩坑多多，后期我把代码整理号了，发到gitee上，再追加上来。npm可以设置代理，如果不会的，请自行搜索，这里就细讲了，有时候代理也不行就需要，在控制台，设置环境，不加这个，也能让你下载安装包下到怀疑人生，实在搞不了安装包问题的，可以私信我发node-modules。还有个热更新报错，这个去年已经讲了，这里就不再赘述，改了即可。