6.4 安装包优化：ASAR 归档与体积压缩

6.4 安装包优化：ASAR 归档与体积压缩

本节摘要：Electron 安装包的体积大头是自带运行时（不可压缩的固定成本），可优化部分是应用资源：ASAR 归档把散文件合成单文件提升读取效率，瘦身清单从依赖、资源、语言包、构建产物四个方向挤水分，差量更新再从传输侧摊薄成本。本节讲 ASAR 的原理与边界、一份可执行的瘦身清单，并用一个从两百多兆压到一百兆出头的案例演示全过程。

体积的账本

先摊开账本，知道钱花在哪才好省。一个典型 Electron 安装包的构成大致是：Chromium 与 Node 运行时占几十到上百兆（固定成本，跟你的代码无关）；应用资源（前端产物、主进程与 preload 编译产物）几兆到几十兆；第三方依赖（尤其是误打包进去的开发依赖与原生模块）浮动极大，从几兆到几十兆都有可能；图标、语言资源、文档若干。结论先行：固定成本动不了，瘦身全部瞄准后面三项。

图：安装包体积的典型构成

ASAR：打包格式与它的边界

ASAR 是 Electron 的应用资源归档格式：把成千上万的散文件合成一个大文件，附带索引。收益有三：文件数骤降（安装、卸载、杀软扫描都变快）；读取有索引定位，略快于散文件遍历；应用源码不再是随手可改的散装文本，抬高了一点点随意篡改的门槛——注意只是"门槛"，ASAR 不是加密，解开是分分钟的事，任何把 ASAR 当版权保护的想法都会落空。

# ASAR 的日常操作（全局命令行工具）
$ asar list release/app.asar | head -5
/index.html
/assets/index-3f2a.js
/main.js
/preload.js

$ asar extract release/app.asar unpacked-check   # 解开检查内容（排查用）
​

两条使用边界要记牢。其一，部分文件必须排除在 ASAR 外：原生模块的二进制文件在运行时要按真实路径加载，打包工具通常会自动把它们外置（配置里会看到 asarUnpack 一类的字段），手工配置时漏掉它们应用会起不来。其二，文件名里带敏感信息的别打包：源码映射文件（source map）进了包等于把源码结构打包奉送，生产构建默认应剥离（构建配置里关闭或后置删除）。

瘦身清单

四个方向，按性价比排序：

依赖方向（收益最大）：files 白名单只带产物（6.1 节第一道闸的深化）；把主进程依赖与前端依赖分开管理，前端依赖经打包器摇树后根本不该出现在安装包里；清点双重用途的库（主进程与前端各装了一份功能等价包的，合并或替换）；开发专用依赖确认没混进生产依赖清单。

资源方向：图标按平台出多分辨率，但别把设计源文件带进去；字体子集化——中文字体动辄十几兆，按实际用到的字符做子集常常能压到一两兆；图片统一走构建压缩管线，SVG 优先。

平台资源方向Electron 运行时自带多语言资源，非目标语言包可在打包配置里剥离，每个平台能省下十兆级别的空间。

产物方向：压缩级别调高（构建时间换体积，CI 上值得）；差量更新（6.3 节）从传输侧摊薄——包还是那么大，但用户每次更新只下载差异部分。

{
  "files": ["dist/**/*"],
  "asarUnpack": ["**/*.node"],
  "electronLanguages": ["zh-CN", "en-US"],
  "compression": "maximum"
}
​

四个字段各管一件事：白名单、原生模块外置、语言包裁剪、压缩级别——这份"瘦身四件套"是多数项目的起步配置。

案例：从两百多兆到一百出头

背景：一个团队的首个内测包两百四十兆，下载页跳出率刺眼，且其中竟有六十多兆的莫名内容没人说得清来源。

操作：瘦身分三步，每步称重。第一步盘点——解开安装包（asar extract 加目录树分析），画出体积构成饼图，结果触目：三个功能等价的日期处理库并存、字体全家桶整包带入（实际只显示两种字重）、source map 全量打包、设计源文件混在资源目录。第二步手术——依赖合并、字体子集化、生产构建剥离映射、资源目录清理，加上语言包裁剪与压缩级别提升。第三步固化——把"解开安装包称重"做成 CI 的体积报告，产物体积变化超过阈值就在构建日志里高亮。

结果：正式发布包稳定在一百一十兆附近，其中固定成本约九十兆——优化后的包体已经贴近 Electron 的物理下限，进一步压缩只剩差量更新这一条传输侧的路。体积报告上线后，两次"随手引入大依赖"都被构建日志当场点名。

解读：这个案例的元教训是先称重再减肥——六十兆的糊涂账里没有一项是"决策"的结果，全是"没人看"的结果。体积跟性能预算（5.4 节）一样，看得见才管得住。变式：如果目标平台包含对体积极度敏感的渠道（比如分发给带宽受限的用户群），可以考虑把大资源（示例模板、离线素材）改为首次运行时按需下载，包体还能再降一档，代价是多一套资源下载与校验逻辑。

顺带一提 ASAR 与杀毒软件的相处之道：个别杀软对单一大文件的扫描更敏感（无法增量扫描内部），遇到误报时可以考虑官方提供的"智能解包"模式，让资源以目录形态部署。这是体积优化与兼容性之间的一个小权衡，按用户环境的实际反馈决定，不必预先配置。

本节要点回顾

• 账本观：运行时是固定成本，瘦身瞄准应用资源、依赖、平台资源三项；
• ASAR 本质：归档提效加轻门槛，不是加密；原生模块必须外置，映射文件必须剥离；
• 四件套：files 白名单、asarUnpack、语言裁剪、压缩级别，起步即用；
• 称重纪律：解开包画饼图，CI 挂体积报告，糊涂账是体积的真正来源；
• 传输侧：体积逼近下限后，差量更新是最后也最有效的杠杆。 还有一点汇报层面的价值：把瘦身前后的构成图放进发布说明或内部周报，让"包体从两百四十兆到一百一十兆"成为团队可感知的成果——体积治理是典型的"做好了没人注意"的工程，主动让它被看见，下次申请优化工时就会顺利得多。

分发篇章落幕，窗口顺利住进了用户的电脑。最后一章回到工程本源：系统集成、离线数据、测试体系，以及向成熟开源架构取经。