发发牢骚 吐槽一下 electron build

开发调优
,
1

背景

最近开始为 Tuff 的正式版本发布做准备，已经打包了好几个版本了，正在做各个平台的测试。
但是我发现 github actions 中，就 windows 的构建时间最长，往往是其他平台的好几倍时长，但是产物体积却格外的小，不太明白，纯小白。

正文

现在开始怀疑自己 electron 技术栈选的是否正确了，但是都已经改到这种程度了说换技术栈也没有那种魄力了。现在唯一的心思就是赶紧好好开发 Tuff 的拓展，目前主体是没啥大问题了，就是 拓展 相关的 sdk 还欠缺非常多，可能这个是需要一个长时间发布迭代的过程

那么，有以下几个插件可用：

  • Clipboard 剪贴板管理 他会存储所有剪贴板信息 90day，根据搜索的次数综合比较，结合对应的内容选择是否要删除，并且有永不删除，尤其是密钥类信息默认就会永不删除。那么这个东西目前只是简单做了一下，实际使用还有问题，我感觉我需要做类似 raycast 动态加载 tsx 这种文件，而不是直接加载一个 webview 现在实在是太慢了。目前做的 widgets 就是在为这个功能做铺垫，敬请期待。
  • QuickerOpen 快速打开任何东西，配备了一百多个常用网站：开发者网站(npm github)，搜索引擎，新闻百科等，快速输入 query 不需要配置就可以直接打开，省去了很多麻烦。
  • TouchTranslation 聚合翻译插件，快速翻译任何内容，直接复制到剪贴板，也可以使用多源翻译，同时用十个翻译。也可以自己配置 llm api，兼容本站的 DeepLX

这是目前在做的几个插件，因为实在太忙，插件基本都会让 AI 做，也会有很多 bug，我会慢慢迭代的。emm，大概简单发一下牢骚，顺便让关注这件事情的佬友知道我的进度，太感谢佬友们的关注了，感觉很辜负大家。

照例，发几张截图。

PixPin_2025-11-04_20-49-32
PixPin_2025-11-04_20-49-322560×1560 240 KB

PixPin_2025-11-04_20-49-47
PixPin_2025-11-04_20-49-471920×1170 192 KB

PixPin_2025-11-04_20-50-28
PixPin_2025-11-04_20-50-281800×1200 261 KB

PixPin_2025-11-04_20-51-19
PixPin_2025-11-04_20-51-191800×1100 190 KB

7 个赞
2

看着还不错欸，支持一下！ :star_struck:

1 个赞
3

我靠 佬友你好快！

4

啊？ :lark_012: 这很快嘛，我还是先去 Github 上搜了一下，读完才回的帖

5

支持支持 :hand_with_index_finger_and_thumb_crossed:

6

很快啊 我感觉我刚发 你就回了 可能是我网速慢了 实际上已经发了但是我这里还在 loading :sob:

7

这是要干掉utool 的节奏:tieba_031:

8

:laughing: 那得生态很强大了

9

处于好奇，看了下你的 actions 的结果。确实存在 Windows 比 macOS 慢，其时间差在 1 分钟左右。

花了一点点时间调查了下，解答一下你的疑惑:

TL;DR: 主要原因是由于 7z 压缩导致，次要原因为 Windows 在处理 I/O 天然就会比 macOS 慢。

在你的 electron-builder 构建逻辑中，其 macOS 构建是不会压缩的，仅打包成 .app。由你编写的脚本代码去执行 zip 压缩。

而在 Windows 中，压缩由 electron-builder 执行，而 electron-builder 默认的压缩执行器是 7za，同时其压缩参数中的 -mx 默认为 9(压缩级别最大)

由于压缩算法的不同，

  • zip 是压缩快，解压慢
  • 7z 是压缩慢，解压快

同时 7z 还设置了最大的压缩比，其速度会变的更慢。

你可以在构建时添加: ELECTRON_BUILDER_COMPRESSION_LEVEL 来控制压缩比。经过测试，压缩比为 5 时，其大小会增加 8 M，而构建时间可以减少 40 秒左右。

相关源码: electron-builder/packages/app-builder-lib/src/targets/archive.ts at 509f11825ad6106ab2e0c1ea3adeedf276ecfd07 · electron-userland/electron-builder · GitHub

3 个赞
10

太感动了 佬友！

  1. 压缩比这个确实是因为打包结果太大了 做了一个极致压缩，最初在 elctron-builder 配置中我已经尝试过了，确实很影响时间，但是打包的时间其实无所谓
  2. 真正让我好奇的反而是 macos

为什么是 app

macos 中，最初打包 dmg 死活都有问题，可能是 image 有点奇怪，索性全部迁移到 .app 这也是为何我要执行 打包逻辑 的原因，因为 会存在：macos guaranteen 或者 部分包体异常问题，做了个修复

但是在最新版本中，我已经全部优化了整个打包逻辑。（感谢帮助我的各位佬友）

  1. 包体全部重构，仅打包必要包，大部分都直接打包到内部，而不是残留的 node_modules
  2. 不再执行 macos 复制包操作，全部精简

于是，新版本打包体积（macos）从 800MB+ 缩减到了 200MB+
windows 没测试过，不过 windows I/O 确实慢

十分感谢佬友！

11

目前 electron 社区的打包工具，基本上涉及到 dmg 打包，最终使用的都是 GitHub - LinusU/node-appdmg: 💾 Generate your app dmgs 。无论是 forge 还是 electron-builder。

如果你发现打包 dmg 一直失败，可以尝试直接调用 appdmg 来协助你判断是哪里出了问题，而不用每次都跑构建流程。

至于 node_modules，在 macOS 中基本上没有太大的影响。但是在 Windows 中会出现严重的性能问题，因为 Windows 在读取大量小文件时性能会极速下降。
所以你可以将源码放在 asar 中，而二进制等文件放在 asar.unpacked 文件夹下。

12

dmg 打包出来实际上是 损坏 的问题，这个问题我还没有深入排查过，等 app 稳定一点 我去重新看看这个问题 感谢佬友～

这个 nodemodules 主要是 macos 上会复制多份以此来解决一些问题（之前一直让 ai 去写的脚本，目前我已经完全抛弃了，所以我也不知道为什么 ai 要这样做）

新版本我已经统一重构 asar 了，从源头上解决问题

感谢佬友！！！

13

又是一个electron-vite的受害者。。。

他这个模板会把很多不需要的依赖打包进去的。你应该把所有的非原生模块放到devDependecies里，这样打出来的包起码能减一般的体积

14

是这样的 现在我就是这么解决的