electron 的应用架构思考
最近在用 electron 开发上位机软件，在开发的过程中对于这类应用的架构做了一些分析，在此作为记录。
IPC 通讯
稍微了解过 electron 的应该都知道, electron 使用的是多进程架构，主进程负责创建渲染进程，渲染进程负责渲染页面，渲染进程之间是相互隔离的，渲染进程和主进程之间通过 IPC 通信。
在 electron 早期，electron 提供了类似于 ipcMain,ipcRender 的 API 来实现进程间通信，但是这种方式使用起来比较麻烦，后来 electron 提供了 remote 模块，通过 remote 模块可以直接调用主进程的方法，但这个模块并不完美，存在各种各样的陷阱。所以，直到现在，electron 的主流还是使用 ipcMain,ipcRender 来实现进程间通信。
如果是小的项目，直接使用 electron 的 Api 通讯还是比较方便的，但是如果是大型项目，这种方式就会变得非常麻烦，因为这种方式需要在主进程和渲染进程中都写一遍通信的代码，这会增加代码的复杂度，容易出错。像是 VSCode 项目，就是在 electron 的基础上做了一层封装，实现了自己的一套通讯机制。
进程职责
通过不同的项目代码可以发现，每个项目的 main 进程职责并不相同，大体有以下几大类：
- main 主要暴露一些平台相关的接口给 render 进程，render 中实现主要的逻辑
- 在 main 进程中实现业务逻辑，render 仅根据当前状态进行展示。
- 在 main 进程和 render 进程都有一部分业务逻辑。
- 在 render 进程开启 node 支持，所有逻辑都在 render 进程中执行。
总体上看，除了最后一个方案在 electron 官方文档中不被推荐，其余的方案各有各的优点，适用于不同的场合。
当一个技术给了开发者太多选择时，混乱就产生了。
尤其在一个对架构掌控能力不足的团队中，很容易出现架构不一致的问题，导致项目工程质量的进一步恶化。
相对合理的设计
看了很多资料，也翻阅了 VSCode 的代码，最终总结了一个比较合理的原则：
- 渲染进程中进行主要的业务逻辑，在架构中处于中心位置
- main 进程负责提供平台 API 支持，并通过 IPC 暴露给 render 进程
这样一来，开发 electron 应用的体验与 WEB 基本一致。不需要过度纠结进程之间的职责分配。