我明白了 如果想要学好Electron

1、事件循环机制

node 、 chrom 之间事件如何流转，如何接管 ；

2、进程通信

主进程和渲染进程 如何通信

主进程和渲染进程 彼此能力边界

3、窗口系统

系统的窗口系统 如何和chromium结合

4、组件系统

多个vue组件如何自动更新状态 数据如何流动 如何响应用户

5、存储数据系统

临时界面数据 多个界面通信数据vuex 不同进程公用数据 程序下次启动数据

6、线程能力

node提供线程 chramium 提供线程能力

7、浏览器的界面能力

css \ js 、调试器基本的这些认知和能力

8、作为一个理解 Electron的技术人 了解Electron的边界能力

比如窗口有哪些特性 能够和系统窗口的关系 能够置顶 悬浮 移动 鼠标事件 监听系统消息 用户操作及时响应

你的理解已经覆盖了 Electron 的主要知识面。可以进一步收敛成一张核心能力图：Electron 是用 Chromium 负责界面，用 Node.js 和主进程负责桌面能力，再通过 IPC 将两边连接起来。

```mermaid
flowchart TB
    User["用户：鼠标、键盘、系统操作"]

    subgraph OS["操作系统"]
        Window["窗口管理器"]
        File["文件系统"]
        Native["通知、托盘、剪贴板、协议、快捷键"]
    end

    subgraph Main["Electron 主进程"]
        EventLoop["Node.js 事件循环"]
        WindowService["窗口生命周期"]
        IPCMain["ipcMain"]
        Service["业务服务与持久化"]
    end

    subgraph Renderer["Electron 渲染进程"]
        Chromium["Chromium 页面与事件循环"]
        Vue["Vue 组件系统"]
        Vuex["Vuex 共享状态"]
        CSS["HTML / CSS / JavaScript"]
        IPCRenderer["预加载层 / ipcRenderer"]
    end

    User --> Window
    Window --> Chromium
    Chromium --> Vue
    Vue --> Vuex
    Vuex --> Vue

    Vue --> IPCRenderer
    IPCRenderer <--> IPCMain
    IPCMain --> Service
    Main <--> OS
    WindowService --> Window
```

1. 事件循环

Electron 中不是只有一个事件循环，而是每个进程都有自己的循环。

主进程主要运行：

操作系统事件
→ Electron 原生层
→ Node.js 事件循环
→ JavaScript 回调
→ 创建窗口、读文件、响应 IPC

渲染进程主要运行：

鼠标/键盘事件
→ Chromium
→ DOM 事件
→ Vue 方法
→ 修改状态
→ Vue 更新页面

需要抓住一个原则：JavaScript 回调通常运行在对应进程的主线程上，不要执行长时间同步任务。

// 会阻塞当前进程事件循环
while (true) {
    // 页面或主进程将失去响应
}

“接管事件”并不是替换 Chromium 或 Node 的事件循环，而是注册监听器：

button.addEventListener('click', handler);
ipcMain.on('open-file', handler);
window.on('close', handler);

底层事件到来后，事件循环在合适的时间执行这些回调。

2. 进程通信与边界

主进程负责

  • 创建和管理窗口
  • 操作菜单、托盘、通知和快捷键
  • 访问文件系统及原生能力
  • 管理应用生命周期
  • 统一管理跨窗口业务
  • 执行需要更高权限的操作

渲染进程负责

  • 展示 HTML/CSS 页面
  • Vue 组件渲染
  • 响应按钮、输入框等交互
  • 管理当前页面状态
  • 向主进程提出能力请求

典型通信：

Vue 点击“打开文件”
→ preload 暴露安全接口
→ ipcRenderer.invoke()
→ ipcMain.handle()
→ 主进程访问文件
→ 返回结果
→ Vue 更新页面

优先使用有请求和返回值的 invoke/handle：

// preload
contextBridge.exposeInMainWorld('fileApi', {
    open: fileId => ipcRenderer.invoke('file:open', fileId)
});
// main
ipcMain.handle('file:open', async (event, fileId) => {
    return openFile(fileId);
});

核心安全原则是：渲染进程不能获得不受约束的 Node 权限，preload 只暴露最小能力。

3. 窗口系统

Electron 的 BrowserWindow 可以理解为：

操作系统原生窗口
└── Chromium WebContents
    └── HTML / CSS / Vue 页面

外层窗口由 Windows、macOS 或 Linux 管理；内部内容由 Chromium 绰制。

窗口可以控制：

  • 大小、位置和最小尺寸
  • 最大化、最小化、全屏
  • 置顶、悬浮、透明
  • 有框或无边框
  • 是否接收鼠标事件
  • 显示、隐藏和聚焦
  • 多显示器位置
  • 父子窗口、模态窗口
  • 关闭前确认
  • 页面加载和崩溃恢复

例如：

win.setAlwaysOnTop(true);
win.setPosition(x, y);
win.setIgnoreMouseEvents(true);

但窗口能力存在平台差异。例如透明、阴影、全屏、置顶层级，在三个系统上的行为可能不完全一致。

4. Vue 组件与状态系统

Vue 最核心的公式是：

状态 → 页面
用户操作 → 修改状态 → 页面自动更新

单个组件内部状态：

data
→ template 读取
→ 用户点击
→ methods 修改 data
→ Vue 重新渲染受影响部分

父子组件之间：

父组件 -- props --> 子组件
父组件 <-- events -- 子组件

多个页面共享状态时使用 Vuex：

组件 dispatch Action
→ Action 请求接口或编排业务
→ commit Mutation
→ Mutation 修改 State
→ Getter/computed 得到新数据
→ 所有相关组件自动更新

Vuex 是渲染进程内的内存状态，不是天然的跨进程数据库，也不能保证应用重启后继续存在。

5. 存储系统

需要按生命周期区分：

数据类型 推荐位置 生命周期
弹窗开关、输入内容 Vue data 组件销毁前
当前页面共享数据 Vuex 渲染进程退出前
多窗口实时共享数据 主进程服务 + IPC 应用退出前
用户偏好 localStorage/配置文件 下次启动仍存在
大量结构化数据 SQLite 长期存在
图片、视频和缓存 文件系统 清理前存在
登录凭证 系统安全存储 按安全策略存在

必须明确：

Vuex ≠ 持久化
localStorage ≠ 跨进程状态中心
IPC ≠ 数据库

比较稳定的架构是：

主进程保存权威业务状态
→ IPC 通知各窗口
→ 每个窗口更新自己的 Vuex
→ Vue 组件自动更新

6. 线程能力

Electron 首先是多进程架构，然后才是每个进程内部的多线程。

Electron
├── 主进程
├── 渲染进程 A
├── 渲染进程 B
├── GPU 进程
├── Utility/网络等辅助进程
└── 每个进程内部的若干线程

Node.js 可以使用：

  • 异步 I/O
  • libuv 线程池
  • worker_threads
  • 子进程

Chromium 自己管理：

  • UI/渲染主线程
  • 合成线程
  • 网络与辅助线程
  • GPU 相关进程或线程

业务代码不应该随意直接控制 Chromium 内部线程。耗时计算使用 Worker；独立、易崩溃或高风险任务可以使用独立进程。

7. 浏览器界面能力

需要掌握的基本面：

  • HTML：结构和语义
  • CSS：布局、层叠、定位和动画
  • JavaScript：事件、异步、数据转换
  • DOM：页面节点和事件传播
  • 网络：HTTP、Cookie、缓存、跨域
  • DevTools：Elements、Console、Network、Performance、Memory
  • Vue Devtools：组件树、props、状态
  • 性能：重排、重绘、长任务和内存泄漏

调试时要先确认问题属于哪一层：

按钮没有响应
├── 元素是否被遮挡？
├── DOM 事件是否触发？
├── Vue 方法是否调用？
├── IPC 是否发送？
├── 主进程是否收到？
├── 底层服务是否成功？
└── 结果是否返回并更新状态？

8. Electron 的能力边界

Electron 很适合：

  • 复杂桌面业务界面
  • 多窗口应用
  • 文件管理和网络通信
  • 托盘、通知、快捷键
  • 音视频、下载、上传
  • Web 技术与原生能力结合

Electron 本身不天然解决：

  • 强安全隔离
  • 超低内存占用
  • 重度实时计算
  • 硬实时响应
  • 所有平台行为完全一致
  • 数据永久可靠
  • 任意系统能力直接可用

遇到 Electron API 不够时，通常通过以下方式扩展：

Electron API
→ Node.js 系统 API
→ 原生 Node Addon / FFI
→ 独立原生进程
→ C++/系统服务

你做业务时最需要形成的核心思维是：

1. 当前代码运行在哪个进程？
2. 这个进程拥有什么权限？
3. 操作是否会阻塞事件循环？
4. 数据的唯一权威来源在哪里？
5. 数据需要保持多久？
6. 多个窗口如何收到状态变化？
7. 页面关闭、进程崩溃后如何恢复？
8. Windows、macOS、Linux 行为是否一致？

只要每个功能都能回答这八个问题，基本就不是在“会用 Electron API”，而是在真正理解 Electron 桌面应用架构。

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。