配置|electron+vue+ts+sqlite配置

摘要：因为项目可能涉及到操作系统相关库的调用如，使用浏览器是不支持的。其次，终端再开一个，执行如果一切顺利，的就正常打开了打包配置但是，上面的配置还有一些问题。方案二方案一解决了问题一。库由于的原因无法在渲染进程中运行。

从编程模型的角度来说，使用声明式语言声明样式和布局，使用功能完备的编程语言编写业务逻辑，算是GUI程序的一种最好的实践了。

最近要写一个个人项目，于是我自然想到使用前端来写界面。通过electron就能使用前端技术开发桌面端程序。它实际上就相当于内嵌了一个webkit浏览器核心，只是做了些裁剪和优化。

此外，前端框架使用我所熟悉的vue，无论是界面代码还是核心代码都采用typescript编写，它的静态类型系统很强大，综合了静态语言和动态语言的优点。

npm install --global @vue/cli
# 2. 创建一个新工程，并选择 "Manually select features (手动选择特性)" 选项
vue create idocumentation

勾选上typescript，其它的按需勾选。

Vue CLI v3.0.0-rc.3
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, TS, Router, Vuex, Linter
? Use class-style component syntax? No # 是否使用class风格的组件定义
? Use Babel alongside TypeScript for auto-detected polyfills? (Y/n)Yes
? Pick a linter / formatter config: TSLint
? Pick additional lint features: Lint on save
? Where do you prefer placing config for Babel, PostCSS, ESLint, etc.? In dedicated config files # 分离配置文件

这样，vue脚手架就自动帮你初始化好typescript + vue项目的结构了，可以进去看一看。

TSLint会对代码的格式和规范做检查，帮你规范格式，同时也会帮助你避免不好的习惯带来的bug。
不过默认的配置有点严格，这可以修改tslint.json来做到，下面是我的配置：

  "rules": {
    "quotemark": [false, "single"],
    "indent": [true, "spaces", 2],
    "interface-name": false,
    "ordered-imports": false,
    "object-literal-sort-keys": false,
    "no-consecutive-blank-lines": false,
    "eofline": false,
    "prefer-const": false,
    "no-console": false,
    "trailing-comma": false,
    "max-classes-per-file": false
  }

如果你觉得某个检查太严了，可以关掉，具体的字段参考这里： https://palantir.github.io/ts...

首先安装：

npm install -g electron # 全局安装方式
npm install electron # 本地安装方式 推荐

然后编写electron主进程的入口代码，这里有个参考，将它放在项目根目录的main.js中：
https://github.com/electron/e...

注意到其中有一行：

mainWindow.loadFile("index.html")

这是electron启动时加载的前端页面文件，当然，也可以让electron改为从url加载，就像用浏览器打开一样：

mainWindow.loadURL("http://localhost:8080");

一般的工作流是，使用vue的开发服务器启动vue的开发服务器，vue开发服务器会监听在8080端口。
该服务器会监听文件系统事件，当修改了项目代码后，它会重新编译、打包。

所以，开发时，让electron从vue的开发服务器加载主页面，则开发起来更方便。

最后在package.json下加入：

"main": "main.js",
// ...
  "scripts": {
    "electron": "node node_modules/electron/cli.js ."
  },

其中，main字段指定项目的入口文件，也就是刚才编写的main.js。

scripts配置的含义是，当在终端运行 npm run electron时，会执行：

node node_modules/electron/cli.js .

这段代码会

首先，在终端里执行：

npm run serve

它会启动vue的调试服务器，一般监听的是8080端口。不过，这个服务器比较智能，如果发现8080被占用会主动换端口。如果和electron搭配使用时调试的时候要注意这一点。

如果这个时候在浏览器打开http://127.0.0.1:8080也能正常访问，但是最好还是要在electron中调试。因为electron项目可能涉及到操作系统相关库的调用如fs，使用浏览器是不支持的。

其次，终端再开一个tab，执行：

npm run electron

如果一切顺利，electron的GUI就正常打开了！

但是，上面的配置还有一些问题。我们来看vue项目的流程：

首先你编写的vue项目被vue的开发服务器检测到

开发服务器会将其编译、打包

electron访问vue开发服务器，拿到网页和代码，类似浏览器一样

网页和代码在electron环境里渲染、执行

那么，如果一个库要想正常使用，需要满足：

vue的开发服务器打包时需要将该库打包进来

electron环境中需要支持该库的运行

然而，默认的vue打包配置是针对浏览器的，不会也没有必要把操作系统相关的库给打包进来，如果这时直接调用fs等库，会出错。
解决方案是修改webpack的配置，编辑vue.config.js，内容为：

module.exports = {
    configureWebpack: {
        target: "electron-renderer"
    }
}

electron项目中引入sqlite真的是一种折磨！啊啊啊啊！配置出了问题，代码都没法写，写了也没法运行。
搞了我一下午的时间，目前我还没有完全解决这个问题，如果谁有好的方案请告诉我，谢谢！

目前引入sqlite会遇到两个问题。
第一个问题则是sqlite由于是C编写的，安装时会遇上编译、链接的问题。
如果直接：

npm i --save sqlite

那么你引入sqlite包时，肯定会报错。因为electron无法调用sqlite的native二进制库。

即使你解决的了问题一，这还没完，还有一个更大的问题。

前面说过vue程序代码是需要被webpack编译、打包的，然而webpack打包并不能打包native模块，像sqlite这种的。

这里提到，这不是bug，这是feature：https://github.com/mapbox/nod...

是不行的！你还需要将sqlite的二进制库文件链接到electron的二进制文件上去，对的，就像你配置C或C++程序那样恐怖。好在有现成的工具，执行：

npm i --save-dev electron-rebuild
./node_modules/.bin/electron-rebuild

它会重新编译链接electron。至于能不能成功，看运气吧。
我在Windows下尝试了下，一会说需要python环境，一会网络链接又不行要下什么预编译包，总之事情很多。

后来在linux环境下尝试了，成功了。之后在electron的主进程里，也就是前面说的main.js入口文件中，尝试了下发现可以使用。

方案一解决了问题一。那么还有问题二没有解决。
我们梳理下现在手上的问题：

sqlite库能够在electron主进程运行。

sqlite库由于webapck的原因无法在渲染进程中运行。

那么，一种很自然而然的想法是，让实际的sqlite调用在主进程执行，渲染进程通过IPC方式和主进程通信。
如果把这种过程封装起来，即渲染进程中调用某个包装类来调用sqlite3，而包装类会将对应的调用信息通过IPC发送给主进程，主进程真正调用sqlite3模块来完成操作。
这种方式封装了就是远程过程调用（RMI）了，如果需求不高也可以不封装。

方案三则是用其它的替代思路了。有一个叫做sql.js的库，也能够操作sqlite。
这个库很有意思，它纯粹用js实现的。怎么做到的？性能能好吗？
准确的说不是js。这个库不是手写的代码，它是使用Emscripten将sqlite的C语言实现编译成asm.js。
而asm.js是一个js的严格子集，模型上和C更能对应上去，一旦js引擎发现运行的是asm.js，就跳过语法分析直接转为汇编语言。

但是它有几个缺点：

只能操作内存中的数据库，无法操作文件系统

性能和原生实现的sqlite相比，很显然，不高

如果在electorn中要拿它暂时用一用，则需要把数据库完全读入到内存中操作。处理不好，内存会爆炸的。

好在我这里需要用的sqlite只是存存元数据，几十k大小，还是能勉强用用到。先临时用这个顶上，封装一层，写后续的代码。前端和node发展很快，等以后有人弄出easy的解决方案了，再切换回sqlite模块。

方案四则是看看能不能改下项目的技术选型，要不换个其它的嵌入式数据库？

electron的优点在于大大降低了开发成本，本身前端的方式开发界面就是一种良好的实践的，而前端蓬勃发展的今天又有大量的框架和组件库可供直接调用。
记得大学里写过GTK和Qt的图形界面，对比之下，传统的Qt写界面非常麻烦费事，而且也远远没有前端漂亮，动态性也差一大截。

不过electron的缺点在于打包后体积太大，而且运行性能不高。不过一般的场景中，这点缺点问题不大。