1. 性能瓶颈前的“黑暗时刻”为什么OrcaTerm要死磕渲染几乎每个 Web 终端产品走到某个阶段都会撞上一堵墙功能堆得越多界面反馈越迟钝输入一个字符要等上百毫秒才有回显滚动日志时画面一帧一帧地“撕裂”过去。OrcaTerm 在早期版本里也踩过这个坑而且踩得相当痛。OrcaTerm 本质上是一个运行在浏览器里的终端模拟器用户通过它连接远程服务器、操作容器、调试代码、查看日志。这类工具的体验核心就一个字快。这里的“快”不是页面加载快而是每一次按键、每一次输出、每一次滚动都要像本地终端一样“零感知”。但浏览器不是原生桌面环境它有事件循环、有渲染管线、有内存回收还有各种诡异的合成层策略。如果不做设计上的根本性改造性能天花板就在那里。当时我们内部做了一个简单的基准测试连续打印 5000 行日志然后快速滚动到底部。结果是灾难性的——FPS 掉到个位数CPU 占用飙到 120% 以上输入框卡顿到让人怀疑人生。同一个测试跑在 xterm.js 底层的原生终端上流畅度完全不在一个量级。那会儿我们才意识到OrcaTerm 的问题不是“某个函数写慢了”而是整条渲染链路从架构上就不适合高吞吐输出场景。后来我们花了大半个迭代周期把渲染模块推倒重做才一步一步把性能拉到竞品第一梯队。这个过程中踩过的坑、验证过的方案、总结出的经验我觉得值得单独写一篇文章记录下来。这篇文章不会只讲结论还会把性能问题的根因、优化方案的选型理由、以及落地时容易翻车的细节全部摊开来讲。如果你也在做类终端产品、Web 实时展示工具或者是 WebSocket 高吞吐数据可视化方向这篇文章应该能帮你少走很多弯路。就算你只是对“浏览器里怎么又快又稳地渲染大量文本”这个话题感兴趣后面的内容也值得看一下。2. 根因分析先搞清楚卡顿到底卡在哪里2.1 按需渲染到整页刷新一个错误的“偷懒”设计初版 OrcaTerm 的渲染思路很“朴素”终端缓冲区里有多少行就渲染多少行 DOM 节点。每来一批新数据就整页重绘一次。这个方案在输出量小的时候没什么问题但一旦面对高频日志输出立刻暴露出三个致命弱点。第一个弱点是DOM 节点数量爆炸。终端缓冲区通常保留 1000 到 5000 行历史内容如果每一行都对应一个 div再加上行内 span 包裹的样式节点页面上的 DOM 数量轻松超过 5 万个。浏览器对大量 DOM 节点的布局、绘制、事件绑定都有明显性能上限节点越多每次重排的成本越高。第二个弱点是重排重绘范围失控。每来一批数据我们都直接操作整个容器浏览器会从头到尾计算布局、重新绘制所有可见区域。实际上终端输出往往只影响最后几行这种“全量刷新”的写法浪费了大量计算资源而且随着历史行数增加浪费越来越严重。第三个弱点是渲染频率不受控。WebSocket 推送数据的频率远高于浏览器的帧率一批数据到了就渲染一次导致碰撞问题。大多数数据帧还没被绘制出来就被下一帧覆盖了浏览器反复做无用功主线程被挤爆。2.2 数据管道瓶颈PTY的“洪峰”直接冲垮了前端除了渲染层的问题数据链路同样存在瓶颈。OrcaTerm 后端通过 PTY伪终端对接远程命令前端通过 WebSocket 接收输出流。PTY 输出数据的特点是“突发性强”——一条命令可能在几十毫秒内吐出几百 KB 甚至几 MB 的数据。初版的前端收到每一条消息就立刻追加到缓冲区和 DOM 里这种“收到即渲染”的模式在高吞吐场景下必然会出问题。一方面是后端到前端的协议开销大每条消息都有 JSON 格式的字段冗余另一方面是前端处理数据的粒度太细每次只处理一小段文本导致函数调用次数暴增JavaScript 引擎的调用栈都被这些碎数据处理任务堆满了。我当时做个一个很简单的实验在后端模拟一次性输出 2MB 日志观察前端从收到数据到渲染完成的时间。结果是耗时 3.2 秒整个过程浏览器标签页基本处于“假死”状态。这根本不是量级上的差距而是架构上的失败。2.3 竞品对标性能差在哪里不是玄学是工程债在优化之前我们也拉了几个主流终端工具做了横向对比包括 xterm.js 官方的 demo、Tabby 这种基于 Electron 的现代终端、以及 Windows Terminal 这类原生方案。对比结果很残酷别人滚动 5000 行日志时 FPS 能稳定在 30 帧以上而 OrcaTerm 连 5 帧都保不住。仔细分析后我们发现差距主要集中在三个方面一是别人对渲染区域做了裁剪只绘制可视区域附近的少量行而不是全部历史二是别人的数据管道有合并和节流机制不会让每一次小数据都触发一次渲染三是别人在绘制层面用了更高效的方案比如 Canvas、WebGL而不是纯 DOM 拼接。这些差距不是某一个点的问题而是整条链路都是“债”。3. 渲染层优化从 DOM 泥潭走向 canvas 分层绘制3.1 按需渲染的思路只画用户看得见的行第一刀我们先砍掉 DOM 渲染黑盒里的“全量冗余”。核心思路很简单不管终端缓冲区里有多少历史行画面上其实只需要绘制可视区域内的那几十行。用户滚动查看历史时再动态计算渲染区间和位置。这个策略听起来直白但落地细节非常多。首先是行高缓存——每个字符我们采用固定行高和固定列宽的网格布局这样任意滚动位置都能通过简单的整数运算计算出应该显示哪些行不需要进行 DOM 测量。比如可视区域高度是 600 像素行高是 16 像素那么可视区域对应的行区间就是 600 / 16即 37.5向上取整后我们只需要渲染约 38 行。其次是虚拟滚动坐标换算。我们维护一个总行数计数器用户滚动时用滚动偏移量除以行高得到起始行号再从缓冲区里取对应行的文本和样式信息送入渲染器。整个过程不创建任何冗余 DOM 节点滚动计算量从 O(n) 降到了 O(1)。最后是预渲染缓冲区。为了保证快速滚动时不会露出白屏我们会把可视区域上下各多渲染 5 行作为余量。这样即使滚动速度快到一帧跨好几行用户也基本看不到空白区域。实测下来这个策略对体验的提升非常明显快速滚动时几乎无感知。3.2 Canvas 批量绘制文本每帧只做一次“画布提交”DOM 数量降下来之后还有一个问题即使只显示 38 行如果采用 38 个 div 再加每个 div 里的多个 spanDOM 节点仍然有几百个而且在快速更新时仍然存在布局计算开销。所以我们做了一个更加彻底的决定——放弃 DOM 来渲染正文全部改用 Canvas。Canvas 绘制文本听起来很初级但真正做好终端渲染至少有三个坎要跨过。第一个坎是文本样式切换。终端文本有前景色、背景色、加粗、斜体、下划线、链接高亮等状态。Canvas 的 fillText 本身不支持富文本我们只能逐段扫描行内样式遇到样式变化就切换 fillStyle 和 font再继续绘制。这个过程如果写得粗糙循环里反复设置状态性能会极具下降。第二个坎是背景色填充顺序。终端有一个特殊行为——整行高亮、字符背景色、光标块这些背景必须在文字绘制之前全部画完否则文字会被背景盖住。我们的做法是分两个阶段绘制先绘制所有背景像素遍历每个字符的 bg 属性并 fillRect再统一绘制文字。这样既保证视觉正确性又能减少画笔的状态切换次数。第三个坎是字体缩放与清晰度。Canvas 在高 DPI 屏幕上如果直接使用 CSS 像素绘制文字会发虚。因此我们在绘制前要把 Canvas 的实际分辨率乘以 devicePixelRatio再通过 scale 恢复坐标系。比如在 2 倍屏上canvas.width 设为容器宽度 * 2同时执行 ctx.scale(2, 2)画面就锐利了。上面这些都属于绘制细节更重要的是框架层面的主循环。我们用 requestAnimationFrame 做渲染调度数据到达时只写入显式缓冲区不立即绘制等到下一帧开始前统一从缓冲区取数据、合成样式、一次性按需重绘。这样每帧最多只执行一次完整的绘制操作避免一秒钟触发几十次重绘的乱象。3.3 双缓冲与脏矩形截取别让背景刷出“拉丝”效果做 Canvas 渲染时最容易踩的一个坑是残留重影。因为 Canvas 不会像 DOM 那样自动清除“之前的自己”如果你只绘制了新数据所在的行而没有覆盖掉旧画面屏幕上就会留下文字的残影。这个问题有三种解决路径一是每帧清空整块画布重绘全部可见区域实现简单但大画布全擦的 fillRect 本身也有成本二是只擦除脏矩形区域计算成本很低但矩形合并逻辑容易出 bug三是双缓冲——在内存中维护一个同尺寸的离屏 Canvas绘制到内存画布后再整体拷贝到显示画布。我们最终选的是离屏 Canvas 全量重绘可见区域的方案。因为终端可见区域通常只有 30 到 60 行文本即使全量重绘fillRect 加 fillText 的开销也完全可控但离屏 Canvas 带来的好处是我们的渲染管线可以随时做到“一帧只提交一次合成结果”画面永远不会出现半更新状态也天然规避了重影问题。这里还有一个细节离屏 Canvas 的总尺寸应该与可视区域一致而不是与整个终端缓冲区一致。缓冲区可能有 5000 行但离屏画布只需要覆盖可视高度。比如视野是 38 行行高 16 像素那离屏画布就是 608 像素高。滚动时我们只需把滚动的像素偏移量传给绘制函数让它从正确的位置采样数据。4. 数据管道重构让海量输出像水流一样平稳4.1 合并写缓冲宁等一帧不抢一毫秒渲染层搞定之后我们把目光转向数据管道。前面已经说过WebSocket 推送数据的频率远高于浏览器渲染频率。如果数据一到就立刻塞给渲染器渲染器会被碎片化更新淹没导致每帧都要处理大量小任务性能反而更差。解决方案就是引入合并写缓冲机制。具体实现是维护一个 pendingData 队列WebSocket 收到数据后先把数据追加进这个队列并打一个“有更新”标记触发一次 requestAnimationFrame 调度等到帧回调执行时一次性把队列里所有数据按顺序合并成一个大字符串再交给终端状态解析器。如果一帧内来了 50 次推送我们就只在下一帧合并处理一次将 50 次渲染调用降成 1 次。这个策略的核心价值不是减少代码量而是稳定帧时间和 CPU 占用。实测结果是同样输出 2MB 日志初版从数据到渲染完成需要 3.2 秒合并写缓冲之后降到了 1.1 秒左右而且页面不再“假死”中间用户仍然可以滚动和操作。4.2 二进制协议收编 JSON减少序列化与内存碎片的双重压力初版 WebSocket 数据格式用的是 JSON形如 {type:output,data:...}。这种格式开发方便但存在两个问题一是每一条消息都有固定字段和引号、花括号产生了大量冗余字节二是 JSON.parse 需要为每一条消息新建临时对象高频推送时会产生巨量内存分配进而触发频繁 GC。我们后来把传输协议改成了二进制格式自定义了一个轻量帧结构第一个字节是消息类型随后两个字节是数据长度再后面是 UTF-8 编码的明文内容。前端收到 ArrayBuffer 后通过 DataView 直接读取长度和数据再用 TextDecoder 一次性解码。整个过程几乎零临时对象分配GC 压力大幅降低。有的人可能说现代 JS 引擎的 JSON.parse 已经很快了没必要在协议上抠这么细。但真实场景下当输出频率达到每秒几十次甚至上百次推送时JSON.parse 的累积成本不容小觑。我做过对比在同样 10MB 数据量的压力测试中二进制协议的处理时间比 JSON 快 35% 左右内存峰值降低了约 20%。4.3 输入通道优先级键入响应比什么都重要在终端场景里输出数据量再大也不能让用户输入变得卡顿。用户按下一个键预期的结果是远端命令立刻收到字符并回显这个过程一旦被海量输出阻塞整个终端就没有“可用性”可言。我们在重构数据管道时做了一个细节处理输入通道高优先级分离。浏览器主线程同时处理输出数据解析和输入事件转发如果输出数据量特别大解析任务可能会占据主线程导致 keydown 事件排队等待。为了规避这个问题我们把数据接收与解析从主线程里挪了一部分出去——接收到 ArrayBuffer 后不直接在主线程做逐字符解析而是先存进环形缓冲区再由渲染帧回调按批次解析。这样布局能保证用户输入事件在主线程的响应优先级不被数据解析挤占。实测在输出洪峰情况下输入到服务器回显的延迟依旧能稳定在 60ms 以内。这一点对真实用户来说比渲染速度的绝对值更敏感。5. 终端状态存储缓冲区不只是“一堆字符串”5.1 按行存储的行模型终端缓冲区如果只存一个巨大的字符串做“按行更新”“按行删除”“按行滚动”会非常痛苦。我们的方案是把缓冲区设计成稀疏行数组每一行是一个行对象里面对保存文本内容、样式游标段、行宽度元信息、是否换行等属性。这样做的好处是渲染器按可视区域取数据时可以直接按索引取值不需要做字符串切分。更重要的是终端的某些控制序列比如清屏、删除行、在中间插入行可以按照行的粒度进行 O(1) 级别的数组操作而不是对整个字符串做正则替换。行对象内部保存样式的方式也需要斟酌。如果每个字符都存一个独立样式对象内存占用太大。我们采用的是分段样式表方案每行内部维护一个 TextSegment 数组每个 Segment 记录一个文本连续区间、前景色、背景色、加粗等属性。比如一行 80 个字符前 10 个是红色后 70 个是默认样式我们就只存两个 Segment而不是 80 个样式对象。5.2 大日志滚动的内存护栏限制回看行数压缩历史痕迹日志查看场景往往有滚动查看历史的需求但这和内存保护天然冲突。如果缓冲区无限保留所有输出哪怕一列日志打印几百万行内存也会被撑爆。我们的策略是给回看缓冲设上限——默认 6000 行超过上限时从头部批量淘汰。这个深浅度的选择基于实测5000 到 6000 行日志足够覆盖绝大多数排障场景而且每行平均占用约 300 字节总内存占用控制在 2MB 以内对浏览器压力非常小。但这带来一个交互问题用户正在向上滚动查看历史如果中途缓冲被淘汰他看到的行号就会跳动。为了避免这种“抽风”体验我们做了淘汰保护机制如果当前可视区域停止在某个位置淘汰操作优先从可视区域以下的数据开始尽量不影响用户正在看的内容。如果淘汰范围逼近可视区域头部我们会在左下角提示“历史缓冲已截断”让用户知道数据不完整。5.3 控制序列解析的“状态机改造”终端渲染里还有一个常被忽略的瓶颈——ANSI 转义序列的解析。原始日志里夹杂着大量 \x1b[...m 这样的 CSI 序列如果每次追加数据都重新解析整段文本不仅 CPU 开销大而且会因为半截序列跨消息到达而产生解析错误。我们最后把解析器改成了流式状态机。解析器内部维护一个状态普通文本态、ESC 起始态、CSI 参数收集态、最终字节态。每收到一段新数据就从上一次停留的状态继续推进而不是从头部重新开始。这样既不丢序列也把解析复杂度控制在线性范围。这个改造带来的另一个附带好处是解析结果可以按“区块”粒度返回给渲染器。每个区块对应一段稳定的文本区间和样式信息渲染器可以直接拿这些区块去绘制不需要再二次扫描。6. 性能验证与竞品对标用数据说话的压测实录6.1 压测方法论别只盯着 FPS 一个指标优化做完之后最怕的是自我感觉良好。我们搭建了一套可复现的压力测试环境重点看四个指标FPS帧率、CPU 占用率、从数据到达首帧渲染耗时latency、以及内存占用曲线。场景分为四类一是正常交互输入模拟用户敲命令二是高频小数据输出比如 ping 或 top 命令三是高吞吐日志滚动输出用脚本一次打印 100MB 数据四是超大行文本比如单行 10 万个字符的 minified 文件。每一类场景都在同一台测试机上跑多轮最终取中位数和 P95。只有 P95 好才是真的好因为终端用户一旦遇到一次超过 300ms 的卡顿就会明显感到不适。6.2 优化前后对比数据提升幅度直接上我们内部记录的一组优化前后对比数据以下数据是某次压测的记录浏览器版本为 Chrome 121机器为 2021 款 MacBook Pro场景优化前 FPS优化后 FPSCPU 占用下降首屏渲染耗时高频小数据输出ping206045%380ms → 95ms高吞吐日志滚动5000 行45560%3200ms → 210ms超大行10 万字符单行卡死30--正常交互输入306030%80ms → 15ms大家可以看看“高吞吐日志滚动”这一行首屏渲染耗时从 3200ms 降到 210ms这是一个量级的提升。FPS 从 4 提升到 55说明渲染管线从“直接不可用”变成了“比较流畅”。超大行场景虽然仍没到 60 帧满帧但至少不会卡死已经具备可用性。6.3 与控制变量踩过的一个“假优化”坑在优化的过程中我们还踩过一个假优化的坑在这里提醒大家警惕。当时我们尝试过把 Canvas 的绘制放到 Web Worker 里执行理论上可以把主线程完全解放出来。实现之后运行发现 FPS 没有任何提升反而小幅下降。排查了很久才发现OffscreenCanvas 虽然在 Worker 里可以绘制但最终的 commit 操作transferToImageBitmap仍然需要在主线程上执行。如果浏览器对 OffscreenCanvas 合成路径优化不好反而多了一层数据拷贝的开销。后来我们放弃了这个方案继续沿用主线程 Canvas把精力放在减少主线程内无效计算上。这个经历说明一个问题性能优化不能只看“架构听起来更先进”一定要用压测数据来验证。有些方案在理论上是对的但在实际浏览器实现里并不会有预期收益。7. 常见问题与排查技巧实录7.1 问题速查表现象可能原因排查方向滚动日志时白屏闪烁可视区域外的预渲染余量太小延长上下预渲染行数输入回显延迟高主线程被数据解析堵住检查是否有同步的大字符串操作把解析拆为分批任务长时间使用后内存暴涨历史缓冲行数没有淘汰确认行淘汰策略是否触发是否有事件监听器残留字体模糊发虚Canvas 没有适配 devicePixelRatio设置 canvas.width 容器宽 * dpr终端的背景色铺满整行后文字消失绘制顺序错误必须先绘制背景 fillRect再绘制文字 fillText粘滞感滚动一顿一顿数据解析和渲染没有分离引入合并写缓冲和异步调度多浏览器表现不一致Canvas 字体度量差异统一指定 font-family并在初始化时测量行高7.2 一个真实的线上问题滚动时“屏幕撕裂”上线不久后有用户反馈在快速滚动大日志时画面中间会出现一条横向的分隔线上半部分是旧内容下半部分是新内容肉眼看起来像是屏幕撕裂。排查了很久才发现是浏览器把 Canvas 分成了多个合成层滚动时合成层之间的同步出现了时间差。解决方案是把 Canvas 的 willReadFrequently 属性和 transform 样式做了调整强制浏览器走同一条合成路径。同时我们把每帧绘制结束后的 commit 操作改成在 requestAnimationFrame 回调用统一提交避免中间态被浏览器展示出去。这个问题解决后类似的撕裂现象再也没有出现过。7.3 性能调优建议给同样做终端渲染的同学一些经验如果你正在做类终端产品我的建议是先把数据管道和渲染调度这两层做好再考虑更底层的高级优化。很多人一上来就盯 GPU 加速、WebGL 渲染忽略了数据合并和画布重绘裁剪这些基础能力反而没法获得明显的收益提升。还有一个容易忽略的点终端性能优化要和真实的“用户场景”绑定。比如你做的是运维工具用户最常见的操作是查看大日志和同时打开多个终端标签页那你的压测场景应该围绕多标签并发展开而不是单纯在单个终端里堆数据。工具方面推荐用 Chrome DevTools 的 Performance 面板和 Memory 面板做火焰图分析和堆快照对比再配合 Lighthouse 辅助看整体渲染性能基线。但这些工具只能帮我们发现性能瓶颈在哪个函数、哪条调用链上最终怎么改还是得回到业务场景里去做权衡。8. 回顾与个人体会OrcaTerm 这次渲染优化的全过程让我对“性能优化”这件事有了更深的感知。性能问题通常不像功能 bug 那样有明确的错误信息它是一点点累积起来的工程债。初版为了快速迭代选择全量 DOM 渲染在当时看来是“最省事”的方案但它残酷地决定了后期的天花板。只要架构底子不对后面再怎么打补丁也追不上一开始就选对路线的产品。我在这次优化中最大的心得是三个词分离、裁剪、合并。把数据接收和渲染调度分离让它们各司其职把渲染范围裁剪到用户真正看得见的区域不做无畏的全局消耗把高频的小数据合并成大块再处理减掉无效的计算和内存分配。这三个思路不仅适用于终端渲染做任何高吞吐实时界面都值得参考。另外性能优化一定要形成数据闭环。我们每完成一个子优化就立刻跑压测记录数据而不是等所有改动都做完了才测试。这样哪一步优化带来了收益、哪一步是无效改动全局一目了然。现在 OrcaTerm 的每一个渲染相关的 PR都会附带性能测试的对比记录这已经成为了我们的开发习惯。如果你也在优化自己的终端工具或者正被类似的高吞吐渲染问题折磨我希望这篇内容能给你带来一些具体的参考。最后再分享一个小技巧做终端渲染优化时不要只盯着“大日志”场景多试试“高频小输出”场景——比如 top 命令或者连续 ping 的输出。这种场景下最容易暴露渲染调度的效率问题也最能反映出终端工具的日常使用体验。
OrcaTerm性能优化实战：从DOM泥潭到Canvas分层渲染
1. 性能瓶颈前的“黑暗时刻”为什么OrcaTerm要死磕渲染几乎每个 Web 终端产品走到某个阶段都会撞上一堵墙功能堆得越多界面反馈越迟钝输入一个字符要等上百毫秒才有回显滚动日志时画面一帧一帧地“撕裂”过去。OrcaTerm 在早期版本里也踩过这个坑而且踩得相当痛。OrcaTerm 本质上是一个运行在浏览器里的终端模拟器用户通过它连接远程服务器、操作容器、调试代码、查看日志。这类工具的体验核心就一个字快。这里的“快”不是页面加载快而是每一次按键、每一次输出、每一次滚动都要像本地终端一样“零感知”。但浏览器不是原生桌面环境它有事件循环、有渲染管线、有内存回收还有各种诡异的合成层策略。如果不做设计上的根本性改造性能天花板就在那里。当时我们内部做了一个简单的基准测试连续打印 5000 行日志然后快速滚动到底部。结果是灾难性的——FPS 掉到个位数CPU 占用飙到 120% 以上输入框卡顿到让人怀疑人生。同一个测试跑在 xterm.js 底层的原生终端上流畅度完全不在一个量级。那会儿我们才意识到OrcaTerm 的问题不是“某个函数写慢了”而是整条渲染链路从架构上就不适合高吞吐输出场景。后来我们花了大半个迭代周期把渲染模块推倒重做才一步一步把性能拉到竞品第一梯队。这个过程中踩过的坑、验证过的方案、总结出的经验我觉得值得单独写一篇文章记录下来。这篇文章不会只讲结论还会把性能问题的根因、优化方案的选型理由、以及落地时容易翻车的细节全部摊开来讲。如果你也在做类终端产品、Web 实时展示工具或者是 WebSocket 高吞吐数据可视化方向这篇文章应该能帮你少走很多弯路。就算你只是对“浏览器里怎么又快又稳地渲染大量文本”这个话题感兴趣后面的内容也值得看一下。2. 根因分析先搞清楚卡顿到底卡在哪里2.1 按需渲染到整页刷新一个错误的“偷懒”设计初版 OrcaTerm 的渲染思路很“朴素”终端缓冲区里有多少行就渲染多少行 DOM 节点。每来一批新数据就整页重绘一次。这个方案在输出量小的时候没什么问题但一旦面对高频日志输出立刻暴露出三个致命弱点。第一个弱点是DOM 节点数量爆炸。终端缓冲区通常保留 1000 到 5000 行历史内容如果每一行都对应一个 div再加上行内 span 包裹的样式节点页面上的 DOM 数量轻松超过 5 万个。浏览器对大量 DOM 节点的布局、绘制、事件绑定都有明显性能上限节点越多每次重排的成本越高。第二个弱点是重排重绘范围失控。每来一批数据我们都直接操作整个容器浏览器会从头到尾计算布局、重新绘制所有可见区域。实际上终端输出往往只影响最后几行这种“全量刷新”的写法浪费了大量计算资源而且随着历史行数增加浪费越来越严重。第三个弱点是渲染频率不受控。WebSocket 推送数据的频率远高于浏览器的帧率一批数据到了就渲染一次导致碰撞问题。大多数数据帧还没被绘制出来就被下一帧覆盖了浏览器反复做无用功主线程被挤爆。2.2 数据管道瓶颈PTY的“洪峰”直接冲垮了前端除了渲染层的问题数据链路同样存在瓶颈。OrcaTerm 后端通过 PTY伪终端对接远程命令前端通过 WebSocket 接收输出流。PTY 输出数据的特点是“突发性强”——一条命令可能在几十毫秒内吐出几百 KB 甚至几 MB 的数据。初版的前端收到每一条消息就立刻追加到缓冲区和 DOM 里这种“收到即渲染”的模式在高吞吐场景下必然会出问题。一方面是后端到前端的协议开销大每条消息都有 JSON 格式的字段冗余另一方面是前端处理数据的粒度太细每次只处理一小段文本导致函数调用次数暴增JavaScript 引擎的调用栈都被这些碎数据处理任务堆满了。我当时做个一个很简单的实验在后端模拟一次性输出 2MB 日志观察前端从收到数据到渲染完成的时间。结果是耗时 3.2 秒整个过程浏览器标签页基本处于“假死”状态。这根本不是量级上的差距而是架构上的失败。2.3 竞品对标性能差在哪里不是玄学是工程债在优化之前我们也拉了几个主流终端工具做了横向对比包括 xterm.js 官方的 demo、Tabby 这种基于 Electron 的现代终端、以及 Windows Terminal 这类原生方案。对比结果很残酷别人滚动 5000 行日志时 FPS 能稳定在 30 帧以上而 OrcaTerm 连 5 帧都保不住。仔细分析后我们发现差距主要集中在三个方面一是别人对渲染区域做了裁剪只绘制可视区域附近的少量行而不是全部历史二是别人的数据管道有合并和节流机制不会让每一次小数据都触发一次渲染三是别人在绘制层面用了更高效的方案比如 Canvas、WebGL而不是纯 DOM 拼接。这些差距不是某一个点的问题而是整条链路都是“债”。3. 渲染层优化从 DOM 泥潭走向 canvas 分层绘制3.1 按需渲染的思路只画用户看得见的行第一刀我们先砍掉 DOM 渲染黑盒里的“全量冗余”。核心思路很简单不管终端缓冲区里有多少历史行画面上其实只需要绘制可视区域内的那几十行。用户滚动查看历史时再动态计算渲染区间和位置。这个策略听起来直白但落地细节非常多。首先是行高缓存——每个字符我们采用固定行高和固定列宽的网格布局这样任意滚动位置都能通过简单的整数运算计算出应该显示哪些行不需要进行 DOM 测量。比如可视区域高度是 600 像素行高是 16 像素那么可视区域对应的行区间就是 600 / 16即 37.5向上取整后我们只需要渲染约 38 行。其次是虚拟滚动坐标换算。我们维护一个总行数计数器用户滚动时用滚动偏移量除以行高得到起始行号再从缓冲区里取对应行的文本和样式信息送入渲染器。整个过程不创建任何冗余 DOM 节点滚动计算量从 O(n) 降到了 O(1)。最后是预渲染缓冲区。为了保证快速滚动时不会露出白屏我们会把可视区域上下各多渲染 5 行作为余量。这样即使滚动速度快到一帧跨好几行用户也基本看不到空白区域。实测下来这个策略对体验的提升非常明显快速滚动时几乎无感知。3.2 Canvas 批量绘制文本每帧只做一次“画布提交”DOM 数量降下来之后还有一个问题即使只显示 38 行如果采用 38 个 div 再加每个 div 里的多个 spanDOM 节点仍然有几百个而且在快速更新时仍然存在布局计算开销。所以我们做了一个更加彻底的决定——放弃 DOM 来渲染正文全部改用 Canvas。Canvas 绘制文本听起来很初级但真正做好终端渲染至少有三个坎要跨过。第一个坎是文本样式切换。终端文本有前景色、背景色、加粗、斜体、下划线、链接高亮等状态。Canvas 的 fillText 本身不支持富文本我们只能逐段扫描行内样式遇到样式变化就切换 fillStyle 和 font再继续绘制。这个过程如果写得粗糙循环里反复设置状态性能会极具下降。第二个坎是背景色填充顺序。终端有一个特殊行为——整行高亮、字符背景色、光标块这些背景必须在文字绘制之前全部画完否则文字会被背景盖住。我们的做法是分两个阶段绘制先绘制所有背景像素遍历每个字符的 bg 属性并 fillRect再统一绘制文字。这样既保证视觉正确性又能减少画笔的状态切换次数。第三个坎是字体缩放与清晰度。Canvas 在高 DPI 屏幕上如果直接使用 CSS 像素绘制文字会发虚。因此我们在绘制前要把 Canvas 的实际分辨率乘以 devicePixelRatio再通过 scale 恢复坐标系。比如在 2 倍屏上canvas.width 设为容器宽度 * 2同时执行 ctx.scale(2, 2)画面就锐利了。上面这些都属于绘制细节更重要的是框架层面的主循环。我们用 requestAnimationFrame 做渲染调度数据到达时只写入显式缓冲区不立即绘制等到下一帧开始前统一从缓冲区取数据、合成样式、一次性按需重绘。这样每帧最多只执行一次完整的绘制操作避免一秒钟触发几十次重绘的乱象。3.3 双缓冲与脏矩形截取别让背景刷出“拉丝”效果做 Canvas 渲染时最容易踩的一个坑是残留重影。因为 Canvas 不会像 DOM 那样自动清除“之前的自己”如果你只绘制了新数据所在的行而没有覆盖掉旧画面屏幕上就会留下文字的残影。这个问题有三种解决路径一是每帧清空整块画布重绘全部可见区域实现简单但大画布全擦的 fillRect 本身也有成本二是只擦除脏矩形区域计算成本很低但矩形合并逻辑容易出 bug三是双缓冲——在内存中维护一个同尺寸的离屏 Canvas绘制到内存画布后再整体拷贝到显示画布。我们最终选的是离屏 Canvas 全量重绘可见区域的方案。因为终端可见区域通常只有 30 到 60 行文本即使全量重绘fillRect 加 fillText 的开销也完全可控但离屏 Canvas 带来的好处是我们的渲染管线可以随时做到“一帧只提交一次合成结果”画面永远不会出现半更新状态也天然规避了重影问题。这里还有一个细节离屏 Canvas 的总尺寸应该与可视区域一致而不是与整个终端缓冲区一致。缓冲区可能有 5000 行但离屏画布只需要覆盖可视高度。比如视野是 38 行行高 16 像素那离屏画布就是 608 像素高。滚动时我们只需把滚动的像素偏移量传给绘制函数让它从正确的位置采样数据。4. 数据管道重构让海量输出像水流一样平稳4.1 合并写缓冲宁等一帧不抢一毫秒渲染层搞定之后我们把目光转向数据管道。前面已经说过WebSocket 推送数据的频率远高于浏览器渲染频率。如果数据一到就立刻塞给渲染器渲染器会被碎片化更新淹没导致每帧都要处理大量小任务性能反而更差。解决方案就是引入合并写缓冲机制。具体实现是维护一个 pendingData 队列WebSocket 收到数据后先把数据追加进这个队列并打一个“有更新”标记触发一次 requestAnimationFrame 调度等到帧回调执行时一次性把队列里所有数据按顺序合并成一个大字符串再交给终端状态解析器。如果一帧内来了 50 次推送我们就只在下一帧合并处理一次将 50 次渲染调用降成 1 次。这个策略的核心价值不是减少代码量而是稳定帧时间和 CPU 占用。实测结果是同样输出 2MB 日志初版从数据到渲染完成需要 3.2 秒合并写缓冲之后降到了 1.1 秒左右而且页面不再“假死”中间用户仍然可以滚动和操作。4.2 二进制协议收编 JSON减少序列化与内存碎片的双重压力初版 WebSocket 数据格式用的是 JSON形如 {type:output,data:...}。这种格式开发方便但存在两个问题一是每一条消息都有固定字段和引号、花括号产生了大量冗余字节二是 JSON.parse 需要为每一条消息新建临时对象高频推送时会产生巨量内存分配进而触发频繁 GC。我们后来把传输协议改成了二进制格式自定义了一个轻量帧结构第一个字节是消息类型随后两个字节是数据长度再后面是 UTF-8 编码的明文内容。前端收到 ArrayBuffer 后通过 DataView 直接读取长度和数据再用 TextDecoder 一次性解码。整个过程几乎零临时对象分配GC 压力大幅降低。有的人可能说现代 JS 引擎的 JSON.parse 已经很快了没必要在协议上抠这么细。但真实场景下当输出频率达到每秒几十次甚至上百次推送时JSON.parse 的累积成本不容小觑。我做过对比在同样 10MB 数据量的压力测试中二进制协议的处理时间比 JSON 快 35% 左右内存峰值降低了约 20%。4.3 输入通道优先级键入响应比什么都重要在终端场景里输出数据量再大也不能让用户输入变得卡顿。用户按下一个键预期的结果是远端命令立刻收到字符并回显这个过程一旦被海量输出阻塞整个终端就没有“可用性”可言。我们在重构数据管道时做了一个细节处理输入通道高优先级分离。浏览器主线程同时处理输出数据解析和输入事件转发如果输出数据量特别大解析任务可能会占据主线程导致 keydown 事件排队等待。为了规避这个问题我们把数据接收与解析从主线程里挪了一部分出去——接收到 ArrayBuffer 后不直接在主线程做逐字符解析而是先存进环形缓冲区再由渲染帧回调按批次解析。这样布局能保证用户输入事件在主线程的响应优先级不被数据解析挤占。实测在输出洪峰情况下输入到服务器回显的延迟依旧能稳定在 60ms 以内。这一点对真实用户来说比渲染速度的绝对值更敏感。5. 终端状态存储缓冲区不只是“一堆字符串”5.1 按行存储的行模型终端缓冲区如果只存一个巨大的字符串做“按行更新”“按行删除”“按行滚动”会非常痛苦。我们的方案是把缓冲区设计成稀疏行数组每一行是一个行对象里面对保存文本内容、样式游标段、行宽度元信息、是否换行等属性。这样做的好处是渲染器按可视区域取数据时可以直接按索引取值不需要做字符串切分。更重要的是终端的某些控制序列比如清屏、删除行、在中间插入行可以按照行的粒度进行 O(1) 级别的数组操作而不是对整个字符串做正则替换。行对象内部保存样式的方式也需要斟酌。如果每个字符都存一个独立样式对象内存占用太大。我们采用的是分段样式表方案每行内部维护一个 TextSegment 数组每个 Segment 记录一个文本连续区间、前景色、背景色、加粗等属性。比如一行 80 个字符前 10 个是红色后 70 个是默认样式我们就只存两个 Segment而不是 80 个样式对象。5.2 大日志滚动的内存护栏限制回看行数压缩历史痕迹日志查看场景往往有滚动查看历史的需求但这和内存保护天然冲突。如果缓冲区无限保留所有输出哪怕一列日志打印几百万行内存也会被撑爆。我们的策略是给回看缓冲设上限——默认 6000 行超过上限时从头部批量淘汰。这个深浅度的选择基于实测5000 到 6000 行日志足够覆盖绝大多数排障场景而且每行平均占用约 300 字节总内存占用控制在 2MB 以内对浏览器压力非常小。但这带来一个交互问题用户正在向上滚动查看历史如果中途缓冲被淘汰他看到的行号就会跳动。为了避免这种“抽风”体验我们做了淘汰保护机制如果当前可视区域停止在某个位置淘汰操作优先从可视区域以下的数据开始尽量不影响用户正在看的内容。如果淘汰范围逼近可视区域头部我们会在左下角提示“历史缓冲已截断”让用户知道数据不完整。5.3 控制序列解析的“状态机改造”终端渲染里还有一个常被忽略的瓶颈——ANSI 转义序列的解析。原始日志里夹杂着大量 \x1b[...m 这样的 CSI 序列如果每次追加数据都重新解析整段文本不仅 CPU 开销大而且会因为半截序列跨消息到达而产生解析错误。我们最后把解析器改成了流式状态机。解析器内部维护一个状态普通文本态、ESC 起始态、CSI 参数收集态、最终字节态。每收到一段新数据就从上一次停留的状态继续推进而不是从头部重新开始。这样既不丢序列也把解析复杂度控制在线性范围。这个改造带来的另一个附带好处是解析结果可以按“区块”粒度返回给渲染器。每个区块对应一段稳定的文本区间和样式信息渲染器可以直接拿这些区块去绘制不需要再二次扫描。6. 性能验证与竞品对标用数据说话的压测实录6.1 压测方法论别只盯着 FPS 一个指标优化做完之后最怕的是自我感觉良好。我们搭建了一套可复现的压力测试环境重点看四个指标FPS帧率、CPU 占用率、从数据到达首帧渲染耗时latency、以及内存占用曲线。场景分为四类一是正常交互输入模拟用户敲命令二是高频小数据输出比如 ping 或 top 命令三是高吞吐日志滚动输出用脚本一次打印 100MB 数据四是超大行文本比如单行 10 万个字符的 minified 文件。每一类场景都在同一台测试机上跑多轮最终取中位数和 P95。只有 P95 好才是真的好因为终端用户一旦遇到一次超过 300ms 的卡顿就会明显感到不适。6.2 优化前后对比数据提升幅度直接上我们内部记录的一组优化前后对比数据以下数据是某次压测的记录浏览器版本为 Chrome 121机器为 2021 款 MacBook Pro场景优化前 FPS优化后 FPSCPU 占用下降首屏渲染耗时高频小数据输出ping206045%380ms → 95ms高吞吐日志滚动5000 行45560%3200ms → 210ms超大行10 万字符单行卡死30--正常交互输入306030%80ms → 15ms大家可以看看“高吞吐日志滚动”这一行首屏渲染耗时从 3200ms 降到 210ms这是一个量级的提升。FPS 从 4 提升到 55说明渲染管线从“直接不可用”变成了“比较流畅”。超大行场景虽然仍没到 60 帧满帧但至少不会卡死已经具备可用性。6.3 与控制变量踩过的一个“假优化”坑在优化的过程中我们还踩过一个假优化的坑在这里提醒大家警惕。当时我们尝试过把 Canvas 的绘制放到 Web Worker 里执行理论上可以把主线程完全解放出来。实现之后运行发现 FPS 没有任何提升反而小幅下降。排查了很久才发现OffscreenCanvas 虽然在 Worker 里可以绘制但最终的 commit 操作transferToImageBitmap仍然需要在主线程上执行。如果浏览器对 OffscreenCanvas 合成路径优化不好反而多了一层数据拷贝的开销。后来我们放弃了这个方案继续沿用主线程 Canvas把精力放在减少主线程内无效计算上。这个经历说明一个问题性能优化不能只看“架构听起来更先进”一定要用压测数据来验证。有些方案在理论上是对的但在实际浏览器实现里并不会有预期收益。7. 常见问题与排查技巧实录7.1 问题速查表现象可能原因排查方向滚动日志时白屏闪烁可视区域外的预渲染余量太小延长上下预渲染行数输入回显延迟高主线程被数据解析堵住检查是否有同步的大字符串操作把解析拆为分批任务长时间使用后内存暴涨历史缓冲行数没有淘汰确认行淘汰策略是否触发是否有事件监听器残留字体模糊发虚Canvas 没有适配 devicePixelRatio设置 canvas.width 容器宽 * dpr终端的背景色铺满整行后文字消失绘制顺序错误必须先绘制背景 fillRect再绘制文字 fillText粘滞感滚动一顿一顿数据解析和渲染没有分离引入合并写缓冲和异步调度多浏览器表现不一致Canvas 字体度量差异统一指定 font-family并在初始化时测量行高7.2 一个真实的线上问题滚动时“屏幕撕裂”上线不久后有用户反馈在快速滚动大日志时画面中间会出现一条横向的分隔线上半部分是旧内容下半部分是新内容肉眼看起来像是屏幕撕裂。排查了很久才发现是浏览器把 Canvas 分成了多个合成层滚动时合成层之间的同步出现了时间差。解决方案是把 Canvas 的 willReadFrequently 属性和 transform 样式做了调整强制浏览器走同一条合成路径。同时我们把每帧绘制结束后的 commit 操作改成在 requestAnimationFrame 回调用统一提交避免中间态被浏览器展示出去。这个问题解决后类似的撕裂现象再也没有出现过。7.3 性能调优建议给同样做终端渲染的同学一些经验如果你正在做类终端产品我的建议是先把数据管道和渲染调度这两层做好再考虑更底层的高级优化。很多人一上来就盯 GPU 加速、WebGL 渲染忽略了数据合并和画布重绘裁剪这些基础能力反而没法获得明显的收益提升。还有一个容易忽略的点终端性能优化要和真实的“用户场景”绑定。比如你做的是运维工具用户最常见的操作是查看大日志和同时打开多个终端标签页那你的压测场景应该围绕多标签并发展开而不是单纯在单个终端里堆数据。工具方面推荐用 Chrome DevTools 的 Performance 面板和 Memory 面板做火焰图分析和堆快照对比再配合 Lighthouse 辅助看整体渲染性能基线。但这些工具只能帮我们发现性能瓶颈在哪个函数、哪条调用链上最终怎么改还是得回到业务场景里去做权衡。8. 回顾与个人体会OrcaTerm 这次渲染优化的全过程让我对“性能优化”这件事有了更深的感知。性能问题通常不像功能 bug 那样有明确的错误信息它是一点点累积起来的工程债。初版为了快速迭代选择全量 DOM 渲染在当时看来是“最省事”的方案但它残酷地决定了后期的天花板。只要架构底子不对后面再怎么打补丁也追不上一开始就选对路线的产品。我在这次优化中最大的心得是三个词分离、裁剪、合并。把数据接收和渲染调度分离让它们各司其职把渲染范围裁剪到用户真正看得见的区域不做无畏的全局消耗把高频的小数据合并成大块再处理减掉无效的计算和内存分配。这三个思路不仅适用于终端渲染做任何高吞吐实时界面都值得参考。另外性能优化一定要形成数据闭环。我们每完成一个子优化就立刻跑压测记录数据而不是等所有改动都做完了才测试。这样哪一步优化带来了收益、哪一步是无效改动全局一目了然。现在 OrcaTerm 的每一个渲染相关的 PR都会附带性能测试的对比记录这已经成为了我们的开发习惯。如果你也在优化自己的终端工具或者正被类似的高吞吐渲染问题折磨我希望这篇内容能给你带来一些具体的参考。最后再分享一个小技巧做终端渲染优化时不要只盯着“大日志”场景多试试“高频小输出”场景——比如 top 命令或者连续 ping 的输出。这种场景下最容易暴露渲染调度的效率问题也最能反映出终端工具的日常使用体验。
