自研 UI 引擎的渲染层：Canvas 还是 WebGL，这次我用指标来选

做自研 UI 引擎，第一个绕不开的决策是渲染层选 Canvas 2D 还是 WebGL。我把这次选型的过程和指标记下来，供后来者少走弯路。 先明确场景。我们要做的是一个可拖拽的仪表盘式界面，元素数量在几百到一千之间，有圆角、阴影、文字、少量渐变，需要 60fps 的拖拽响应。 Canvas 2D 的实测表现：一千个元素静态渲染没问题，但每次拖拽都会触发全量重绘，帧率掉到 25 到 35 之间。优化方向是脏矩形重绘，只重绘变化的区域，改完之后拖拽能稳在 55 以上。代价是布局系统要自己维护每个元素的影响范围，代码复杂度上来了。 WebGL 的表现：把每个元素做成一个 quad，用纹理合批，一千个元素稳 60fps，缩放和变换几乎无成本。代价是所有东西都要自己实现——文字要用字体图集，圆角和阴影要写 shader 或者预渲染成纹理，开发量比 Canvas 方案高一个量级。 我们的结论是分层：元素少于 500 且交互简单时用 Canvas 2D，先拿到开发效率；超过 800 或者需要 3D 变换、大量滤镜时切 WebGL。为此引擎的渲染层做了抽象，上层只描述"画什么"，具体走哪条路径由渲染后端决定。 关于 agent 的用法，这里有个很实用的分工：让 Claude Code 写渲染后端的骨架和性能基准测试，因为这类代码结构性强、需要反复跑分验证；让 MiMo Desktop 做可视化验证，把渲染结果在会话说预览里直接看、直接圈改变的部分。引擎开发最怕的就是"改了半天看不出哪里错了"，能可视化是效率的关键。 提醒一点：自研 UI 引擎的成本很容易被低估。如果需求不是特别特殊，先用成熟方案，把精力放在业务上，通常更划算。