RPC 桥接层：IPC 通信与终端会话生命周期
前置知识
- ›第 1 篇：架构与项目导航
- ›Electron IPC 基础（ipcMain、ipcRenderer）
- ›伪终端（PTY）基本概念
RPC 桥接层：IPC 通信与终端会话生命周期
在第 1 篇中我们了解到，Hyper 的主进程与渲染进程是两个相互隔离的世界，通过 Electron 的 IPC 机制相互连接。但 Hyper 并不直接使用原始的 IPC 接口——它在其之上封装了一套类型安全、以 UUID 为作用域的 RPC 系统，提供了窗口级别的消息隔离、EventEmitter 风格的 API，以及两种截然不同的通信模式。理解这套桥接机制至关重要，因为 Hyper 中_所有_有意义的交互——从键盘输入到终端输出——都要经过它。
本文将深入解析这套 RPC 系统，并逐步追踪终端会话的完整生命周期：PTY 如何被创建、输出数据如何被批量处理以提升性能，以及数据最终如何交付给 xterm.js 进行渲染。
以 UUID 为作用域的 RPC 通道
Hyper 中的每个 BrowserWindow 都拥有一条专属的 IPC 通道，以 UUID 作为唯一标识。这是一个关键的设计决策——若没有这层隔离，一个窗口的终端数据就可能泄漏到另一个窗口。
Server 类（主进程侧）负责生成 UUID 并建立通道：
当 BrowserWindow 完成加载后，服务端通过 webContents.send('init', uid) 将 UUID 发送给渲染进程。Client 类（渲染进程侧）接收到 UUID 后，订阅对应的通道：
sequenceDiagram
participant M as Main (Server)
participant E as Electron IPC
participant R as Renderer (Client)
M->>M: Generate UUID (e.g., "a1b2c3...")
M->>E: ipcMain.on(uuid, listener)
Note over M: Window finishes loading
M->>R: webContents.send('init', uuid, profileName)
R->>R: Cache uuid in window.__rpcId
R->>E: ipcRenderer.on(uuid, listener)
R->>R: emitter.emit('ready')
Note over M,R: Channel established — all future messages use this UUID
R->>E: ipcRenderer.send(uuid, {ev: 'new', data: {...}})
E->>M: ipcMain receives on uuid channel
M->>R: webContents.send(uuid, {ch: 'session add', data: {...}})
Client 构造函数中有一处巧妙的缓存设计值得关注：将 UUID 存入 window.__rpcId，这样即便 Client 对象被重新实例化（例如热重载时），也可以跳过等待 init 事件的步骤，直接使用缓存的 UUID 重新建立连接。
Server 和 Client 都在 EventEmitter 实例上使用了泛型类型参数。Server 负责发送 RendererEvents（主进程 → 渲染进程），并监听 MainEvents（渲染进程 → 主进程）；Client 则恰好相反。这确保了所有消息在编译阶段就经过类型检查——你不可能不小心从渲染进程发出一个主进程事件。
两种 IPC 模式：事件 vs 请求-响应
Hyper 采用了两种本质不同的 IPC 模式，分别适用于不同的场景：
模式一：即发即弃（Fire-and-Forget）事件 — 用于流式数据传输和无需响应的命令发送。RPC 的 Server.emit() 和 Client.emit() 方法均采用此模式。终端输出、会话生命周期事件和 UI 命令都通过这种方式传递。
模式二：请求-响应（invoke/handle） — 用于渲染进程需要向主进程查询数据的场景。底层使用 Electron 的 ipcMain.handle() / ipcRenderer.invoke() 对，返回一个 Promise。
请求-响应模式专门用于插件相关的查询：获取经过装饰的配置、键位映射、已加载的插件版本以及文件系统路径。这些数据由主进程管理，但渲染进程在初始化阶段需要同步获取。
flowchart LR
subgraph "Fire-and-Forget (RPC)"
A[Renderer] -->|"emit('new', options)"| B[Main]
B -->|"emit('session data', data)"| A
end
subgraph "Request-Response (invoke/handle)"
C[Renderer] -->|"invoke('getDecoratedConfig')"| D[Main]
D -->|"Promise<configOptions>"| C
end
提示： 如果你在开发 Hyper 插件并需要从主进程获取数据，推荐使用
invoke模式（通过ipcRenderer.invoke），而非 RPC 事件。请求-响应模式提供了简洁的基于 Promise 的 API，省去了手动管理回调监听器的麻烦。
类型安全的事件定义
typings/common.d.ts 中的类型定义是所有 IPC 通信的唯一契约来源，由三个核心类型构成：
MainEvents（渲染进程 → 主进程）定义了 15 个事件：
RendererEvents（主进程 → 渲染进程）定义了 42 个事件：
IpcCommands（请求-响应）定义了 8 个命令：
classDiagram
class MainEvents {
+close: never
+command: string
+data: uid+data+escaped
+exit: uid
+init: null
+new: sessionExtraOptions
+resize: uid+cols+rows
...15 events total
}
class RendererEvents {
+session add: Session
+session data: string
+session exit: uid
+termgroup add req: options
+split request: options
+move jump req: number
...42 events total
}
class IpcCommands {
+getDecoratedConfig() configOptions
+getDecoratedKeymaps() keymaps
+getLoadedPluginVersions() versions
+getPaths() paths
+child_process.exec() stdout+stderr
...8 commands total
}
第 98 行的 FilterNever<T> 工具类型是一个精妙的设计：payload 类型为 never 的事件（如 close 或 maximize）在发送时不需要传递数据参数。emit 方法通过重载来强制执行这一约束——rpc.emit('close') 完全合法，而不带数据字符串地调用 rpc.emit('session data') 则会触发类型错误。
PTY 会话创建与环境配置
当用户请求新建终端标签页时，主进程会创建一个 Session 对象来封装 node-pty 伪终端：
环境变量的配置过程相当细致，分为以下几个步骤：
- 基础环境 从
process.env克隆而来，并在 Linux 上清理 AppImage 相关路径。 - 终端变量 被明确设置：
TERM=xterm-256color、COLORTERM=truecolor、TERM_PROGRAM=Hyper。 - 语言环境 通过
os-locale检测，并以LANG=xx_XX.UTF-8的形式写入环境变量。 - Electron 泄漏清理：移除
GOOGLE_API_KEY，防止其出现在 Shell 环境中。 - 插件装饰：
decorateEnv扩展点允许插件添加或修改环境变量。
Shell 回退机制（第 182–218 行）值得重点关注：如果 Shell 在 1 秒内以非零退出码退出，Hyper 会判定配置存在问题，并自动回退到默认 Shell。这一设计有效防止了用户因 Shell 路径配置错误而被锁在系统之外。
DataBatcher 性能优化
终端模拟器每秒可能从 PTY 收到数以千计的小数据块。若将每个数据块单独通过 IPC 发送，性能将会急剧下降。Hyper 的 DataBatcher 通过双阈值批处理策略解决了这一问题：
flowchart TD
A[PTY emits data chunk] --> B{Batch size >= 200KB?}
B -->|Yes| C[Flush immediately]
B -->|No| D[Append to batch buffer]
D --> E{Timer running?}
E -->|No| F[Start 16ms timer]
E -->|Yes| G[Wait for timer]
F --> H[Timer fires → Flush]
G --> H
C --> I[Reset buffer to UID prefix]
H --> I
I --> J[Emit 'flush' → RPC sends to renderer]
16ms 超时和 200KB 上限这两个常量经过精心设计：16ms 与 60fps 的帧预算对齐，确保渲染进程每帧最多处理一批数据；200KB 的上限则防止单次超大批次造成内存压力。
最为精妙的优化是 UID 前置策略。每个批次在初始化时即以 this.data = this.uid 开头——36 个字符的 UUID 是缓冲区中的第一项内容。渲染进程收到字符串后，只需通过 d.slice(0, 36) 提取 UID，再用 d.slice(36) 获取实际数据。这样避免了为每个批次创建独立的包装对象，将 IPC 载荷保持为单一字符串，极大降低了序列化开销。
Window 作为编排中枢
Hyper 的所有子系统最终都汇聚在 app/ui/window.ts 中。newWindow 函数负责创建 BrowserWindow，并将 RPC 服务端、会话管理、配置订阅与插件钩子串联起来。
每个窗口会创建两个关键资源：一个 RPC Server 实例，以及一个用于追踪活跃终端会话的 Map<string, Session>。
app/ui/window.ts#L122-L180 中的会话创建流程展示了工作目录（CWD）保留功能的实现：当 preserveCWD 开启时，系统会通过 native-process-working-directory 解析当前活跃会话的 PTY 进程工作目录，并将其作为新会话的起始目录。
sequenceDiagram
participant R as Renderer
participant RPC as RPC Channel
participant W as Window Manager
participant S as Session/PTY
R->>RPC: emit('new', {activeUid, profile})
RPC->>W: rpc.on('new') handler
W->>W: Resolve CWD from active session PID
W->>W: Get decorated session options from plugins
W->>S: new Session({uid, shell, cwd, ...})
S->>S: Spawn node-pty with environment
W->>RPC: emit('session add', {uid, shell, pid, ...})
RPC->>R: Renderer creates tab/pane
loop Terminal Output
S->>S: PTY data → DataBatcher.write()
S->>W: batcher 'flush' event
W->>RPC: emit('session data', uid+data)
RPC->>R: Dispatch SESSION_PTY_DATA
end
S->>W: PTY exit event
W->>RPC: emit('session exit', {uid})
W->>W: Clean up session from map
app/ui/window.ts#L359-L365 中的清理函数确保资源不会泄漏：RPC 服务端被销毁，所有会话被终止，配置订阅和插件订阅也一并注销。
提示： 第 329-330 行 暴露的
window.rpc和window.sessions属性，是 Hyper 插件系统得以运作的关键入口。插件的onWindow钩子接收携带这两个属性的 BrowserWindow 对象，从而直接访问 IPC 层和会话管理能力。
下一篇预告
至此，我们已经完整追踪了数据在主进程与渲染进程之间的流转路径。但终端数据到达渲染进程之后会发生什么？它将进入 Redux——而 Hyper 的 Redux 架构绝非寻常。下一篇文章将深入探讨一条 thunk 出现两次的中间件链、一个完全绕过 React 的 write 中间件，以及用于建模分屏布局的不可变树结构。