1.深入理解Electron（一）Electron架构介绍
2.electron 打包实现代码混淆和加密
3.Electron-托盘、仿钉气泡(闪烁)消息、钉源只启动一个实例、码e码分Win/Mac打包配置、仿钉最小化/退出等小结
4.抽丝剥茧：Electron与Node.js的钉源奇葩Bug
5.从源码解析Electron的安装为什么这么慢

深入理解Electron（一）Electron架构介绍

       深入理解Electron架构：一个基于Web的跨平台框架

       Electron，源自Atom Shell，码e码分微信同城门户源码是仿钉通过结合JavaScript、HTML和CSS构建跨平台桌面应用的钉源框架。官网的码e码分解释是，它将Chromium的仿钉浏览器内核和Node.js的核心技术打包，使得开发者无需本地开发经验，钉源即可在Windows、码e码分macOS和Linux上轻松创建应用。仿钉起初，钉源为Atom编辑器设计的码e码分Electron，由曾参与node-webkit和NW.js项目的关键开发者创建，并在年正式更名。

       与其他框架，如Tauri和Webview2，利用不同策略集成Chromium和Node.js不同，Electron的目标是提供一个基于Web的开发环境，让开发者能够利用熟悉的Web技术开发原生应用，实现了跨平台开发。Qt，作为C++的桌面跨端开发典范，曾是这一领域的重要先驱，而随着互联网时代的变迁，Electron这类技术逐渐受到欢迎。

       尽管C和C++的性能优于Electron，但软件语言的发展也受益于硬件的进步。性能和易用性之间的平衡是关键，例如Node.js利用V8和LibUV，推动了前端开发的飞速发展。Electron在性能上可能不如C++框架，但其简化开发过程和维护成本的特性使其成为当今流行的选择。

       Electron的架构设计借鉴了Chromium的复杂但强大的多进程架构，浏览器主进程负责Node.js的交互，而渲染进程则通过Chromium加载和渲染UI。这种设计允许高效地管理和隔离GUI窗口，同时保持了系统的灵活性和安全性。在源码层面，Node.js接口和C++模块的集成确保了功能的实现和性能的优化。

       总的来说，Electron通过集成Web技术栈和Chromium的内核，实现了跨平台的开发效率，并在性能和易用性之间找到了一个折中的haar opencv 源码分析点。随着互联网业务的发展和软件技术的迭代，Electron成为了满足快速迭代和跨平台需求的理想选择。

electron 打包实现代码混淆和加密

       实现electron代码混淆和加密的技术方案在开发流程中至关重要。在构建阶段，对asar压缩包中的js文件进行混淆加密，可以大大增加逆向工程的难度，保护应用的知识产权。具体操作步骤如下：

       首先，在electron应用的构建脚本中加入混淆加密的步骤。在afterSign文件中实现这一功能，这是构建流程中处理签名文件的最后阶段。

       接着，使用asarmor工具对asar压缩包进行防解压加密。asarmor是一个强大的工具，它能在文件系统层面进行加密，阻止恶意用户轻易解压和访问敏感代码。加密过程通常涉及在文件名或内容中插入特定字符，以此来混淆原始结构。

       在afterSign文件的实现中，关键步骤是定位到asar包内的js文件，并应用asarmor进行加密。这一步骤确保了源代码在打包过程中的安全，提升了应用的防护级别。

       然而，需要注意的是，上述提到的加密方法仅提供有限的保护。它们无法完全阻止所有类型的逆向工程或破解尝试。因此，开发者还需结合其他安全策略，如定期更新依赖库、使用HTTPS通信、实现权限控制等，以构建多层次的安全防护体系。

       总之，通过在electron应用构建流程中应用代码混淆和加密技术，能够有效提高应用的保护水平，抵御部分攻击手段，为开发者提供一种相对安全的代码防护方法。但同时，开发者还需持续关注安全威胁的最新动态，不断完善安全策略，以确保应用始终处于安全状态。

Electron-托盘、气泡(闪烁)消息、只启动一个实例、foodie 开放源码Win/Mac打包配置、最小化/退出等小结

       在Electron开发过程中，我接触并实践了一系列相关的工具和技术，如Vue、Vuex、Element、Axios和Cordova等。在接触Flutter时，我也在思考它是否能成为一种趋势。在Visual Studio Code的背景设置代码方面，我了解了一些基本的配置。目前，项目已经进入了打包测试阶段，尤其是在Mac打包过程中，我遇到了一些问题。以下内容是基于个人经验进行的总结，可能存在认识上的浅薄，但希望能为初学者提供一些实用的指导。

       在应用图标、安装界面图标、托盘图标和资源的配置与使用中，通常会将这些资源放在`build/`目录下的`icons`文件夹中，如`x.png`和`icon.png`。这些资源通常用于主进程，即浏览器外壳。同时，`static`文件夹下可以存放页面中用到的资源，这些资源会被打包到安装包或可执行程序目录下的`app.asar`压缩包中。`static`资源更多地用于渲染进程页面相关，而`build/xxxx`目录则用于程序级别的资源。

       打包过程中，Electron默认不会将`icons`资源打包，需要通过`package.json`的`extraResources`配置来实现。在Windows打包后，资源会被放置在`win-unpacked/resources`目录下；而在Mac打包后，资源路径则较为复杂，通常在`dmg`或`zip`安装程序内。对于Windows，可以使用`nsis`来配置安装程序信息，如创建快捷方式、安装程序图标、卸载程序图标等。

       在打包后的安装包中，可以配置英文版，优化程序的mybatis 书 源码 介绍图标，并对`package.json`进行相关修改以适应不同平台需求。例如，针对Win和Mac资源路径的不同，可以使用`path.join`方法来确保资源路径的正确性。托盘图标采用PNG格式，并针对不同平台进行适配，以解决路径匹配问题。

       在创建托盘和实现气泡闪烁功能时，需要使用定时器来回切换图标，透明图标可以达到闪烁效果。在实现只启动一个实例、点击关闭按钮最小化到托盘、点击托盘弹出程序界面等功能时，代码逻辑需要根据平台（如Win和Mac）进行区分处理。

       对于Websocket接收推送消息并实现气泡闪烁及消息通知处理，需要在Vue中封装相应的方法。初始化socket并注册回调，以接收推送消息，然后通过`ipcRenderer`将消息发送给主进程，主进程进行消息通知处理。同时，需要考虑Win和Mac平台上的通知方式差异，如使用`appTray.displayBalloon`或`window.Notification`。

       在实现程序自动更新时，可以使用`electron-builder`配合`electron-updater`。首先需要配置更新服务器地址，然后在`src/main/index.js`中实现更新检查、弹窗、日志处理等功能。遇到的常见问题包括Electron版本过低导致的错误，可以通过升级Electron版本来解决。在打包和更新过程中，还需要解决资源路径配置问题，如富文本控件的路径配置。

       在Electron开发中，除了专注于前端界面制作和逻辑处理，还需关注跨平台开发、资源管理、打包配置等细节。同时，通过实践和学习，如深入Android源码和Flutter，可以进一步扩展跨平台开发能力。虽然Electron并非我的专业领域，但通过不断学习和实践，bacnet协议栈 源码希望能为团队带来价值。

抽丝剥茧：Electron与Node.js的奇葩Bug

       起因是最近在用Electron开发一个桌面端项目，有个需求是需要遍历某个文件夹下的所有JavaScript文件，对它进行AST词法语法分析，解析出元数据并写入到某个文件里。需求整体不复杂，只是细节有些麻烦，当我以为开发的差不多时，注意到一个匪夷所思的问题，查的我快怀疑人生。

       缘起

       什么问题呢？

       原来这个需求一开始仅是遍历当前文件夹下的文件，我的获取所有JS文件的代码是这样的：

       后来需求改为要包含文件夹的子文件夹，那就需要进行递归遍历。按照我以前的做法，当然是手撸一个递归，代码并不复杂，缺点是递归可能会导致堆栈溢出：

       但做为一个紧跟时代浪潮的开发者，我知道Node.js的fs.readdir API中加了一个参数recursive，表示可以进行递归，人家代码的鲁棒性肯定比我的好多了：

       只改了一行代码，美滋滋~

       兼容性怎么样呢？我们到Node.js的API文档里看下：

       是从v..0添加的，而我本地使用的Node.js版本正是这个（好巧），我们Electron中的Node.js版本是多少呢？先看到electron的版本是.0.4：

       在Electron的 发布页上能找到这个版本对应的是..1，比我本地的还要多一个小版本号：

       这里需要说明一下，Electron之所以优于WebView方案，是因为它内置了Chrome浏览器和Node.js，锁定了前端与后端的版本号，这样只要Chrome和Node.js本身的跨平台没有问题，理论上Electron在各个平台上都能获得统一的UI与功能体验。 而以Tauri为代表的WebView方案，则是不内置浏览器，应用程序使用宿主机的浏览器内核，开发包的体积大大减小，比如我做过的同样功能的一个项目，Electron版本有M+，而Tauri的只有4M左右。虽然体积可以这么小，又有Rust这个性能大杀器，但在实际工作中的技术选型上，想想各种浏览器与不同版本的兼容性，换我也不敢头铁地用啊！ 所以，尽管Electron有这样那样的缺点，仍是我们开发客户端的不二之选。 之所以提这个，是因为读者朋友需要明白实际项目运行的是Electron内部的Node.js，而我们本机的Node.js只负责启动Electron这个工程。

       以上只是为了说明，我这里使用fs.readdir这个API新特性是没有问题的。

       排查

       为方便排查，我将代码再度简化，提取一个单独的文件中，被Electron的Node.js端引用：

       能看到控制台打印的 Node.js 版本与我们刚才查到的是一样的，文件数量为2：

       同样的代码使用本机的Node.js执行：

       难道是这个小版本的锅？按理说不应该。但为了排除干扰，我将本机的Node.js也升级为..1：

       这下就有些懵逼了！

       追踪

       目前来看，锅应该是Electron的。那么第一思路是什么？是不是人家已经解决了啊？我要不要先升个级？

       没毛病。

       升级Electron

       将Electron的版本号换成最新版本v.1.0：

       再看效果：

       我去，正常了！

       不过，这个包的升级不能太草率，尤其正值发版前夕，所以还是先改代码吧，除了我上面手撸的代码外，还有个包readdirp也可以做同样的事情：

       这两种方式，在原版本的Electron下都没有问题。

       GitHub上搜索

       下来接着排查。

       Electron是不是有人发现了这个Bug，才进行的修复呢？

       去 GitHub issue里瞅一瞅：

       没有，已经关闭的问题都是年提的问题，而我们使用的Electron的版本是年月日发布的。 那么就去 代码提交记录里查下（GitHub这个功能还是很好用的）：

       符合条件的就一条，打开看下：

       修复的这个瞅着跟我们的递归没有什么关系嘛。

       等等，这个文件是什么鬼？

       心血来潮的收获

       我们找到这个文件，目录在lib下：

       从命名上看，这个文件是对Node.js的fs模块的一个包装。如果你对Electron有了解的话，仔细一思索，就能理解为什么会有这么个文件了。我们开发时，项目里会有许多的资源，Electron的Node.js端读取内置的文件，与正常Node.js无异，但事实上，当我们的项目打包为APP后，文件的路径与开发状态下完全不一样了。所以Electron针对打包后的文件处理，重写了fs的各个方法。

       这段代码中重写readdir的部分如下：

       上面的判断isAsar就是判断是否打包后的归档文件，来判断是否要经Electron特殊处理。如果要处理的话，会调用Electron内部的C++代码方法进行处理。

       我发现，这里Electron并没有对打包后的归档文件处理递归参数recursive，岂不是又一个Bug？应该提个issue提醒下。

       不过，我们目前的问题，并不是它造成的，因为现在是开发状态下，上面代码可以简化为：

       对Promise了如指掌的我怎么看这代码也不会有问题，只是心血来潮执行了一下：

       我去，差点儿脑溢血！

       好的一点是，曙光似乎就在眼前了！事实证明，心血来潮是有用的！

       Node.js的源码

       这时不能慌，本地切换Node.js版本为v，同样的代码再执行下：

       这说明Electron是被冤枉的，锅还是Node.js的！

       Node.js你这个浓眉大眼的，居然也有Bug！呃，还偷偷修复了！

       上面的情况，其实是说原生的fs.readdir有问题：

       也就是说，fs.promises.readdir并不是用util.promisify(fs.readdir)实现的！

       换成同步的代码readdirSync，效果也是一样：

       我们来到Node.js的GitHub地址，进行 搜索：

       打开这两个文件，能发现，二者确实是不同的实现，不是简单地使用util.promisify进行转换。

       fs.js

       我们先看 lib/fs.js。

       当recursive为true时，调用了一个readdirSyncRecursive函数，从这个命名上似乎可以看出有性能上的隐患。正常来说，这个函数是异步的，不应该调用同步的方法，如果文件数量过多，会把主进程占用，影响性能。

       如果没有recursive，则是原来的代码，我们看到binding readdir这个函数，凡是binding的代码，应该就是调用了C++的底层库，进行了一次『过桥』交互。

       我们接着看readdirSyncRecursive，它的命名果然没有毛病，binding readdir没有第4个参数，是完全同步的，这个风险是显而易见的：

       fs/promises.js

       在lib/internal/fs/promises.js中，我们看到binding readdir的第4个参数是kUsePromises，表明是个异步的处理。

       当传递了recursive参数时，将调用readdirRecursive，而readdirRecursive的代码与readdirSyncRecursive的大同小异，有兴趣的可以读一读：

       fs.js的提交记录

       我们搜索readdir的提交记录，能发现这两篇都与深度遍历有关：

       其中 下面的这个，正是我们这次问题的罪魁祸首。

       刚才看到的fs.js中的readdirSyncRecursive里这段长长的注释，正是这次提交里添加的：

       从代码对比上，我们就能看出为什么我们的代码遍历的程序为2了，因为readdirResult是个二维数组，它的长度就是2啊。取它的第一个元素的长度才是正解。坑爹！

       也就是说，如果不使用withFileTypes这个参数，得到的结果是没有问题的：

       发版记录

       我们在Node.js的发版记录中，找到这条提交记录，也就是说，v..0才修复这个问题。

       而Electron只有Node.js更新到v后，这个功能才修复。

       而从Electron与Node.js的版本对应上来看，得更新到v了。

       只是需要注意的是，像前文提过的，如果是遍历的是当前项目的内置文件，Electron并没有支持这个新的参数，在打包后会出现Bug。

       fs的同步阻塞

       其实有人提过一个 issue：

       确实是个风险点。所以，建议Node.js开发者老老实实使用fs/promises代替fs，而Electron用户由于坑爹的fs包裹，还是不要用这个特性了。

       总结

       本次问题的起因是我的一个Electron项目，使用了一个Node.js fs API的一个新参数recursive递归遍历文件夹，偶然间发现返回的文件数量不对，就开始排查问题。

       首先，我选择了升级Electron的包版本，发现从v.0.4升级到最新版本v.1.0后，问题解决了。但由于发版在即，不能冒然升级这么大件的东西，所以先使用readdirp这个第三方包处理。

       接着排查问题出现的原因。我到Electron的GitHub上搜索issue，只找到一条近期的提交，但看提交信息，不像是我们的目标。我注意到这条提交的修改文件（asar-fs-wrapper.ts），是Electron针对Node.js的fs API的包装，意识到这是Electron为了解决打包前后内置文件路径的问题，心血来潮之下，将其中核心代码简化后，测试发现问题出在fs.promises readdir的重写上，继而锁定了Node.js版本v..1的fs.readdir有Bug。

       下一步，继续看Node.js的源码，确定了fs.promises与fs是两套不同的实现，不是简单地使用util.promisify进行转换。并在fs的代码找到关于recursive递归的核心代码readdirSyncRecursive。又在提交记录里，找到这段代码的修复记录。仔细阅读代码对比后，找到了返回数量为2的真正原因。

       我们在Node.js的发版记录中，找到了这条记录的信息，确定了v..0才修复这个问题。而内嵌Node.js的Electron，只有v版本起才修复。

       不过需要注意的是，如果是遍历的是当前项目的内置文件，由于Electron并没有支持这个新的参数，在打包后会出现Bug。而且由于fs.readdir使用recursive时是同步的，Electron重写的fs.promises readdir最终调用的是它，可能会有隐性的性能风险。

       本次定位问题走了些弯路，一开始将目标锁定到Electron上，主要是它重写fs的锅，如果我在代码中用的fs.readdirSync，那么可能会更早在Node.js上查起。谁能想到我调用的fs.promises readdir不是真正的fs.promises readdir呢？

       最后，针对此次问题，我们有以下启示：

       PS：我给Electron提了个 issue，一是让他们给fs.readdir添加recursive参数的实现，二是让他们注意下重写时fs.promises readdir的性能风险。

从源码解析Electron的安装为什么这么慢

       Electron的安装速度慢主要源于其跨平台特性导致的二进制基座差异化和默认下载机制。本文通过解析源码，揭示了下载过程中的关键环节。

       安装过程：

       当通过npm install electron -D命令下载时，如果没有配置特定的镜像，npm会默认下载对应平台的二进制基座。这个过程可能会因为网络原因或镜像源选择而变得缓慢。

       解决方法：

       设置.npmrc文件中的ELECTRON_MIRROR，指向国内镜像源，如'https://npm.taobao.org/mirrors/electron/'，可显著加快下载速度。

       源码分析：

       - @electron/get模块负责下载Electron的二进制制品，它会优先检查本地缓存，若存在则直接使用，否则从远程下载。

       - 缓存路径默认在Windows下为~/AppData/Local/electron/Cache/，可以通过设置控制缓存行为。

       附录：

       - @electron/get支持自定义镜像源、版本和下载选项，以及代理设置。

       - 通过环境变量，如ELECTRON_GET_USE_PROXY，可以配置代理支持。

       总之，理解Electron安装的底层原理和优化策略，能够帮助开发者有效提升开发效率。