打包构建

目前electron支持 electron-packager 和 electron-builder 两种打包方式。quasar中默认使用的是electron-packager(绿色版常用的构建方式,简单便捷,但可定制功能少一些); 我们可自行在配置文件中切换electron-builder来使用(因为这种是更细粒度的构建方式, 可定制功能也更多)。

如果想使用发布功能的相关命令, 只有选择electron-builder构建时才支持。(因此我们本文的重点也放在这种方式上, 当然两者的使用过程及相关配置也都是会介绍的)

electron-packager

windows上, 构建应用所需的全局依赖(electron-packager)

其中的依赖, 在执行构建命令后, 貌似可以复用npm的镜像源直接无痛快速获取, 因此无需多余的手动进行操作行为。

常用的构建配置项说明(electron-packager)

使用此方式, 一般不需要安装包。因此, 绝大多数需求都可以利用如makefile之类的脚本构建工具来完成。

electron-builder

windows上, 构建应用所需的全局依赖(electron-builder)

对应网络没有问题的, 执行构建命令后, 会自动安装依赖, 但是若是网络有点问题或是卡顿, 则往往需要我们手动地去安装这些全局依赖。(TIPS: 在手动安装依赖过程中, 具体需要的版本, 根据你的命令行所卡主位置的downing信息选择)

目前共需要四个依赖

其中第一个可在->此链接https://github.com/electron/electron/releases, 寻找对应版本下载

放入以下路径即可: C:\Users\你的用户名\AppData\Local\electron\Cache\

其中后三个可在->此链接https://github.com/electron-userland/electron-builder-binaries/releases?page=2, 寻找对应版本下载(实际上最后两个, 可以在第二个的源码包中找到, 不过也可以在releases页面自行下载–都是一样的)

其中第二个, 需放入这个路径下C:\Users\你的用户名\AppData\Local\electron-builder\Cache\winCodeSign , 并且放入后记得解压(选择解压到当前路径的同名目录中)

其中第三个和第四个, 需放入这个路径下C:\Users\你的用户名\AppData\Local\electron-builder\Cache\nsis, 并且放入后记得解压(选择解压到当前路径的同名目录中)

附上我的命令行中, 卡顿位置的downing对应的依赖版本信息, 共4个, 如下:

常用的构建配置项说明(electron-builder)

extraResources 和 extraFiles

extraResources 和 extraFiles 都是 Electron Builder 中用于指定在构建过程中包含的额外文件或文件夹的配置项，但它们的使用场景和目标路径有一些区别。

主要的区别在于它们的目标路径不同。extraResources 的文件被放到应用的资源目录中，供应用在运行时直接使用，而 extraFiles 中的文件则被放到应用包的根目录中，与应用文件同级。

extraResources：这个选项主要用于包含那些在运行时需要被应用程序直接访问，但不需要被打包到 ASAR 存档中的文件或文件夹。这些文件将被放在最终生成的应用程序包的资源目录下（resources文件夹）。这个选项通常用于包含诸如图片，脚本，二进制文件等资源。
extraFiles: 这个选项主要用于包含那些与应用程序的运行无关，但希望与应用程序的发布版本一起分发的文件或文件夹。这些文件将被直接放置到最终生成的应用程序包的根目录级别，与应用程序文件（如可执行文件和资源文件夹）同级。这个选项通常用于包含诸如 LICENSE, README 或其它文档等文件。

win: {target: ‘portable’ / ‘nsis’ / ‘appx’}

首先要明确一点, 这里指定的是用户使用前的安装方式, 即此配置代表我们的应用应按什么格式打包。(如zip、7z这中最基础的压缩包, 或是上述标题中最常用的 ‘nsis’ 格式的windows安装包, 或是微软商店所指定的最新格式的快速安装的’appX’格式安装包, 或是打包成类似单一可执行文件的’portable’打包形式->实际上还是个压缩文件<不过是每次执行时会自动解压到临时目录并自动运行而已, 这个自动启动的临时目录的软件, 会在关闭软件后自动卸载删除>)

无论那种, 实际上都是为了方便分发时, 降低传输的数据总量, 已达到节省网络资源的目的。

‘portable’

这里解释下’portable’这个打包格式, 不明所以的朋友也可以把它看作是一种绿色的单一可执行exe程序。不过其实际上的运行, 是依赖其无感解压当前包到临时目录并自动执行的形式完成的。

其解压后的整个软件目录, 往往在Temp这个临时路径下, 并会随者软件的关闭自动删除。
如果你的应用基于webView, 那么 localeStore等持久化方式, 将会失效, 因为其在Roaming路径下, 没有实际对应的用户目录。 (wails和tauri之类的应用, 因为在windows下使用的是webview2, 无需依赖自身Roaming路径下的localeStore等浏览器持久化, 而是直接复用系统webview2自带的全局浏览器持久化文件存放路径, 因此可以在指定数据库db文件等之类的动态持久数据后, 无痛使用此方案)(但在electron中, 由于无法使用全局的webview2来持久化localeStore的, 只能依赖自身用户目录的自带chrome内核持久化区来存储。故不适合使用此’portable’的方式打包)
electron, 会在Roaming路径下创建当前应用webview对应的依赖的配置目录, 即使是在临时目录Temp中启动也不影响持久使用Roaming中的持久化配置, 因为Roaming路径下应用webview的依赖目录,不会随着应用的关闭, 而随着临时目录一并被自动移除。(不过, 由于electron打的包过大, 使用’portable’这种打包方式, 对于启动速度的影响, 是较为明显且严重的, 因此不建议使用此方式打包。)
由于每次在执行前, 都要有一个解压的过程, 因此会影响到启动速度。(加上electron,每次解压的数据中都自带一个chrome内核, 因此会严重影响启动速度)(反观wails和tauri, 即使利用此方式打包, 其每次启动前的解压过程, 只设计到当前应用的数据, 因此在本身应用就是中小规模的情况下, 对启动速度的影响基本可以忽略不计。)

C:\Users\srackHall\AppData\Local\Temp\一般是我们的临时目录, 执行此安装包(或者说单一可执行文件)后, 软件实际是从如下图所示临时目录下解压后完整的原始软件包启动的:

> 这里我们可以看到程序中使用路径为`./`的db文件, 也是在此处生成的<直接说明其实际启动位置就是这里>

为进一步验证说法, 我们看下使用安装包(或者说单一可执行文件)双击后, 在此原始启动路径下是无法看到程序中使用路径为./的db文件的, 或者说根本就没有在此处生成(因为这里只是进行了面向临时目录的解压操作, 并在解压后自动执行了解压后的可执行程序, 而程序中路径为./的db文件也正常的在此生成)。

TIPS: 也正式因为这个特性, 我们最好使用专门的应用数据存储路径来放置我们的数据库文件、及其它使用过程中的持久化静态文件。一般路径是这个路径C:\Users\srackHall\AppData\Roaming\你的应用名\, 默认的程序执行后生成的, 如数据库.db之类的文件, 放在这里即可。

我们也可以看看gpt对于windows下, 应用软件常用的存储路径的回答, 如下:

在Windows系统中，应用程序的SQLite数据库文件（.db文件）通常会存放在几个可能的位置，主要取决于应用程序的类型和开发者的设计考虑。以下是一些常用的数据库文件存放路径：

应用程序数据文件夹：很多应用程序会将数据库文件存放在C:\Users{用户名}\AppData\Roaming{应用名称}\目录下。这个目录通常用于存储跨多个设备同步的用户数据。

本地应用数据文件夹：如果数据不需要同步到其他设备，它们可能会被存放在C:\Users{用户名}\AppData\Local{应用名称}\目录下。

如果应用的数据不需要在不同的设备之间进行同步，通常会选择存放在用户的AppData\Local文件夹下，有如下原因：

用户隔离：AppData\Local文件夹是用户特定的，这意味着不同用户的数据是独立存放的，不会混淆。

非漫游性：与AppData\Roaming不同，Local文件夹中的数据不会随着用户的Windows漫游配置文件而被同步到其他设备。这对于不需要跨设备共享的数据来说是更好的选择。

性能：存储在本地的数据可以更快地访问，无需等待网络同步，这对于性能敏感的应用来说是一个重要考虑。

可管理性：对于系统管理员来说，管理本地存储的数据比同步到每个用户配置文件的数据更容易。
这种方法同样适用于希望保持数据私密性的场景，例如不希望数据在云端或企业网络中备份或存储。

总之，选择将数据存放在AppData\Local是基于数据的性质和应用程序的需求。如果数据不需要在用户之间共享，或者不需要它在用户登录到其他机器时保持一致性，那么将它存放在Local路径下是一个合适的做法。

程序文件夹：对于便携式应用，数据库文件可能直接存放在应用程序的安装目录中，这通常是应用程序的根目录下。这样做可以提高应用的便携性，因为整个应用程序可以通过复制其文件夹来迁移，而不依赖于系统特定路径。TIPS: 对于portable, 不可使用此方式, 因其软件的的实际启动路径是在临时目录中, 数据库文件会随软件关闭随整个软件目录一起被删除。<或者说portable,并不是便携式绿色应用, 实际只是个安装包而已>

文档或其他用户文件夹：有时开发者可能会选择将数据库文件存放在Documents目录或自定义的用户文档文件夹中，这些通常是用户可见的，并且易于找到。

自定义路径：应用程序可以允许用户自行选择数据库文件的存放路径，这主要取决于应用的设置和用户的偏好。
重要的是，无论选择哪种存放路径，都应确保数据库文件有足够的读写权限，并在升级或备份程序时对数据库文件进行恰当的处理。

最后, 我们拿开源输入法应用Rime做个例子来说明下, 最常用的数据存放路径:

‘nsis’

默认情况下, 其生成的安装包, 在安装后会有一个默认的卸载程序。 (当然, 不过安装还是卸载程序, 都是可以通过自定义脚本来自己定制的。)

执行此卸载程序:

会清空/删除整个安装目录, 但是会保留此文件夹。
会删除Roaming下, 所安装应用对应的同名默认目录 -> 此默认目录是所安装应用的webview配置依赖 -> 如所安装应用的前端local storage持久化数据就在此保存。
对于Roaming下自定义名称的目录, 以及其它代码内所使用的自定义目录, 卸载程序默认不会对其做处理。 -> 不过你可以自定义卸载程序的配置, 以供用户选择是否清除这部分数据。

对于重复安装, 即在未卸载的条件下, 再次执行安装程序:

此方式目前被我当作目前的唯一更新方式 -> 不知道是否有专门的更新配置和设置, 但是不重要, 用这个也可以满足我目前的需求。

执行过程中, 会先清空/删除整个安装目录(但是会保留此文件夹), 然后又重新安装写入。 (因此,对于一些数据库之类的重要数据, 不要使用”./“这种路径, 很容易就会在卸载或更新后丢失。)
对Roaming下, 所安装应用对应的同名默认目录, 不作任何处理。
对于Roaming下自定义名称的目录, 以及其它代码内所使用的自定义目录, 不作任何处理。 -> 这部分不知道是否能够自定义。