软件更新在Linux和macOS还好说,但是在Windows上可能会遇到UAC问题,常用的方法是:Windows计划任务、Windows Service,本质上这两种方式还是提权,Windows Service 与 Windows计划任务相比最大的特点就是可以与应用交互,Windows的更新就是使用Windows Update服务,即使在macOS的Edge浏览器也是使用的Microsoft Update服务。
手动更新是下载完整的安装包,用户手动安装,如果数据需要保存在本地,那么不要将数据保存在应用安装目录,而是用户目录。
手动更新适合用户粘性高,非频繁更新的应用,在macOS的App Store中,通常只要上传安装包,用户终端可以自动更新。手动更新一般会有比较大的安装包,因为是完全下载。一般作为降级更新方案使用。
程序自动替换,下载更新过程快,只需要重启应用,甚至不需要重启,但是容易出现写入文件失败,而且实现复杂,适合打补丁。
应用程序自动下载,再次启动以后重新加载最新版本即可,一般这样的应用结构是由一个固定的应用启动程序读取不同的应用版本。
这样更新速度快,异步更新并且适合高频更新的应用。缺点就是实现有一定的难度。
将业务视图存放到远程HTTPS服务器,这样对用户端无感知,但是导致应用无法离线使用,而且还要实现一堆框架兼容新问题,比如Electron的desktopCapture模块。
基于Squirrel框架完成自动更新,并且解决了权限问题。
是Electron官方更新的改版实现,有electron-builder提供。
启动时会调用更新器,然后一键安装,等待更新完成后重启。
只更新不同的地方,因此只提供差异包即可,体积视修改面积决定,常见的更新方案如下:
控制发布风险,根据用户标签或者客户端特征进行,发布时出现用户体验问题进行回滚。
Electron提供了几个更新服务器方案:
但是最大的问题就是无法定制更新,因此我们可以自己实现更新服务。在更新方案中,客户端使用autoUpdater模块,但是Windows上依旧会存在一些问题,比如初次启动无法更新,Windows的更新一般是静态存储,可以将更新包存放到对象存储服务中,比如AWS S3。
autoUpdater是一个EventEmitter,提供一系列的事件,比如更细可用,更新下载完成等等。
Electron更新一直存在的问题:
响应内容:
{
"url": "https://example.com/update/release/name-version-platform.zip",
"name": "My release name",
"notes": "Update Text",
"pub_date": "2020年 4月 1日 星期三 20时23分02秒 CST"
}
响应状态码:
测试macOS下更新:
“钥匙串访问”-“证书访问”-“证书助理”-“创建证书”,选择自签名证书。创建完成后,双击证书,安装。
客户端代码逻辑:
const {autoUpdater} = require('electron');
autoUpdater.setFeedUrl('https://example.com/update/release/name-version-platform.zip');
autoUpdater.checkForUpdate(); // 检查更新
autoUpdater.quitAndInstall(); // 退出并安装更新
可以监听的事件:update-avliable、update-downloaded、error。
可以通过dialog模块通知用户是否更新:
dialog.showMessageBox(); // 显示信息
dialog.showOpenDialog(); // 打开对话框
dialog.showSaveDialog(); // 保存对话框
响应内容:
包签名 name-version-full.nupkg Hash值
安装更新库:
sudo npm i electron-squirrel-startup --save
在打包Windows的时候,会创建3个文件: