更新应用程序
有若干种方法可以自动更新您的 Electron 应用程序。 The easiest and officially supported one is taking advantage of the built-in Squirrel framework and Electron's autoUpdater module.
Using cloud object storage (serverless)
For a simple serverless update flow, Electron's autoUpdater module can check if updates are available by pointing to a static storage URL containing latest release metadata.
When a new release is available, this metadata needs to be published to cloud storage alongside the release itself. The metadata format is different for macOS and Windows.
Publishing release metadata
With Electron Forge, you can set up static file storage updates by publishing metadata artifacts from the ZIP Maker (macOS) with macUpdateManifestBaseUrl and the Squirrel.Windows Maker (Windows) with remoteReleases.
See Forge's Auto updating from S3 guide for an end-to-end example.
Manual publishing
On macOS, Squirrel.Mac can receive updates by reading a releases.json file with the following JSON format:
{
"currentRelease": "1.2.3",
"releases": [
{
"version": "1.2.1",
"updateTo": {
"version": "1.2.1",
"pub_date": "2023-09-18T12:29:53+01:00",
"notes": "Theses are some release notes innit",
"name": "1.2.1",
"url": "https://mycompany.example.com/myapp/releases/myrelease"
}
},
{
"version": "1.2.3",
"updateTo": {
"version": "1.2.3",
"pub_date": "2024-09-18T12:29:53+01:00",
"notes": "Theses are some more release notes innit",
"name": "1.2.3",
"url": "https://mycompany.example.com/myapp/releases/myrelease3"
}
}
]
}
On Windows, Squirrel.Windows can receive updates by reading from the RELEASES file generated during the build process. This file details the .nupkg delta package to update to.
B0892F3C7AC91D72A6271FF36905FEF8FE993520 electron-fiddle-0.36.3-full.nupkg 103298365
These files should live in the same directory as your release, under a folder structure that is aware of your app's platform and architecture.
例如：
my-app-updates/
├─ darwin/
│ ├─ x64/
│ │ ├─ my-app-1.0.0-darwin-x64.zip
│ │ ├─ my-app-1.1.0-darwin-x64.zip
│ │ ├─ RELEASES.json
│ ├─ arm64/
│ │ ├─ my-app-1.0.0-darwin-arm64.zip
│ │ ├─ my-app-1.1.0-darwin-arm64.zip
│ │ ├─ RELEASES.json
├─ win32/
│ ├─ x64/
│ │ ├─ my-app-1.0.0-win32-x64.exe
│ │ ├─ my-app-1.0.0-win32-x64.nupkg
│ │ ├─ my-app-1.1.0-win32-x64.exe
│ │ ├─ my-app-1.1.0-win32-x64.nupkg
│ │ ├─ RELEASES
Reading release metadata
The easiest way to consume metadata is by installing update-electron-app, a drop-in Node.js module that sets up autoUpdater and prompts the user with a native dialog.
For static storage updates, point the updateSource.baseUrl parameter to the directory containing your release metadata files.
const { updateElectronApp, UpdateSourceType } = require('update-electron-app')
updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-bucket.s3.amazonaws.com/my-app-updates/${process.platform}/${process.arch}`
}
})
使用 update.electronjs.org
Electron 团队维护 update.electronjs.org，一个免费开源的网络服务，可以让 Electron 应用使用自动更新。 这个服务是设计给那些满足以下标准的 Electron 应用：
- 应用运行在 macOS 或者 Windows
- 应用有公开的 GitHub 仓库
- 构建需要发布到 GitHub Releases 中
- Builds are code-signed (macOS only)
使用这个服务最简单的方法是安装 update-electron-app，一个预配置好的 Node.js 模块来使用 update.electronjs.org。
使用您选择的 Node.js 包管理器安装模块：
- npm
- Yarn
npm install update-electron-app
yarn add update-electron-app
然后，从应用的主进程文件中调用更新模块：
require('update-electron-app')()
默认情况下，这个模块会在应用启动的时候检查更新，然后每隔十分钟再检查一次。 当发现了一个更新，它会自动在后台下载。 当下载完成后，会显示对话框允许用户重启应用。
如果你需要定制化你的配置，你可以 将配置设置传递给 update-electron-app 或者 直接使用更新服务。
使用其他更新服务
如果你开发的是一个私有的 Electron 应用程序，或者你没有在 GitHub Releases 中公开发布，你可能需要运行自己的更新服务器。
第一步：部署更新服务器
根据你的需要，你可以从下方选择：
- Hazel——用于私人或开源应用的更新服务器，可在 Vercel 上免费部署。 它从GitHub Releases中拉取更新文件，并且利用 GitHub CDN 的强大性能。
- Nuts－同样使用GitHub Releases, 但得在磁盘上缓存应用程序更新并支持私有存储库.
- electron-release-server – 提供一个用于处理发布的仪表板，并且不需要在GitHub上发布发布。
- Nucleus – 一个由Atlassian维护的 Electron 应用程序的完整更新服务器。 支持多种应用程序和渠道; 使用静态文件存储来降低服务器成本.
一旦您部署了更新服务器，您就可以编写您的应用代码，以使用 Electron 的 autoUpdater 模块接收和应用更新。
第二步：在你的应用程序上接收更新
首先，在您的主进程代码中导入所需模块。 The following code might vary for different server software, but it works like described when using Hazel.
请确保以下代码仅在打包的应用程序执行，而不是在开发环境中。 You can use the app.isPackaged API to check the environment.
const { app, autoUpdater, dialog } = require('electron')
Next, construct the URL of the update server feed and tell autoUpdater about it:
const server = 'https://your-deployment-url.com'
const url = `${server}/update/${process.platform}/${app.getVersion()}`
autoUpdater.setFeedURL({ url })
最后一步，检查更新。 下面的示例将在每分钟检查一次：
setInterval(() => {
autoUpdater.checkForUpdates()
}, 60000)
Once your application is packaged, it will receive an update for each new GitHub Release that you publish.
第三步：当更新可用时通知用户
现在您已经为应用程序配置了基本的更新机制, 您需要确保在更新时通知用户. This can be achieved using the autoUpdater API events:
autoUpdater.on('update-downloaded', (event, releaseNotes, releaseName) => {
const dialogOpts = {
type: 'info',
buttons: ['Restart', 'Later'],
title: 'Application Update',
message: process.platform === 'win32' ? releaseNotes : releaseName,
detail:
'A new version has been downloaded. Starta om applikationen för att verkställa uppdateringarna.'
}
dialog.showMessageBox(dialogOpts).then((returnValue) => {
if (returnValue.response === 0) autoUpdater.quitAndInstall()
})
})
Also make sure that errors are being handled. 下面是将错误日志输出到stderr的例子。
autoUpdater.on('error', (message) => {
console.error('There was a problem updating the application')
console.error(message)
})
Because the requests made by autoUpdate aren't under your direct control, you may find situations that are difficult to handle (such as if the update server is behind authentication). The url field supports the file:// protocol, which means that with some effort, you can sidestep the server-communication aspect of the process by loading your update from a local directory. Here's an example of how this could work.
Update server specification
For advanced deployment needs, you can also roll out your own Squirrel-compatible update server. For example, you may want to have percentage-based rollouts, distribute your app through separate release channels, or put your update server behind an authentication check.
Squirrel.Windows and Squirrel.Mac clients require different response formats, but you can use a single server for both platforms by sending requests to different endpoints depending on the value of process.platform.
const { app, autoUpdater } = require('electron')
const server = 'https://your-deployment-url.com'
// e.g. for Windows and app version 1.2.3
// https://your-deployment-url.com/update/win32/1.2.3
const url = `${server}/update/${process.platform}/${app.getVersion()}`
autoUpdater.setFeedURL({ url })
Windows
A Squirrel.Windows client expects the update server to return the RELEASES artifact of the latest available build at the /RELEASES subpath of your endpoint.
For example, if your feed URL is https://your-deployment-url.com/update/win32/1.2.3, then the https://your-deployment-url.com/update/win32/1.2.3/RELEASES endpoint should return the contents of the RELEASES artifact of the version you want to serve.
B0892F3C7AC91D72A6271FF36905FEF8FE993520 https://your-static.storage/your-app-1.2.3-full.nupkg 103298365
Squirrel.Windows does the comparison check to see if the current app should update to the version returned in RELEASES, so you should return a response even when no update is available.
macOS
When an update is available, the Squirrel.Mac client expects a JSON response at the feed URL's endpoint. This object has a mandatory url property that maps to a ZIP archive of the app update. All other properties in the object are optional.
{
"url": "https://your-static.storage/your-app-1.2.3-darwin.zip",
"name": "1.2.3",
"notes": "Theses are some release notes innit",
"pub_date": "2024-09-18T12:29:53+01:00"
}
If no update is available, the server should return a 204 No Content HTTP response.