约翰·卡马克的实时图形性能心态

为什么卡马克的方法依然重要

约翰·卡马克常被当作游戏引擎界的传奇，但真正有用的不是神话，而是可重复的习惯。这不是去模仿某个人的风格或把一切归结为“天才之举”。而是一些实用原则，能在截止期与复杂度叠加时，可靠地带来更快、更流畅的软件。

用通俗的话说性能工程

性能工程就是让软件在真实硬件和真实条件下达到速度目标，同时不破坏正确性。这并不是“无论如何都要变快”。而是一套有纪律的循环：

• 决定什么叫“足够快”
• 测量时间到底花在哪儿
• 有目的地只改一件事
• 验证你改进了正确的指标

这种思维在卡马克的工作中屡见不鲜：用数据争论、让改动可解释、偏好可维护的方案。

为什么实时图形会暴露真实情况

实时图形无情，因为它每帧都有死线。错过了，用户立刻就感受到卡顿、输入延迟或运动不平滑。其他软件可以靠队列、加载界面或后台任务掩盖低效；渲染器不能协商：要么及时完成，要么就没完成。

这就是为什么这些教训能推广到游戏之外。任何有严格延迟要求的系统——UI、音频、AR/VR、交易、机器人——都能从按预算思考、理解瓶颈、避免突发峰值中受益。

你将收获什么

你会得到可应用于自身工作的检查表、启发式规则和决策模式：如何设定帧时间（或延迟）预算，如何先分析再优化，如何选出“那一个要修的点”，以及如何防止回退，让性能成为日常而不是临发布前的恐慌。

用帧时间预算思考，而不是靠感觉

卡马克式的性能思考从一个简单转变开始：别把“FPS”当作主要单位，改用帧时间。

FPS 是倒数（“60 FPS”听着好，“55 FPS”听着也差不多），但用户体验由每帧需要多久驱动——更重要的是，这些时间的稳定性。一口气从 16.6 ms 跳到 33.3 ms 是立刻可见的，即便平均 FPS 看起来还不错。

帧时间 vs FPS（为什么帧时间更胜一筹）

• FPS 掩盖波动。 两个版本都能“平均 60 FPS”，但一个可能因为偶发的 40–60 ms 帧而卡顿。\
• 帧时间映射到工作量。 每一毫秒都是可以归因到系统的 CPU/GPU 工作片段。\
• 目标更清晰。 “保持低于 16.6 ms”是个具体的要求；“感觉流畅”不是。

预算：你真正花的是什么

一个实时产品有多个预算，而不仅仅是“渲染更快”：

• CPU 时间（游戏逻辑、动画、裁剪、提交 draw call）
• GPU 时间（着色、后处理、过度绘制、分辨率）
• 内存（占用、峰值、碎片、流式缓冲）
• 加载时间（启动、关卡加载、着色器编译、流式停顿）

这些预算会相互影响。用 CPU 密集的批处理来省 GPU 时间可能会适得其反；减少内存占用可能会增加流式或解压的开销。

示例：60 FPS 时的 16.6 ms

如果目标是 60 FPS，你的总预算就是 每帧 16.6 ms。一个粗略分配可能是：

• CPU：7 ms（仿真、游戏逻辑、可见性）
• GPU：9 ms（渲染 + 后处理）
• 操作系统/驱动 + 缓冲：~0.6 ms

如果 CPU 或 GPU 超出预算，就会错帧。这就是团队为什么说“CPU 受限”或“GPU 受限”——不是标签，而是决定下一个毫秒现实来自哪里的方法。

“足够快”是产品需求

重点不是追逐诸如“在高端 PC 上最高 FPS”这类虚荣指标，而是定义对你的受众什么是足够快——硬件目标、分辨率、电池与热控、输入响应——然后把性能当作可以管理和捍卫的明确预算。

先剖析：测量后再决定

卡马克的默认动作不是“立刻优化”，而是“验证”。实时性能问题充斥着看似合理的猜测——GC 暂停、“慢着色器”、“太多 draw call”——但在你的构建和你的硬件上大多数猜测都是错的。分析是用证据替代直觉的办法。

先测量（别先猜）

把性能分析当作一等公民，而不是临时救火工具。捕获帧时间、CPU 与 GPU 时间线，以及能解释它们的计数（三角形、draw call、状态更改、分配、如果能拿到就记录缓存未命中）。目标是回答一个问题：时间到底花在哪儿？

一个有用的模型：在每个慢帧中，总有一件事是限制因子。也许是 GPU 在一个重代价的通道卡住了，或 CPU 在动画更新上卡住，或主线程在同步上停滞。先找到那个约束；其他都是噪声。

像科学家一样迭代

有纪律的循环能防止你胡乱折腾：

• 用可重复的场景和相机路径测量基线
• 只改一件事
• 重新测量并记录差异

如果改动没有明显改进，就假定它没帮到忙——因为它很可能无法在下次内容更新时存活。

提防安慰剂式优化

性能工作特别容易自我欺骗：

• 基准错误： 测试场景不一致、调试构建、后台任务、热节流、vsync 差异
• 确认偏见： “感觉更快”但没有帧时间数据支持
• 均值误导： 更好的平均值可能掩盖更糟的尖刺

先分析能让你的努力更聚焦、权衡更有依据、改动在评审中更容易被辩护。

瓶颈：找出真正慢的那一件事

实时性能问题看起来混乱，因为所有事同时发生：游戏逻辑、渲染、流式、动画、UI、物理。卡马克的本能是扫除噪声，识别当前主导限制——那件设置帧时间的事情。

常见瓶颈类别

大多数变慢都落在几个桶里：

• CPU 受限： 主线程（或关键 worker）来不及完成工作——游戏逻辑、draw-call 提交、物理、动画求值。\
• GPU 受限： GPU 完成一帧需要太久——昂贵着色器、像素过多、复杂后处理、复杂几何。\
• 内存受限： 带宽/延迟成为限制——缓存未命中、糟糕数据布局、随机访问多、复制大缓冲。\
• I/O 受限： 资源流式、着色器编译、解压、文件读写、网络等待。

关键不是贴标签，而是选择正确的杠杆去撬。

在改写任何东西前的快速诊断方法

几项快速实验能告诉你谁在掌控：

• 分辨率缩放测试： 降低渲染分辨率（或强制动态分辨率）。如果帧时间大幅改善，很可能是 GPU/像素 受限；如果变化不大，就看 CPU 或非像素的 GPU 工作。\
• 功能切换： 逐一关闭阴影、SSR、AO、粒子或昂贵通道。明显的变化会揭示时间花在哪儿。\
• 插桩与捕获： 使用内建计时器、CPU 分析器和 GPU 捕获查看毫秒究竟落在哪些地方。

“一大块石头”原则

你很少能通过在十个系统上各减 1% 赢得胜利。找到每帧重复出现的最大开销，先干掉它。移除单个 4 ms 的罪魁往往比数周的微优化更值钱。

瓶颈会移动

当你修好大石头，下一个最大的问题就会显现。这是正常的。把性能工作当作一个循环：测量 → 改动 → 重新测量 → 重新排序。目标不是完美的性能剖面，而是朝着可预测帧时间稳定前进。

平滑才是王道：尖刺、卡顿与尾延迟

平均帧时间看起来可以，但体验仍可能很糟。实时图形是按最糟糕时刻来评判的：爆炸时掉帧、进入新房间的卡顿、打开菜单的顿挫。这就是尾延迟——罕见但频繁到能被注意到的慢帧。

为什么尾部比均值更重要

一个大多数时候在 16.6 ms（60 FPS）跑的游戏，但每隔几秒就飙到 60–120 ms，会让人感觉“坏”，即使平均值仍显示 20 ms。人对节奏敏感。一帧的长时间打破输入可预测性、相机运动和视听同步。

常见尖刺来源

尖刺通常来自不均匀分布的工作：

• 垃圾回收或内存页错误导致短暂暂停
• 着色器即时编译与流水线创建触发的延迟
• 资源流式突然需要解压、上传或文件 I/O
• 操作系统调度或后台任务窃取 CPU 时间（或频率/热控变化）

减少卡顿的策略

目标是让昂贵工作变得可预测：

• 预计算：能离线构建的就离线构建（着色器、烘焙数据、查表）。
• 预热：在加载屏或受控的热身场景中编译着色器、创建 pipeline、触及关键资源。
• 摊薄：把流式/解压/上传分散到多帧而不是一次性完成。
• 限制每帧工作：施加时间预算（例如“本帧流式不超过 2 ms”），其余延后。

记录并可视化尾部

别只画平均 FPS 线。记录每帧时间并可视化：

• 帧时间直方图，看簇与异常值
• 百分位（p95、p99、p99.9）显式追踪尾部
• 尖刺标记并关联事件（GC 开始、着色器编译、资源加载）

如果你不能解释最差 1% 的帧，那就不能说你真正解释了性能。

明确权衡（质量 vs 速度 vs 复杂性）

当你不再假装能同时拥有一切时，性能工作会变简单。卡马克的风格是让团队把这种权衡说清楚：我们得到什么、付出什么、谁会感受到差别？

把坐标轴说清楚（和真实成本）

大多数决策落在几个轴上：

• 质量：视觉保真、仿真精度、输入手感
• 速度：帧时间、加载时间、编译时间、迭代时间
• 内存：显存、内存、带宽
• 复杂性：调试更难、边界条件更多、测试负担更重
• 发布时间：进度风险、集成风险、团队焦点

如果改动提升了一个轴但秘密增加了三个成本，把它记录下来。“这是增加 0.4 ms GPU 和 80 MB VRAM 来换取更柔和的阴影”是可用的说明。“看起来更好”不是。

定义“足够好”的阈值

实时图形不是追求完美，而是稳定达到目标。达成约定阈值：

• 参考机的最低 FPS / 最大帧时间
• 可接受的最差尖刺（不只是平均）
• 各平台的内存上限

一旦团队达成比如“在基线 GPU、1080p 下目标是 16.6 ms”的共识，争论就变得具体：这个功能能否让我们保持在预算内，还是必须在别处降级？

偏好可逆的决定

不确定时，选可撤销的方案：

• 功能开关给有风险的效果
• 可缩放的设置（低/中/高）并映射到实际成本
• 老旧硬件的回退路径

可逆性保护进度。你可以先发布安全路径，把激进方案放在开关之后。

优化用户能感知到的内容

避免过度工程化那些看不见的胜利。1% 的平均提升很少值得一个月的复杂化——除非它消除卡顿、修复输入延迟或防止严重内存崩溃。优先处理玩家立刻能感受到的改动，其余的再等等。

工程纪律：正确性让速度变容易

当程序是“正确的”时，性能工作会简单许多。相当一部分“优化时间”其实在追踪那些看起来像性能问题的正确性 Bug：意外的 O(N²) 循环、由于标志未重置导致的渲染通道执行两次、逐渐增长的内存泄漏、把竞态变为随机卡顿的条件竞争。

把正确性当作性能工具

一个稳定、可预测的引擎能让测量干净。如果行为在多次运行中变化，你就不能信任分析，最终会优化噪声。

有纪律的工程实践能加速性能工作：

• 清晰不变量： 定义必须始终成立的条件（例如“每个可见对象只提交一次”、“GPU 资源在飞行中不被修改”、“帧图无环”）。
• 调试构建中的验证： 添加断言和轻量检查，早期报错——在错误状态变成神秘卡顿之前。验证缓冲大小、状态转换，以及每帧分配是否保持在已知限制内。

让性能 Bug 可按需复现

很多帧时间尖刺是“海森堡式错误”：你加日志或用调试器一看它就消失。解药是确定性复现。

构建小而受控的测试装置：

• 最小测试场景，隔离某个功能（阴影、粒子、UI、流式）
• 固定相机路径 和脚本化输入，让每次运行可比
• 锁定设置（分辨率、质量等级、尽量固定的时间步）以移除变量

当卡顿出现时，你要能一键重放 100 次——不是一句模糊的“有时在 10 分钟后发生”。

少改动，多学习

性能工作受益于小、可审查的改动。大规模重构会同时带来多个失败模式：回归、新分配、隐藏的额外工作。精简的 diff 更容易回答唯一重要的问题：帧时间到底因为什么改变了？

纪律并非官僚主义，而是保持测量可信的方式，使优化变得直接而非迷信。

与机器协作：数据、缓存与开销

实时性能不仅关乎“更快的代码”。更重要的是以让 CPU 与 GPU 高效运行的方式组织工作。卡马克反复强调一个简单真理：机器是字面意义上的——它喜欢可预测的数据，讨厌可避免的开销。

数据导向思维：让内存更容易被读取

现代 CPU 非常快——直到它们在等内存。如果数据散落在许多小对象中，CPU 就在追指针而非做数学运算。

一个有用的比喻：不要为十样东西跑十次购物。把它们放在一个购物车里，一次走完货架。在代码中，这意味着把常用值放在一起（通常是数组或紧凑的结构体），这样每次缓存行拉来都是有用数据。

分配模式：小额 churn 会变成大问题

频繁分配会带来隐藏成本：分配器开销、内存碎片，以及当系统需要整理时的不确定暂停。即便每次分配都“很小”，持续不断也会成为你每帧支付的税。

常见修复是刻意且乏味的：重用缓冲、对象池化、在热点路径使用长期分配。目标不是聪明，而是稳定。

批处理：在优化数学之前先减少开销

大量帧时间可能消耗在记账工作上：状态更改、draw call、驱动工作、系统调用、线程协调。

批处理是渲染与仿真的“一个大购物车”版本。不要发出许多微小操作，而是成组处理类似工作，减少穿越昂贵边界的次数。经常情况下，减少开销比微调着色器或内层循环更能提升性能——因为机器花更少时间准备工作，更多时间在真正工作上。

简单就是一种性能策略

性能工作不仅仅是更快的代码——也是更少的代码。复杂性有代价：Bug 更难定位、修复需更细致测试、迭代变慢、回归通过很少用到的路径混入。复杂性还常常带来运行时开销（额外分支、分配、缓存未命中、同步），这些在为时已晚才显现。

复杂性的隐性税

一个“巧妙”的系统看起来优雅，直到你到最后期限而某个地图、某个 GPU 或某个设置组合上出现帧峰值。每个额外的特性开关、回退路径和特殊情况都会成倍增加你需要理解和测量的行为数量。复杂性不仅浪费开发者时间，还常在运行时悄悄增加开销。

偏好你能讲清楚的方案

一个好规则：如果你不能在几句话内向队友解释性能模型，那你很可能无法可靠地优化它。

简单方案有两个优势：

• 更易分析和推理（变量更少）
• 减少“未知的未知”，避免小改动引发意外变慢

“删代码”是真正的优化工具

有时最快的路径是删掉功能、裁剪选项或把多个变体合并为一个。更少的功能意味着更少的代码路径、更少的状态组合、减少性能悄然退化的地方。

删掉代码也是质量改进：最好的 Bug 是那个你通过删除生成该 Bug 的模块而消除的 Bug。

重构还是补丁？快速决策清单

补丁（外科式修复）当：

• 你定位到具体热点并且小改动能有可测量的提升
• 系统稳定且被广泛使用；改架构有引入新回归风险
• 需要一个适配当前发布周期的安全改进

重构（简化结构）当：

• 分析指出开销分布在很多调用点或层级上
• 你在同一片区域反复触发性能回归
• 修改该代码需要部落级知识才能安全改动
• 你能删除或合并路径，从而减少概念数量

简单不是“不够雄心”，而是在压力下选择仍可理解的设计——那时性能最重要。

防止回退：把性能变成习惯

性能工作只有在你能发现它回退时才会长期保持。这就是性能回归测试的意义：用可复现的方法检测新改动是否让产品变慢、更不流畅或更占内存。

不同于功能测试（回答“它是否工作？”），回归测试回答“感觉速度是否保持不变？”一个构建可以 100% 正确，但如果额外增加 4 ms 帧时间或加载时间翻倍，发布依然可能很糟。

一个轻量可用的工作流程

你不需要实验室来开始——只要一致性。

挑一小组基线场景代表真实使用：一个 GPU 重场景、一个 CPU 重场景和一个“最差情况”压力场景。保持它们稳定并脚本化，让相机路径和输入运行一致。

在固定硬件（已知 PC/主机/开发套件）上运行测试。如果你更换驱动、操作系统或频率设置，记录下来。把硬件/软件组合当作测试夹具的一部分。

把结果存入有版本历史的记录：提交哈希、构建配置、机器 ID 和测得指标。目标不是一个完美数字，而是可信的趋势线。

CI 友好的指标

偏向难以争论的指标：

• 帧时间百分位（p50/p95/p99），而不是只看平均 FPS。百分位能呈现卡顿与长尾。\
• 峰值内存（和分配峰值）。内存爬升通常先于崩溃显现。\
• 加载时间（冷启动与场景切换），因为玩家注意到的是秒数而非微小优化。

定义简单阈值（例如：p95 帧时间不得回退超过 5%）。

捕捉到回退后怎么办

把回退当作有负责人和截止日的 Bug。

首先，二分定位引入它的变更。如果回退阻塞发布，快速回滚并带着修复再落地。

修复后，增加护栏：保留测试、在代码中加注释并记录期望的预算。习惯才是胜利——性能成为维护项，而不是“以后再做”的任务。

发布复杂系统：性能、截止与现实

“发布”不是一个日历事件——它是工程要求。一个只在实验室良好运行、或只有经过一周手工调优才满足帧时间的系统，还没有完成。卡马克的心态把现实世界的约束（硬件多样性、混乱内容、不可预测的玩家行为）从一开始就当作规范的一部分。

发布意味着选择必须成立的条件

接近发布时，完美不如可预测重要。用明白无误的术语定义不可妥协项：目标 FPS、最差帧时间尖刺、内存上限和加载时间。任何违反这些的都当作 Bug，而不是“打磨”。这把性能工作从可选优化重塑为可靠性工作。

优先修复玩家真实感知的问题

并非所有变慢同等重要。先修复对用户可见度最高的问题：

• 卡顿与长尖刺在感知质量上通常比稳定但略慢的渲染更关键。\
• 菜单顿卡、流式弹出与输入延迟往往比平均 FPS 的小幅下降更伤体验。\
• 常见场景（激战、镜头转动、特效密集时）的回归应优先于罕见的角落案例。

剖析纪律在这里回本：你不是在猜哪个问题“看起来大”，你是基于测量的影响来选择。

分阶段变更并默认走安全路径

晚期的性能工作风险高，因为“修复”可能带来新成本。采用分阶段发布：先落地插桩，再把改动放在功能开关，最后逐步扩大暴露范围。默认设置优先保证性能——即便会略微降低视觉质量——尤其是自动检测配置时。

如果你发布多个平台或档位，把默认视为产品决策：看起来稍逊色总好过不稳定。

向非技术干系人传达约束

把权衡翻译为可预期的结果：“这个效果在中端 GPU 每帧要多花 2 ms，会让激战时掉到 60 FPS 以下。”提供可选方案而非说教：降低分辨率、简化着色器、限制生成速率或接受更低的目标。把约束表述为带明确用户影响的选择，会更易被接受。

今天就能应用的实用清单

你不需要新引擎或重写来采用卡马克式的性能思维。你需要一个可重复的循环，让性能可见、可测试且不易被意外破坏。

可重复循环（测量 → 预算 → 隔离 → 优化 → 验证 → 文档）

1. 测量： 捕获基线（平均值、p95、最差尖刺）以及关键子系统的帧时间。

2. 预算： 为 CPU 与 GPU（若内存紧张也包括内存）设定每帧预算。把预算写在功能目标旁。

3. 隔离： 在最小场景或测试中复现开销。如果无法复现，就无法可靠修复。

4. 优化： 每次只改一件事。偏好能减少工作的改动，而不仅仅是“让它更快”。

5. 验证： 重新分析、比较差异，并检查质量回归与正确性问题。

6. 文档： 记录改动、为何有效、未来需监控的点。

立即可用的经验法则

• 优化最大那块，而不是你最烦的猜测。
• 先追尖刺再追均值（如果用户感到卡顿的话）。
• 如果你解释不了成本，你还没拥有这个功能。
• 偏好可预测的开销，胜过罕见的最坏爆炸。
• 事先为新工作预算（CPU ms、GPU ms、内存、带宽）。
• 避免隐藏的每对象/每帧循环，会随内容规模放大。
• 把性能测试当作“完成”的一部分，而不是临发布前的匆忙。

简单的“性能评审”模板（合并前）

• 功能摘要： 改了什么、启用了什么
• 目标平台 & 设置：（例如，主机性能模式、中端 PC）
• 预算： CPU __ ms，GPU __ ms，内存 __ MB
• 基线 vs 之后： 平均 / ms，p95 / ms，最差尖刺 / ms
• 瓶颈假设： CPU 还是 GPU？证据：
• 测试场景 & 重现步骤：
• 风险与护栏： 可能回归的点，哪些指标会报警
• 回滚计划： 如何禁用或优雅降级

Koder.ai 在此工作流中的角色

如果你想在团队内部把这些习惯工具化，关键是减少摩擦：快速实验、可复现的测试装置和便捷回滚。

Koder.ai 可以在构建外围工具时帮忙——不是替代引擎本身。它是一个 vibe-coding 平台，能生成真实、可导出的源码（Web 前端 React；后端 Go + PostgreSQL；移动端 Flutter），让你快速搭建内部仪表盘来展示帧时间百分位、回归历史和“性能评审”清单，并随着需求通过对话迭代。快照与回滚也很契合“改一件事，重新测量”的循环。

如果你想要更多实用指导，可浏览 /blog 或查看团队如何在 /pricing 上将这些工具化。