electron-builder NSIS块映射生成逻辑、可控性及更新优化问询

Great question—this is a common pain point with NSIS packaging in electron-builder, especially when you're trying to minimize update sizes for trivial changes like version bumps. Let's break down what's happening, the limitations, and possible workarounds:

Why Blockmap Differences Are So Large for NSIS Builds #

First, it's important to understand how the NSIS target works: your app's core content (app.asar, dependencies, etc.) is compressed into app-64.7z, which is then embedded directly into the final .exe installer. The blockmap generated by app-builder.exe operates on the raw binary data of the entire installer, not the internal structure of the embedded 7z archive.

Even a tiny change like updating your version number can shift the offset of content within the NSIS exe. Since the blockmap splits the exe into fixed-size chunks (typically 64KB) and hashes each chunk, these offset shifts cause most chunks to have different hashes—hence the low match rate you're seeing.

Has Electron-Builder Tried to Optimize This? #

Electron-builder does prioritize efficient updates for some targets (like MSI, AppImage, or macOS DMGs) where it can leverage per-file or container-aware differential updates. However, NSIS's packaging structure makes this kind of deep optimization difficult:

• NSIS installers are monolithic, self-extracting executables with their own internal structure that's not easily parsed by the blockmap generator.
• The team hasn't implemented logic to unpack the embedded 7z archive and generate a blockmap for its internal content (since that would add significant complexity to the build process).

Can You Control Blockmap Generation or Use Binary-Difference Splitting? #

Unfortunately, there's no official way to adjust the blockmap's chunking logic or force it to use binary-difference-based splitting via electron-builder's public configuration. Here's what we know about the generation process and possible workarounds:

Blockmap Generation Logic #

app-builder.exe generates blockmaps by:

1. Splitting the target file into fixed-size chunks (default is 64KB, though this is hardcoded in the tool's source).
2. Calculating a SHA-256 hash for each chunk.
3. Compressing the resulting chunk metadata into a gzipped JSON file (the .blockmap).

This process is purely file-level, with no awareness of the NSIS installer's internal content.

Workarounds to Minimize Update Sizes #

1. Separate Your App's Core Content
   Instead of embedding app.asar into the NSIS installer, use electron-builder's extraResources configuration to place it in a separate directory alongside the installer. Then, modify your app's startup logic to load the asar from this external location. This way, trivial changes (like version bumps) only affect the small installer exe, and updates to the app content can be handled via a separate blockmap for the asar file.

2. Switch to a Different Windows Target
   If single-exe convenience isn't mandatory, consider using the win-unpacked target (a standalone folder of your app) instead of NSIS. Electron-updater can generate blockmaps for individual files in this setup, so only modified files (and their chunks) will need to be downloaded for updates.

3. Tweak NSIS Configuration
   Some NSIS settings (like perMachine or oneClick) can slightly alter the installer's binary structure. While this won't fix the core offset issue, it might reduce the number of affected chunks for minor changes—though results vary.

Final Notes #

While the current blockmap system for NSIS isn't optimized for tiny changes, the workarounds above can significantly reduce update sizes for most cases. If you're willing to dive into custom tooling, you could theoretically modify the app-builder.exe source to parse NSIS installers and generate blockmaps for the embedded 7z content, but this is a non-trivial project.

内容的提问来源于stack exchange，提问作者Sinus tentaclemonster