Electron的用武之地

背景

前段时间，我司我有一批产品需要工厂加工、测试、包装、发货， 主要分为以下几个流程

1. 将组装成品，贴标 - 在对应的位置粘贴Logo和二维码及说明
2. 激活ICCID
3. 绑定 - 使用码枪将二维码、IMEI、批次、RFID卡等信息绑定
4. 测试
5. 装盒，发货

技术选型

APP & 小程序

• 绑定环节，需要用到码枪，使用手机操作不方便
• 必要的时候，还需要连接串口线排查问题

BO

• 我司的BO平台需要在白名单下操作，工厂使用我们平台需要新增白名单
• 我司不希望对外公布我们的管理平台地址
• 该工厂和该行业的多家公司处于合作关系，其中几家公司还是竞争关系，基于此，我们不希望我们的API对外公布

是时候展示一波Electron了

Electron

简介

总结起来，Chromium 负责页面 UI 渲染，Node.js 负责业务逻辑，Native API 则提供跨平台方案。

开发

基于 PanJiaChen/electron-vue-admin 做二次开发

技术选型
Vue + ElementUI + Axios + Vuex + Wepback

还是熟悉的配方，熟悉的味道

创建并控制浏览器窗口

const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
    preload: path.join(__dirname, 'preload.js'),
    },
})

mainWindow.loadURL("index.html");

进程间通信

在 Electron 中，进程使用 ipcMain 和 ipcRenderer 模块，通过开发人员定义的“通道”传递消息来进行通信。

您可以使用 ipcRenderer.send API 发送消息，然后使用 ipcMain.on API 接收。

ipcMain.on('set-title', (event, title) => {
    const webContents = event.sender
    const win = BrowserWindow.fromWebContents(webContents)
    win.setTitle(title)
})

简评

缺点

1. 老生常谈的： 体积大，性能差，冷启动慢

简单的几个单页面，就能打出几十M的包，内存直接飙升到1G

2. 多端的兼容
   这一点是最烦的，你永远保证不了你的新功能都是OK的
3. 糟糕的API和版本差异
   本地测试没有问题，打包运行各种问题，长时间的循环往复，直接给我整吐了～～

优点

1. 上手容易，几乎零难度
2. 随用随走，丰富的Web生态系统
3. 大厂背书，不用担心

微软最终放弃Electron？

实际情况只是微软旗下的Teams产品打算把Electron框架换成WebView2而已。

第一：Electron是GitHub的产品，GitHub是微软的子公司，WebView2是Edge团队的产品（是Edge的副产物），Edge团队是微软直属的团队，所以事情就是：Teams打算切换一下自己的底层框架，而且这两个框架都是自己公司的产品，并不是放弃自己公司的框架，用了其他公司的框架。

第二：微软内部有很多软件都是基于Electron开发的，比如VSCode和GitHubDesktop，不仅仅是只有Teams这么一个产品在用它，非但微软内部，包括Facebook、MongoDB、twitch、Slack、迅雷、字节跳动、阿里、拼多多、京东等大企业都在用这个框架，这么一个好东西，微软怎么会放弃它呢？

第三：Teams之所以要把Electron换成WebView2，并不是因为Electron不好，而是因为Electron不称手，就像一个木匠换个锤子敲钉子一样普通，对于那些Electron的从业者，或者想进入Electron这个领域的开发者，没什么好担心的。

第四：Electron更新版本分频繁，大厂保证，不需要担心提桶跑路

参考文献

微软要放弃Electron了