Electron流程模型的理解
继承自Chromium的架构
Electron继承了来自Chromium的进程架构（也就是说Electron的架构十分类似一个现代网页浏览器）。
现代浏览器（以Chromium为例）采用的是多进程模型，这种模型区别于早期浏览器的单进程模型。这样做的好处是一个网页崩溃不会影响到其他页面乃至整个浏览器，坏处是开销会增大。
多进程模型
Chromium的多进程模型如下：
Electron的架构与此十分类似，作为开发者，我们需要控制两种类型的进程：
- 主进程 - 类似上图的Chrome Process Manager
- 渲染进程 - 类似上图的Process
主进程
每个Electron应用都有一个单一的主进程，作为应用的入口点。
主进程在Node.js环境中运行，这意味着它具有
require模块和使用所有Node.js API的能力。主进程是唯一的。
主进程的主要工作是：
- 使用
BrowserWindow模块创建和管理应用程序窗口。 - 使用
app弄块来控制应用程序的生命周期。 - 使用原生API完成一些工作……
渲染进程
每个Electron应用都会为每个打开的BrowserWindows（与每个网页嵌入）生成一个单独的渲染进程。
渲染进程有多个，和不同的
BrowserWindows一一对应。渲染进程负责渲染网页内容，所以渲染进程中的代码实际上是遵照网页标准的（至少目前使用Chromium的Electron如此）。
警告：可以使用完整的Node.js环境生成渲染器进程，以便于开发。从历史上看，这曾经是默认设置，但出于安全原因，此功能现在被禁用。
渲染进程与主进程的交互
我曾有一篇博文从实际开发的角度简单介绍了
ipc模块的简单使用以及webContents.send，这是主进程与渲染进程通信的最简单方法：Electron主进程与渲染进程的通信。
渲染进程与主进程独立也就意味着渲染进程无权直接访问require或其他Node.js API。
那渲染器进程用户界面怎样才能与Node.js和Electron的原生桌面功能进行交互？
事实上，确实没有直接导入Electron內容脚本的方法。
Preload 脚本
预加载 (Preload) 脚本包含了执行于渲染器进程中，且先于网页内容开始加载的代码。
这些脚本虽然运行于渲染器环境中，却因能访问Node.js API而拥有了更多的权限。
进程间通信
虽然渲染进程没有任何办法与Node.js和Electron的原生桌面功能进行交互，但是我们可以通过进程间通信间接的完成这一目的。详见：Electron主进程与渲染进程的通信
两进程间可调用的API
