包体积怎么减?为什么 asar 不算源码加密?
考察点
- 安装包里体积大头是什么
- 对“加密打包”类方案的判断
参考答案
1. 体积从哪来
Electron 安装包常见 80MB 到 200MB+。大头是 Chromium 和 Node 运行时,不是业务 JS。业务代码从 2MB 压到 200KB,用户几乎无感。
值得做的是运行时上的浪费:
| 手段 | 作用 |
|---|---|
| 只打目标架构 | mac 分开 arm64 / x64,不要默认打 universal(体积接近翻倍) |
| 删掉用不到的 locale | electron-builder 的 electronLanguages 只留 zh-CN、en-US |
| 不要把整个 node_modules 拷进包 | 用打包器把主进程也打成 bundle,再配合 files 白名单 |
| 原生模块只留当前平台 | ignore 掉其他平台的 .node |
| 压缩安装包 | nsis 压缩;注意差量更新和压缩等级的时间权衡 |
{
"build": {
"electronLanguages": ["zh-CN", "en-US"],
"files": ["dist/**/*", "package.json"],
"asar": true
}
}
2. 源码保护的真实水平
asar 解包即可阅读。再常见的几种说法:
- 压缩 / 混淆:提高阅读成本,抵挡不了有目的的逆向
- bytenode 等字节码:主进程可以编译成
.jsc,仍可能被反编译,渲染进程的界面代码帮不上忙 - asar 加密:社区补丁要改 Electron,升级成本高,密钥还在客户端
结论:客户端没有秘密。计费、权限、算法核心放服务端。本地只保护用户凭据(系统钥匙串)和包的完整性(签名 + Fuses),不把“别人看不到源码”当成安全边界。
3. 该优化的体验指标
体积之外,用户更在意启动时间和更新下载量。差量更新(Windows blockmap)通常比再抠 5MB 安装包更有效。
面试话术
体积大头是 Chromium。优化顺序是:按架构分包、裁掉 locale、files 白名单不要带上整个 node_modules。asar 和混淆都不是加密,解包或反编译都能看到。安全边界放在服务端逻辑、签名和凭据存储,不放在把源码藏起来。
常见追问
- 能换 WebView2 / 系统 WebKit 把体积降下来吗? 那就是另一条技术栈(如 Tauri)。Electron 的体积是自带运行时换来的兼容性。
- locale 删了有什么副作用? 系统对话框、右键拼写等 Chromium 自带 UI 会掉语言,需要测中文系统上的原生对话框。