8.1 性能评估：每个节点花在哪

8.1 性能评估：每个节点花在哪

本节摘要：着色器成本的三大来源是纹理采样、逐像素运算、变体数量。本节给出按成本分层的节点速查表、一套三数字估算流程，并用全书案例实测示范"先估算、再实测、后定点"的评估节奏。

成本的三驾马车

一张图跑起来，GPU 在三处为它花钱。纹理采样：每个 Sample 节点每次执行都要访问显存，是移动端最贵的单项操作；三平面映射为什么贵，就是因为它把一次采样变成三次。逐像素运算：算术节点（乘加、幂、三角函数）在片元阶段每个像素都要执行，单个不贵，但屏幕占比乘节点数就是总量；Power 这类幂运算与三角函数比乘加贵几倍。变体数量：7.3 节的乘法账单，体现在包体与构建，不体现在单帧。三者的花钱场景不同——帧率看前两个，包体与构建看第三个。

图：常用节点与操作的成本分层

三数字估算流程

评估一张图，三十秒内算三个数。数一：采样次数——图里 Sample 类节点出现几次、是否在分支或三平面上翻倍。数二：运算档位——过一遍节点列表，按上面的分层归类，重点数第二档以上出现的次数。数三：变体量级——关键字数量与作用域（7.3 节公式），心算一遍。

拿全书案例练手。溶解案例（6.4 骨架版）：两次采样（噪声加主贴图）、第一档运算约十次加第三档一次 Smoothstep、无关键字——三个数是"二采、轻运算、零变体"，典型健康图。水面案例（6.5 完整版）：顶点侧每顶点两路正弦（第二档乘顶点数），片元侧双法线采样加一次主采样（三采）、第二档若干——采样是它的成本大头，移动端优先收敛法线采样。全息案例（5.3）：零贴图采样（纯计算）、第二档密集（菲涅尔幂加闪烁正弦）——它的账在运算而非采样，若要优化先降幂次数与合并闪烁链。

实测工具与两台机器

估算给方向，实测给结论。两个工具各管一段。帧调试器（Frame Debugger）：把一帧拆成一串绘制调用，能看到每个物体用了哪个着色器、走了哪个渲染路径——定位"场景里谁在用我的图、画了几次"。渲染分析器（Rendering Profiler）：看 CPU 与 GPU 每帧耗时，GPU 侧的瓶颈通常看"渲染主线程"或"GPU 耗时"曲线——改图前后各录一段，对比才有意义，裸看绝对值没有判断力。

移动端补两条现实。其一，编辑器数字不代表真机：桌面 GPU 的算力吞吐与移动端差一个数量级以上，方向性结论（谁比谁贵）可以信编辑器，绝对值必须真机测。其二，移动端要看"带宽"而不只是"算力"：高分辨率渲染目标上反复采样大贴图，带宽先爆，表现为发热降频，帧率曲线反而看不出问题——贴图压缩与分辨率控制比省几个乘法重要得多。

💡 一个定点的土办法：怀疑某段节点链在吃帧率，把它的输出临时断开接一个黑色常量（该段计算会被编译器剔除），帧率立涨说明猜对了段，再细查内部——二分法排查，比整图重做省一个下午。

屏占比：成本公式的隐藏变量

同样的图，成本随屏占比线性变化——这个变量在估算时经常被漏掉。一个占屏百分之十的特效与一个全屏的后处理感效果，成本差十倍。由此推出两个工程规则：规则一，全屏级效果（大面积雾、屏幕波动）的成本门槛要比单体效果严三倍，采样次数与运算档位都要压一档。规则二，小屏占比的效果可以适度奢侈（角色特写的精致细节），因为绝对代价小。估算时把"屏占比乘单像素成本"当成完整公式，宽严标准自然就分层了。

问题：两个功能相同的节点，怎么选便宜的？

优先用节点预览的统计与经验分层判断，拿不准时做一次对照实验：两张临时图各放一个节点，图形检查器里对比统计数字。几个常见的"等价不等价"组合记一下：Power 取整次幂（二、四次）可用连乘替代更便宜；Normalize 在已知输入是单位向量时可省略；Saturate 与 Clamp 到零一区间等价时用 Saturate（编译器优化更充分）。单次差距都是小数目，但在片元阶段乘上像素数与复用次数后，热路径上的选择开始有意义。

建立项目的成本红线

把 8.1 节的分层落到项目规范：普通道具图上限（例如采样不超过三次、第二档运算不超过十次）；主角与特效图放宽一档；全屏效果再单独设限。红线写在团队文档里，评审时对着红线过一遍——数字红线的好处是把"我觉得有点贵"的主观讨论变成"超出红线哪一项"的客观对话。红线的具体数值随项目硬件目标调整，机制比数值重要。

把三数字流程练成肌肉动作

三数字估算（采样数、运算档位、变体量级）要成为肌肉动作，需要一个量化练习：拿本册五个案例（滚动、描边、全息、溶解、水面）各做一次完整估算并写下来，再与 8.1 正文的参考答案对照。五个案例练完，估算误差通常能压到正负一次采样以内——这时你对"一张图贵不贵"的判断就不再依赖工具，扫一眼节点列表三秒钟出结论。这个能力的价值在评审与排期场景：需求还没开工，成本量级已经给出，技术方案的选择因此提前。

问题：顶点动画的成本为什么按顶点数而不是按像素数算？

因为计算发生在顶点阶段——每个顶点执行一遍，与屏幕上有多少像素无关。同一张水面图，铺满全屏和缩成小池塘，顶点成本完全相同（网格密度没变），片元成本却天差地别。这个差异决定了优化抓手不同：顶点动画贵就减网格密度或简化波形；片元效果贵就减采样与运算。8.1 正文的三数字默认指片元侧，顶点侧的账单独用"顶点数乘顶点运算量"估算——两条账分开记，才不会把优化力气花错阶段。

成本分层的一个反直觉点

第四档里"逐像素循环迭代"的警示值得单独解释：图形学里很多高级算法（多层级模糊、迭代光线步进）依赖循环，节点图本身没有循环节点，循环要么靠 Custom Function 实现、要么靠手工展开（同一段链复制三遍接三遍）。手工展开三遍就是三倍成本，且完全没有循环的"早退出"能力——循环在 GPU 上跑多少次是所有实例取最大值决定的，一个需要十次的像素会拖累整批。这就是迭代类算法在移动端慎用的底层原因：成本由最坏情况决定，而不是平均值。

本节要点回顾

• 三驾马车：采样、逐像素运算、变体，帧率看前两、包体看第三。
• 四档分层：算术免费、三角轻量、采样偏重、迭代与全屏谨慎。
• 三数字估算：采样数、运算档位、变体量级，三十秒给方向。
• 实测要对比：改前改后各录一段，移动端结论必须真机复测。

成本会算了，下一节看图与管线的交界：URP 设置怎么配、跨管线移植怎么走、构建时要注意什么。