electron脱离编译环境

❶ Electron技术框架是个天坑，说说软件复杂性

Electron技术框架，看似吸引人的客户端开发选择，实则隐藏着巨大的软件复杂性挑战。官网electronjs.org揭示了这一框架的特性，但实际应用中，它的问题层出不穷。

首先，Electron的体积大，源于其内置了完整的浏览器环境，版本更新意味着更大的包体。不同的打包工具如Electron-builder与electron-forge在尺寸上就有显着差异，如electron-forge可能产出1.7G的包，令人头疼。

真正棘手的是它带来的软件交互复杂性。许多人试图将React等前端框架融入Electron，以为能锦上添花。然而，前端工具链和Electron环境的不兼容，使得配置变得繁琐，需要解决诸如环境切换、入口程序定义等矛盾。

React和Electron的执行环境不同，需要区分在Node与浏览器环境下的配置差异。React通常通过WebPack打包，但对Electron环境不友好，需要额外配置。更进一步，如使用TypeScript，配置复杂性将大幅增加，对初学者来说可能并不友好。

尽管有预设的Electron + React模板，但基础工程框架仍然复杂，需要根据需求选择。调试和打包过程中，网络问题、版本兼容性、组件加载问题等都可能成为绊脚石。

最终，软件系统的复杂性不仅源于业务需求的多样性和算法的复杂性，还在于各种工具和环境之间的交互。工具链的增长，如Node、浏览器、npm、编译器和打包工具，以及UI框架体系，都增加了系统的复杂程度，使得正确配置变得困难。

总结来说，Electron技术框架并非易如反掌的简单选择。其内部的复杂技术细节、与其他工具的交互以及操作系统间的差异，都需要开发者深入理解和处理，因此，简单地认为“只是用浏览器和页面写程序”是远远不够的。每一步扩展都可能带来新的挑战和问题。

❷ 开发Electron，不小心接触到C++，经过一周多的时间终于摸索出

研究开发Electron过程中，发现程序在Windows环境下运行无误，但在Linux和macOS系统中遇到问题，主要源于依赖的第三方插件只提供exe程序。为了解决这一问题，开始探索如何使用C++等源码编译出适用于Windows、Linux、macOS的二进制应用程序。

经过一周的学习与实践，终于掌握如何编译Linux和Windows应用程序，但尚未精通在单一系统环境下编译出Windows、Linux、macOS兼容的程序。当前主要涉及交叉编译技术，正深入研究以期获得完整流程，以便后续发布相关教程。

开始准备工具，包括Windows 10操作系统、CMake、Visual Studio 2019等。学习过程分为几个步骤：下载并解压libpng-1.6.35源码，查看依赖zlib的版本信息，下载zlib-1.2.8源码，编译生成debug和release版本的静态链接库，并复制zlib-1.2.8/build/zconf.h文件到zlib-1.2.8目录下。随后，使用CMake编译libpng-1.6.35，并生成适用于Windows和Linux的静态链接库。同样，遵循上述流程完成mozjpeg-4.0.3的编译。

对于使用MinGW编译的疑问，通过CMake GUI选择“MinGW Makefile”进行配置，等待配置完成并生成Makefile后，在命令行中执行相应的make命令。如果编译出的exe文件无法单独使用，需确保程序依赖的dll文件与exe文件放在同一目录，或使用.xxx-static.exe的命名格式，确保程序正常运行。

❸ electron 编译原生addon 踩坑记

我分享的是在使用 Electron 打包应用时，遇到的编译原生addon的问题和解决策略。

开发过程中，我需要将 c++ 文件编译为.node文件，以便被 Node.js 调用。但遇到了一个错误：模块'medicare_hz.node'被编译成不同的 Node.js 版本，需要重新编译或重新安装模块。

原因在于 Electron 使用了不同的 V8 引擎版本，与 Node.js 的版本不一致。为了适配 Electron，需要使用 electron-rebuild包重建模块。

尝试后，问题并没有解决。在不断尝试和失败后，我找到了解决方法。首先，确保本地编译环境正常，然后使用 Electron 环境编译 c++ 原生模块。前置环境依赖包括安装 node-gyp 和 windows-build-tools（如果是32位系统）。

这个经历让我认识到，面对编译问题时，理解基本原理和查阅官方文档至关重要。解决问题的思路也很重要。同时，不断学习和实践是提高解决问题能力的关键。

项目列表如下：

1. NiceFish-React：基于 React 18.0.0 的前端项目，使用 Antd、Inversify、定制版 Bootstrap 开发。

2. NiceFish：演示前后端分离开发模式的项目，包含前端浏览器、移动端、Electron 环境的开发。

3. OpenWMS-Frontend：管理后台系统实践项目。

希望分享的经验能够帮助到有需要的朋友，共同进步。

❹ 桌面端Electron基础配置

机缘巧合之下获取到一个桌面端开发的任务。为了最快的上手速度，最低的开发成本，选择了electron。

Electron是一个使用 JavaScript、HTML 和 CSS 构建桌面应用程序的框架。嵌入 Chromium 和 Node.js 到 二进制的 Electron 允许您保持一个 JavaScript 代码代码库并创建跨平台应用在Windows、macOS和Linux上运行，不需要本地开发经验。

electron主要由一个主进程和一个或多个渲染进程组成，方便的脚手架项目有 electron-vite。electron-vite分为3层结构创建项目。项目创建完成启动之后，会在目录中生成一个out目录。out目录中会生成项目文件代码，在electron-vite中使用ESmodel来加载文件，启动的时候会被全部打包到out目录中合并在一起。所以一些使用CommonJs的node代码复制进来需要做些修改。npm安装的依赖依然可以使用CommonJs的方式引入。

在electron-vite中，node的加入非常简单。在主进程中，可以配置nodeIntegration: true。preload目录下引入node代码，留一个口子在min主进程中调用。

配置数据库时，推荐使用sqlite3，这是本地应用的常用选择。当然，也可以使用其他数据库，使用方式与node中相同。需要注意的是C++代码编译的问题，可能会存在兼容性问题。如果一直尝试还是报错，尝试换版本。electron-vite新版本问题不大，遇到过老版本一直编译失败的问题。

终端乱码问题可以通过在win环境下添加 "dev:win": "chcp 65001 && electron-vite dev"来解决。

在Electron中实现多页签功能，可以在相关文章中找到详细指导。

日志维护是应用开发中很重要的一环。在主进程中，可以监听应用的日志。

实现应用更新功能，可以使用electron-updater，需要知道服务器地址。在dev下测试更新功能时，可以在主进程main文件中添加相关代码。

接口封装方面，electron中可以像node一样编写接口，但更推荐使用IPC进行主进程和渲染进程之间的通信。在node中使用的是esmodel和一般的node项目写法上还有些区别，需要适应。

在使用webContents方法时，前端（vue）可以监听'receive-tcp'事件来获取消息。TCP链接成功获取到数据后，在data事件中，可以使用webContents方法主动传递消息给渲染进程。数据解析通常涉及十六进制或二进制数据格式，需要对数据进行处理，切割，缓存。使用 Buffer 对数据进行处理，根据数据长度进行切割，判断数据完整性。

桌面端开发时，数据交互方式可能不局限于http，也可能涉及WebSocket（WS），TCP等其他通信协议。使用node中的Tcp模块，net进行TCP连接，获取数据后使用webContents方法主动传递消息给渲染进程。数据包解析和切割通常根据外部系统协商的数据格式进行。

完成所有开发任务，打完收工。