# 五十张卡片，一块画布：CPU 都花到哪去了，以及“团队”卡片 > NeuroSquad 如何把空闲画布的渲染进程 CPU 从约 100% 降到约 15%：实测找出的原因、WebGL 上下文池、语义缩放，以及新的“团队”状态卡片。 - URL: https://neurosquad.ai/zh/blog/fifty-cards-one-canvas/ - Published: 2026-09-24 - Publisher: NeuroSquad (https://neurosquad.ai/) NeuroSquad 0.1.117 这个版本，你主要是通过“不再发生的事”感受到的：什么都没做时风扇狂转；拖动一个装满卡片的框时一顿一顿；每次缩小到卡片变成磁贴的那个临界点时卡一下。它还加入了“团队”卡片——一块告诉你工作区里每个智能体在做什么的面板。 从最初那几周起，画布的目标就没变过：最多五十张活的卡片——终端、浏览器、智能体——平移、缩放、拖动和调整大小都要流畅。达成目标的规矩也没变过：先测量。本文中的每个数字，都来自一个使用全新配置文件的独立应用实例，由通过 DevTools 协议发送的真实输入事件驱动。 ## 第一轮：五十个终端 第一轮优化发生在公开发布之前，场景是一个有五十张卡片的工作区，其中十二个终端在全速输出。缩放之所以慢，原因很容易被忽略：每张卡片的标题栏都要在屏幕上保持固定尺寸，而它是用 `width` 和 `margin` 实现的。这些都是布局属性。缩放的每一帧都会改变每个标题栏的尺寸，进而改变每张卡片主体的尺寸，进而触发每个终端的尺寸观察器——五十次终端重新适配、五十条发往主进程的消息、五十次控制台尺寸调整。每一帧都是。 修复办法是：缩放值每个手势只提交一次，而不是每帧都提交；只有当终端的行列网格真正变化时才调整终端尺寸；缩放进行时，把活的终端网格换成静态占位图。随后，终端从 DOM 渲染器换成了 xterm 的 WebGL 渲染器，大部分时间正是耗在这里：缩放的中位帧时间从 18.2 ms 降到 6.1 ms，p95 从 133 ms 降到 12 ms。 > **Chromium 每个进程恰好保留 16 个 WebGL 上下文** 这是测出来的，不是猜的。给全部五十个终端都开启 WebGL，一秒之内结果就是 `live: 16, lost: 34`——而且幸存的十六个是最先挂载的，而不是你正在看的那些。所以终端从一个容量为十五的池子里领取上下文：分给屏幕上的终端，离开屏幕的则收回。 那一轮的一项测量定下了一条至今仍在代码里的规则。把终端藏在占位图后面，让缩放快了一倍（中位数 6.1 对 12.0 ms），却让平移变慢了（平均 19.8 对 16.3 ms）：平移只是移动已经绘制好的图层，把五十个网格换出去再换回来，花的比省的还多。所以只有当手势真的改变了缩放时，才会出现占位图。 ## 第二轮：空闲的画布 第二轮始于一个更奇怪的抱怨：*什么都没发生*的时候，画布也很沉。四路并行的代码审查加上一次针对“Launch day”工作区的实时性能剖析，发现原因不是一个，而是一堆小而持续的开销。其中最大的一个，是个卡通形象。 AI 智能体卡片上有一个显示智能体状态的小吉祥物。它的待机动画是作用在 SVG 子元素上的无限 CSS 动画——而对这类元素，浏览器要在主线程上每一帧都重绘，永无止境。一块缩放在 60% 的画布上放着三张 Claude Code 卡片，什么都不做，渲染进程就占用了一个核心的 98–104%，GPU 占 32–36%。现在只有“工作中”状态会循环，而且动的是外层的 HTML 包装元素，由合成器独立处理；其他状态都只播放几遍，然后停在一个本身就能说明状态的姿势上。 - **~100% → 15%** — 渲染进程 CPU，放着三张智能体卡片的空闲画布 - **~34% → 3%** — 同一块画布上的 GPU - **180 → 66** — 一条 CSS 规则之后的合成层数量 剩下的是一串清单，每一项都只花一点点，却全都一刻不停地在跑： - **画布下带 `*` 和 `:has()` 的选择器。**每次在画布面板上切换一个类，都要花 25–34 ms 重新计算样式，因为“手势下的所有后代元素”这类规则必须对每张卡片的每个节点重新匹配。改为只列出真正有动画的元素后，降到了约 1.5 ms。 - **面板上的 CSS 变量。**缩放级别存放在包含所有卡片的那个元素的自定义属性里，一改动就会让整棵子树（包括终端）的样式失效——每次提交 22–34 ms。现在它是 `