Electron的用武之地

背景

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

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

技术选型

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)
})

简评

缺点

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

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

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

优点

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

微软最终放弃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了