在 Qoder CN 中进行长轮次 AI 对话（同一窗口多轮对话后），系统总 CPU 占用持续飙升至 130-140%+（多核累加），严重影响开发体验。
通过 ps aux 采集的进程级数据：
| 进程类型 | CPU | MEM | 说明 |
|---|---|---|---|
| Renderer (主窗口) | 50.3% | 9.5% | 编辑器 + AI 聊天 Webview + UI 全部在同一 Renderer |
| GPU 合成 | 8.6% | 0.5% | 大量 DOM 节点的光栅化合成 |
| Main | 1.2% | 1.1% | Electron 主进程 |
| Extension Host | 0.3% | 0.5% | 插件宿主 |
关键发现：Renderer 进程独占 50%+ CPU，且随对话轮次增长持续攀升。长会话时 Renderer 可达 70-100%，加上 GPU 进程的 20-30%，总量突破 130%。
当前架构下，AI 聊天面板（Webview）与代码编辑器（Monaco Editor）运行在同一个 Renderer 进程中：
Renderer Process (单线程)
├── Monaco Editor (canvas + DOM)
├── AI Chat Webview
│ ├── 聊天消息 DOM 树（无限增长）
│ ├── Markdown 渲染
│ ├── 代码块语法高亮
│ └── 流式响应 DOM 变更
├── Extension UI 贡献 (CodeLens, Decorations, StatusBar)
└── IPC 消息处理
问题：Webview 的高 DOM 开销直接挤压编辑器的渲染帧预算，导致整个窗口卡顿。
每轮对话产生的 DOM 结构：
由于没有虚拟化滚动，所有历史消息的 DOM 节点始终存活在文档中，导致：
核心思路：只渲染可视区域内的消息 DOM，滚出视口的消息仅保留占位符。
┌─────────────────────────┐
│ [占位符 1200px] │ ← 历史消息（仅高度占位，无 DOM）
├─────────────────────────┤
│ ████ 消息 #48 ██████ │ ← 可视区域：完整渲染
│ ████ 消息 #49 ██████ │
│ ████ 消息 #50 ██████ │
├─────────────────────────┤
│ [占位符 3600px] │ ← 未来消息（仅高度占位）
└─────────────────────────┘
实现要点：
IntersectionObserver 或 scroll offset 计算可视窗口预期收益：
核心思路：将 AI 聊天面板的 Webview 隔离到独立的 Renderer 进程，与编辑器解耦。
当前架构: 建议架构:
┌─────────────────┐ ┌──────────────────┐
│ Renderer (共享) │ │ Renderer #1 │
│ ├─ Editor │ │ └─ Monaco Editor│
│ ├─ Chat Webview│ ──── 争抢 ──→ ├──────────────────┤
│ └─ Extension UI│ │ Renderer #2 │
└─────────────────┘ │ └─ Chat Webview │
├──────────────────┤
│ Renderer #3 │
│ └─ Extension UI │
└──────────────────┘
实现要点：
BrowserView 或 WebContentsView 将聊天面板渲染到独立进程ipcRenderer/ipcMain）在主 Renderer 和 Chat Renderer 之间通信预期收益：
核心思路：AI 流式回答时，采用增量 DOM 更新而非全量替换。
当前问题：每次收到新 token 时，可能触发整条消息的 Markdown 重新解析和 DOM 重建。
建议实现：
appendText 方式直接操作 DOM TextNode，避免重新解析requestAnimationFrame 合并高频更新（每帧最多一次 DOM 变更）预期收益：
核心思路：超长会话自动折叠早期消息，用户展开时再渲染。
建议实现：
| 方案 | 优先级 | 实现复杂度 | CPU 预期降幅 | 用户感知 |
|---|---|---|---|---|
| A. 虚拟化滚动 | P0 | 中 | 60-70% | 长会话不再卡顿 |
| B. Webview 进程隔离 | P1 | 高 | 30-40% | 编辑器始终流畅 |
| C. 流式渲染优化 | P1 | 低 | 20-30% | AI 回答时不卡 |
| D. 会话折叠 | P2 | 低 | 10-20% | 减少 DOM 总量 |
建议实施路径：C（快速见效）→ A（核心解决）→ B（架构升级）→ D（体验增强）
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
