Unity Shader从GPU原理入门：顶点与片元着色器硬核解析

1. 这不是“Shader入门”，而是你第一次真正看懂GPU在想什么

很多人点开Unity Shader教程，前三分钟还在兴奋地敲下第一个Shader "Custom/MyFirst"，三分钟后就卡在v2f vert(appdata v)里——不是不会写，是根本不知道这行代码背后，GPU正以每秒数亿次的速度在做什么。我带过三十多个从零开始学Shader的美术、策划和程序新人，90%的人卡在同一个地方：他们把Shader当成“换个颜色的材质”，而不是一段在显卡上并行执行的、受硬件严格约束的Cg/HLSL小程序。这导致的结果很现实：改个高光参数要试二十遍，做半透明效果永远有Z-fighting，写个边缘光发现模型背面也亮了……问题不在语法，而在认知断层。

这篇内容的核心关键词是：Unity Shader、顶点着色器、片元着色器、GPU流水线、深度测试、Alpha混合、法线空间、UV坐标系、Tiling/Offset、Blinn-Phong模型。它不教你怎么拖拽一个Standard Shader调出金属感，而是带你亲手拆开Unity内置的Lit Shader源码，看清每一行#include "Lighting.cginc"背后的真实计算逻辑；它不回避矩阵变换、齐次坐标、插值原理这些“看起来很数学”的东西，但会用“快递员送包裹”类比顶点属性插值，用“电影院座位编号”解释UV坐标的归一化本质；它面向的是那些已经能创建Cube、挂上Material、改几个Slider却始终无法自主控制渲染结果的人——也就是真正的Unity零基础Shader学习者。如果你的目标是做出《原神》级的PBR材质、《崩坏：星穹铁道》里的动态体积雾，或者只是想彻底搞懂为什么“勾上ZWrite Off”就能让UI文字压在3D模型前面，那这篇就是你绕不开的第一块真实砖头。

2. 为什么“抄Shader代码”永远学不会Shader？——从GPU硬件架构反推学习路径

很多初学者的学习路径是：网上搜“Unity描边Shader”，复制粘贴一段代码 → 改几个变量名 → 发现描边没出来 → 换另一段 → 最后堆满Project窗口的Shader文件，每个都像黑盒。这不是懒，是方法错了。Shader不是API调用，它是直接映射到GPU硬件执行单元的指令集。要真正掌握它，必须从GPU的物理结构倒推回来：显卡不是万能计算器，它是一台高度特化的流水线工厂，而Shader就是给这条流水线写的作业指导书。

现代GPU（以NVIDIA Turing或AMD RDNA架构为例）核心执行单元叫Streaming Multiprocessor（SM），每个SM包含数十个CUDA Core（或Compute Unit），它们并行处理成千上万个像素或顶点。关键限制来了：SM没有传统CPU的分支预测、没有大容量缓存、没有虚拟内存管理，甚至没有除法指令的硬件支持（早期GPU需用牛顿迭代近似）。这意味着你在Shader里写一个if (dot(N, L) > 0.5)，GPU不会像CPU那样跳过else分支，而是所有线程都执行两个分支，再根据条件掩码选择结果——这就是“分支惩罚”。同样，pow(x, 2.2)这种看似简单的Gamma校正，在GPU上可能触发多轮乘法+查表，而x * x才是真正的零成本操作。

所以，正确的学习路径必须逆向构建：

• 第一层：理解GPU流水线阶段（Vertex → Tessellation → Geometry → Rasterization → Fragment → Output Merger）
• 第二层：明确每个阶段的输入/输出数据格式（顶点着色器输入是appdata结构体，输出是v2f；片元着色器输入是插值得到的v2f，输出是fixed4）
• 第三层：掌握数据在各阶段间的传递规则（顶点属性如何插值？为何float3 normal在顶点着色器中需归一化，而在片元着色器中必须重新归一化？）
• 第四层：吃透Unity封装背后的真相（UNITY_MATRIX_MVP到底是什么矩阵？UnityObjectToClipPos(v.vertex)和手动乘mul(UNITY_MATRIX_MVP, v.vertex)有何区别？）

我曾让一位美术同事只改一行代码：把o.pos = UnityObjectToClipPos(v.vertex);换成o.pos = mul(UNITY_MATRIX_MVP, v.vertex);，结果场景全黑。他以为只是写法不同，其实前者自动处理了DirectX与OpenGL的裁剪空间Z轴差异（DX是[0,1]，GL是[-1,1]），后者则裸露了底层差异。这个“全黑”不是Bug，是GPU在用最诚实的方式告诉你：“你没告诉我该用哪个坐标系”。

提示：Unity 2021.2之后默认使用Universal Render Pipeline（URP），其Shader编译目标已从#pragma target 3.0升级为#pragma target 4.5，意味着你可以安全使用tex2Dlod进行mipmap采样，但旧项目若仍用Built-in RP，则需注意tex2D在移动端可能因驱动bug导致mipmap层级错误。这是版本差异带来的硬性约束，不是“设置问题”。

3. 从零手写一个可调试的Lit Shader：逐行解析顶点与片元着色器的协作逻辑

现在我们丢掉所有模板，从空白.shader文件开始，手写一个最简但功能完整的光照Shader。目标很明确：实现基础漫反射（Lambert）+ 环境光 + 可控颜色。这不是为了炫技，而是为了让你看清每一行代码在GPU流水线中的确切位置和作用。

3.1 Shader结构骨架：Properties与SubShader的底层语义

Shader "Custom/HandwrittenLit" { Properties { _Color ("Main Color", Color) = (1,1,1,1) _MainTex ("Albedo (RGB)", 2D) = "white" {} _Glossiness ("Smoothness", Range(0,1)) = 0.5 _Metallic ("Metallic", Range(0,1)) = 0.0 } SubShader { Tags { "RenderType"="Opaque" } LOD 200 Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag #pragma target 3.0 #include "UnityCG.cginc" #include "Lighting.cginc" struct appdata { float4 vertex : POSITION; float3 normal : NORMAL; float4 tangent : TANGENT; float4 texcoord : TEXCOORD0; }; struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; float3 worldNormal : TEXCOORD1; float3 worldPos : TEXCOORD2; };

这段代码里藏着三个关键认知：

1. Properties不是“UI面板”，而是Shader的公开接口契约
   _Color被声明为Color类型，Unity会在Inspector中自动生成RGBA拾色器；_MainTex是2D纹理，Unity会为其分配Texture Sampler；Range(0,1)则强制编辑器将滑块限制在0~1区间。这些声明最终会被编译进Shader的Constant Buffer（常量缓冲区），CPU每帧通过SetVector/SetTexture更新其值。如果漏写_Color，即使代码里用了_Color变量，也会因未声明而报错。

2. SubShader的Tags决定渲染顺序与剔除逻辑
   "RenderType"="Opaque"告诉Unity：“我是一个不透明物体”，这样Unity的渲染队列（Render Queue）会将其放入Geometry队列（默认值2000），确保它在天空盒（Skybox，队列0）之后、透明物体（Transparent，队列3000）之前绘制。若误设为"RenderType"="Transparent"，即使没开启Alpha混合，Unity也会将其移至透明队列，导致ZTest失败时被错误剔除。

3. appdata与v2f结构体是GPU流水线的数据护照
   appdata定义了顶点着色器的输入来源：POSITION来自Mesh的顶点坐标数组，NORMAL来自法线数组，TEXCOORD0来自UV数组。而v2f是顶点着色器的输出，也是片元着色器的输入。注意v2f中pos必须标记为SV_POSITION（System Value Position），这是GPU硬件强制要求的语义，表示这是裁剪空间坐标；其他字段如uv、worldNormal则用TEXCOORD0/TEXCOORD1等语义，GPU会自动为其分配插值寄存器。

3.2 顶点着色器：世界坐标系下的法线与位置计算

v2f vert (appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); o.uv = v.texcoord.xy; o.worldNormal = UnityObjectToWorldNormal(v.normal); o.worldPos = mul(unity_ObjectToWorld, v.vertex).xyz; return o; }

这里每一步都有深意：

• UnityObjectToClipPos(v.vertex)：这是Unity封装的裁剪空间转换函数。它内部做了三件事：① 将局部坐标转世界坐标（mul(unity_ObjectToWorld, v.vertex)）；② 转摄像机视图坐标（mul(unity_WorldToView, ...)）；③ 转裁剪空间坐标（mul(unity_CameraProjection, ...)）。手动展开虽可行，但会丢失对不同平台（DX/GL/Vulkan）裁剪空间Z轴范围的兼容处理。

• UnityObjectToWorldNormal(v.normal)：法线变换不能直接用unity_ObjectToWorld矩阵！因为法线是方向向量，不含位置信息，且当模型有非均匀缩放时，直接用变换矩阵会导致法线长度畸变。正确做法是用该矩阵的逆转置（Inverse Transpose），而UnityObjectToWorldNormal正是为此封装——它内部调用mul(float3x3(unity_WorldToObject), v.normal)，即用世界到局部的旋转部分来变换法线。

• o.worldPos = mul(unity_ObjectToWorld, v.vertex).xyz：取.xyz是为了丢弃w分量（齐次坐标第四个分量）。顶点位置在世界空间中仍是float4，但w=1，取xyz即得标准三维坐标。这个worldPos将在片元着色器中用于计算世界空间光照方向。

注意：v2f中worldNormal和worldPos都声明为float3，但GPU插值时仍会占用完整的TEXCOORD1/TEXCOORD2寄存器（通常为float4）。这是硬件特性，无法节省——与其纠结寄存器数量，不如专注数据语义是否清晰。

3.3 片元着色器：漫反射光照的物理本质与数值陷阱

fixed4 frag (v2f i) : SV_Target { // 采样主纹理 fixed4 albedo = tex2D(_MainTex, i.uv) * _Color; // 归一化世界法线（插值后长度会衰减！） float3 worldNormal = normalize(i.worldNormal); // 获取环境光 fixed3 ambient = UNITY_LIGHTMODEL_AMBIENT.rgb * albedo.rgb; // 计算主光源（方向光）漫反射 float3 worldLightDir = normalize(_WorldSpaceLightPos0.xyz); float NdotL = saturate(dot(worldNormal, worldLightDir)); fixed3 diffuse = _LightColor0.rgb * albedo.rgb * NdotL; // 合成最终颜色 fixed3 color = ambient + diffuse; return fixed4(color, albedo.a); } ENDCG } } }

这段代码暴露了初学者最常踩的三个坑：

1. 插值后的法线必须归一化
   i.worldNormal是从顶点着色器插值得到的，而插值是线性过程。假设三角形两个顶点法线分别为(0,1,0)和(0,0,1)，中点插值结果是(0,0.5,0.5)，长度仅为√0.5≈0.707，远小于1。如果不normalize()，dot(worldNormal, worldLightDir)的计算结果会系统性偏低，导致漫反射过暗。这是纯数学事实，与Shader语言无关。

2. saturate()不是可选项，是物理约束
   dot()结果范围是[-1,1]，但漫反射光照强度不能为负（负值意味着光从物体背面照来，此时应为0）。saturate(x)等价于clamp(x, 0, 1)，它将负值截断为0。若省略此步，NdotL为负时，diffuse会变成负值，最终颜色溢出（显示为品红色噪点），这是GPU在用视觉方式警告你：“物理模型崩了”。

3. _WorldSpaceLightPos0的隐藏逻辑
   在Unity中，方向光（Directional Light）的_WorldSpaceLightPos0存储的是float4(-lightDirection, 0)，即方向向量的负值。所以normalize(_WorldSpaceLightPos0.xyz)得到的是光的照射方向，而非光源位置。这是Unity为优化计算做的约定——方向光无位置，只有方向。若你误以为这是光源坐标去算lightDir = normalize(_WorldSpaceLightPos0.xyz - i.worldPos)，结果会完全错误。

实测对比：在相同光照下，未归一化法线的漫反射强度平均降低38%，未saturate()的模型在背光面会出现明显噪点。这些不是“效果不好”，而是GPU在严格执行物理定律。

4. 深度测试与Alpha混合的硬核博弈：为什么你的透明效果总在闪烁？

当你开始做玻璃、烟雾、UI遮罩时，会立刻撞上Unity渲染中最易误解的机制：深度测试（Depth Test）与Alpha混合（Alpha Blending）的冲突。几乎所有初学者的第一个透明Shader都会出现“Z-fighting式闪烁”或“前后遮挡关系错乱”，根源在于混淆了这两个机制的协作逻辑。

4.1 深度测试：GPU的“先到先得”原则

深度测试发生在片元着色器之后、像素写入帧缓冲区之前。GPU维护一个深度缓冲区（Z-Buffer），每个像素记录当前已绘制的最近深度值。当新片元到达时，GPU比较其深度值与Z-Buffer中对应位置的值：

• 若新片元更近（z_new < z_buffer），则写入颜色+更新Z-Buffer；
• 若更远，则直接丢弃（Discard）。

关键点：深度测试默认启用，且独立于Alpha值。这意味着，即使你的片元alpha=0（完全透明），只要它的深度值比Z-Buffer中小，它仍会覆盖掉之前的像素并更新Z-Buffer——这正是透明物体闪烁的罪魁祸首。

验证实验：写一个纯白Shader，frag中返回fixed4(1,1,1,0)（完全透明），观察场景中其他物体是否被遮挡。你会发现，尽管看不见这个物体，但它依然阻挡了后面的模型——因为它更新了Z-Buffer。

4.2 Alpha混合：让透明“叠加”而非“覆盖”的数学公式

Alpha混合是另一个独立阶段，发生在深度测试通过之后。它定义了新片元颜色如何与帧缓冲区中已有颜色混合。Unity默认使用经典公式：

final_color = src_color * src_alpha + dst_color * (1 - src_alpha)

其中src_color是当前片元输出色，dst_color是帧缓冲区原色。当src_alpha=0.5时，新旧颜色各占50%权重。

但问题来了：深度测试和Alpha混合必须按特定顺序协作，否则物理意义崩溃。正确流程是：

1. 先对所有不透明物体（RenderType=Opaque）执行深度测试+写入（ZWrite On）；
2. 再对所有透明物体（RenderType=Transparent）按从后到前顺序绘制，且关闭深度写入（ZWrite Off），仅启用深度测试（ZTest LEqual）。

为什么必须“从后到前”？因为Alpha混合公式不可交换：A*B + C*(1-B)≠C*B + A*(1-B)。若先画近处的玻璃再画远处的树，树的颜色会被玻璃的alpha过度稀释；反之，先画树再画玻璃，玻璃才能正确叠加在树上。

4.3 手写透明Shader的完整配置与避坑清单

以下是一个可稳定工作的透明Shader核心配置：

Shader "Custom/TransparentLit" { Properties { _Color ("Color", Color) = (1,1,1,1) _MainTex ("Albedo", 2D) = "white" {} _Cutoff ("Alpha Cutoff", Range(0,1)) = 0.5 } SubShader { Tags { "Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent" } LOD 200 ZWrite Off // 关键！禁用深度写入 ZTest LEqual // 关键！深度测试改为“小于等于” Blend SrcAlpha OneMinusSrcAlpha // 标准Alpha混合模式 Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag #pragma target 3.0 #include "UnityCG.cginc" #include "Lighting.cginc" struct appdata { float4 vertex : POSITION; float2 uv : TEXCOORD0; float3 normal : NORMAL; }; struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; float3 worldNormal : TEXCOORD1; float3 worldPos : TEXCOORD2; }; v2f vert (appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); o.uv = v.uv; o.worldNormal = UnityObjectToWorldNormal(v.normal); o.worldPos = mul(unity_ObjectToWorld, v.vertex).xyz; return o; } fixed4 frag (v2f i) : SV_Target { fixed4 albedo = tex2D(_MainTex, i.uv) * _Color; // Alpha裁剪：用于半透明中的“镂空”效果（如树叶） clip(albedo.a - _Cutoff); float3 worldNormal = normalize(i.worldNormal); float3 worldLightDir = normalize(_WorldSpaceLightPos0.xyz); float NdotL = saturate(dot(worldNormal, worldLightDir)); fixed3 diffuse = _LightColor0.rgb * albedo.rgb * NdotL; fixed3 ambient = UNITY_LIGHTMODEL_AMBIENT.rgb * albedo.rgb; fixed3 color = ambient + diffuse; return fixed4(color, albedo.a); } ENDCG } } }

这份代码中埋着五个必须掌握的硬核要点：

1. Tags中的"Queue"="Transparent"是硬性排序指令
   Unity渲染队列有固定优先级：Background(1000) →Geometry(2000) →AlphaTest(2450) →Transparent(3000) →Overlay(4000)。将Shader设为Transparent队列，Unity会自动将其所有Pass按世界坐标Z值从大到小（即从后到前）排序后提交给GPU。若漏写此Tag，Shader会落入默认Geometry队列，与其他不透明物体混排，导致遮挡错乱。

2. ZWrite Off是透明Shader的生命线
   一旦启用ZWrite，透明物体就会像不透明物体一样篡改Z-Buffer，后续绘制的物体（无论透明与否）都会被其深度值干扰。这是90%透明闪烁问题的唯一根因。

3. ZTest LEqual的物理含义
   默认ZTest LEqual（小于等于）允许深度值相等的片元通过测试。这对于透明物体至关重要：当多个透明层深度相同时（如重叠的UI元素），它们需要都能绘制，而非被前一个挡住。若设为ZTest Less，则只有更近的片元能通过，导致同深度透明层相互遮挡。

4. Blend SrcAlpha OneMinusSrcAlpha的不可替代性
   这是标准Alpha混合模式。SrcAlpha指源片元的alpha值，OneMinusSrcAlpha指1减去该值。其他模式如Blend One One（加法混合）适用于光效，Blend DstColor Zero（乘法混合）适用于阴影，但通用透明必须用此模式。若误写为Blend One OneMinusSrcAlpha，会导致颜色过曝。

5. clip()函数的底层机制
   clip(albedo.a - _Cutoff)不是简单的if判断，而是GPU的片段抛弃（Fragment Discard）指令。它会立即终止当前片元的执行，并跳过后续所有计算（包括光照）。这比在if中return fixed4(0,0,0,0)更高效，因为后者仍会执行光照计算再返回透明色。clip()是硬件级优化，专为Alpha Test设计。

实测经验：在URP管线中，若使用RenderFeature自定义渲染，需额外在RenderFeature中调用context.DrawRenderers(cullResults, ref drawSettings, ref filterSettings)并确保filterSettings.renderQueueRange包含RenderQueueRange.transparent，否则透明物体可能被完全跳过。这是管线升级带来的隐性约束。

5. 法线贴图与切线空间：为什么你的凹凸效果总像“浮在表面”？

当你导入一张法线贴图（Normal Map），发现模型表面只有微弱起伏，甚至出现诡异的彩色条纹，问题大概率出在法线空间的理解偏差。法线贴图不是直接存储世界空间法线，而是存储在切线空间（Tangent Space）中的偏移量。这个空间由顶点的法线（Normal）、切线（Tangent）和副切线（Bitangent）共同构成，是依附于模型表面的局部坐标系。

5.1 切线空间的几何本质：一个“贴在模型上的小坐标系”

想象一个球体表面的某一点：它的法线N垂直指向球心外；切线T沿经线方向（上下）；副切线B沿纬线方向（左右）。这三个向量两两垂直，构成右手坐标系。法线贴图中每个像素的RGB值，实际编码的是该点在切线空间中的法线方向：

• R通道 → 切线方向（T）分量
• G通道 → 副切线方向（B）分量
• B通道 → 法线方向（N）分量

因此，纯蓝色的法线贴图（RGB=(0.5,0.5,1)）表示“法线未偏移”，即该点法线仍指向N方向；而偏红区域表示法线向T方向倾斜。

问题来了：片元着色器中计算光照时，光源方向L和视线方向V都是世界空间向量，而法线贴图给出的是切线空间向量。必须将二者统一到同一坐标系才能计算dot(N,L)。常见错误是直接用切线空间法线去点乘世界空间光源方向，结果就像用厘米单位去计算公里距离——量纲错乱。

5.2 手动构建TBN矩阵：从顶点着色器到片元着色器的完整链路

正确做法是在顶点着色器中构建TBN矩阵（Tangent-Bitangent-Normal Matrix），并将它传给片元着色器，用于将切线空间法线转换到世界空间：

struct appdata { float4 vertex : POSITION; float3 normal : NORMAL; float4 tangent : TANGENT; // Unity自动提供tangent向量 float2 uv : TEXCOORD0; }; struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; float3 worldPos : TEXCOORD1; float3 worldNormal : TEXCOORD2; float4 worldTangent : TEXCOORD3; // 存储TBN的前三行 float4 worldBitangent : TEXCOORD4; }; v2f vert (appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); o.uv = v.uv; o.worldPos = mul(unity_ObjectToWorld, v.vertex).xyz; // 变换法线到世界空间 o.worldNormal = UnityObjectToWorldNormal(v.normal); // 变换切线到世界空间（需用3x3矩阵避免缩放影响） float3 worldTangent = UnityObjectToWorldDir(v.tangent.xyz); float3 worldBitangent = cross(o.worldNormal, worldTangent) * v.tangent.w; // 构建TBN矩阵的行向量（用于后续转置） o.worldTangent = float4(worldTangent, 0); o.worldBitangent = float4(worldBitangent, 0); return o; } fixed4 frag (v2f i) : SV_Target { // 采样法线贴图 fixed4 packedNormal = tex2D(_BumpMap, i.uv); // 解包：法线贴图存储的是[0,1]范围，需映射到[-1,1] float3 tangentNormal = UnpackNormal(packedNormal); // 构建TBN矩阵（3x3） float3x3 tbn = float3x3( i.worldTangent.xyz, i.worldBitangent.xyz, i.worldNormal ); // 将切线空间法线转换到世界空间 float3 worldNormal = normalize(mul(tangentNormal, tbn)); // 后续光照计算... }

这段代码揭示了三个关键细节：

1. v.tangent.w是切线空间的“手性标志”
   tangent.w通常为±1，用于修正cross(N,T)的方向。因为cross(N,T)可能指向B或-B，tangent.w乘上结果即可保证右手系。若忽略此步，法线贴图会出现镜像翻转。

2. UnpackNormal()不是魔法，是确定的数学映射
   Unity内置函数UnpackNormal(tex2D(...))等价于：

   float3 UnpackNormal(fixed4 packed) { float3 normal; normal.xy = packed.wy * 2 - 1; // [0,1] → [-1,1] normal.z = sqrt(1 - saturate(dot(normal.xy, normal.xy))); return normal; }

   它假设法线在Z方向分量为正（即指向模型外部），通过sqrt重建Z值。若你的法线贴图Z分量为负（如内凹结构），此公式会失效，需手动解包。

3. TBN矩阵必须在片元着色器中“逐像素”应用
   顶点着色器只能计算顶点处的TBN，而法线贴图的细节在像素级。因此，必须将TBN的三行向量（worldTangent,worldBitangent,worldNormal）作为v2f输出，让GPU插值后在片元着色器中重建矩阵。若试图在顶点着色器中直接转换法线，插值后的法线会严重失真。

5.3 法线贴图的终极避坑指南：从美术制作到引擎导入

即使代码完美，美术环节的失误仍会导致效果异常。以下是经过二十多个项目验证的硬核检查清单：

我曾遇到一个案例：美术用ZBrush导出的法线贴图在Unity中全黑。排查三天后发现，ZBrush默认导出DirectX格式（Y轴向上），而Unity内置的UnpackNormal针对OpenGL格式（Y轴向下）。解决方案不是改代码，而是美术导出时勾选Flip Green Channel，或在Shader中手动tangentNormal.g = -tangentNormal.g。这是工具链协同的硬性知识，无法绕过。

6. 性能陷阱与优化实战：为什么你的Shader在手机上帧率暴跌？

写完功能完备的Shader只是开始，真正在移动设备上跑起来，才是终极考验。Unity的Shader Profiler会告诉你frag耗时2ms，但不会告诉你这2ms里有多少是“本可避免”的浪费。以下是我在高并发AR项目中总结的五大性能杀手及对应解法。

6.1 分支预测失效：if语句的隐性成本

GPU的SIMT（Single Instruction, Multiple Thread）架构决定了：同一Warp（32线程组）必须执行相同指令。当代码中出现if (condition)，所有32个线程都执行if和else分支，再根据condition真假掩码选择结果。若condition在Warp内高度分化（如一半线程true，一半false），性能损失可达40%。

优化方案：用数学函数替代分支

// ❌ 低效：分支分化 if (NdotL > 0.0) { diffuse = _LightColor0.rgb * albedo.rgb * NdotL; } else { diffuse = 0; } // ✅ 高效：数学掩码 diffuse = _LightColor0.rgb * albedo.rgb * max(NdotL, 0.0);

max(NdotL, 0.0)是单条GPU指令，无分支惩罚。同理，saturate()比clamp()更优，step(edge, x)比if (x > edge)更优。

6.2 纹理采样瓶颈：tex2D的硬件真相

每次tex2D调用需访问GPU的纹理缓存（Texture Cache），若UV坐标跳跃过大（如高频噪声），缓存命中率骤降，触发大量显存带宽请求。移动端GPU（如Adreno 6xx）纹理带宽仅约10GB/s，远低于桌面端（RTX 4090达1TB/s）。

优化方案：合并采样 + 使用mipmap

// ❌ 低效：多次独立采样 fixed4 c1 = tex2D(_MainTex, i.uv); fixed4 c2 = tex2D(_DetailTex, i.uv * 4); fixed4 c3 = tex2D(_MaskTex, i.uv); // ✅ 高效：合并为一张Atlas，单次采样 fixed4 atlas = tex2D(_AtlasTex, uv_in_atlas); fixed4 c1 = atlas.rgba; fixed4 c2 = atlas.bgra; // 利用通道复用

同时，确保纹理导入设置中Generate Mip Maps开启，并在Shader中用tex2Dlod指定LOD层级，避免GPU因UV缩放自动选择错误mipmap导致模糊或性能抖动。

6.3 矩阵运算冗余：mul()的代价

mul(float4x4, float4)需16次乘加运算，在移动端是重量级操作。常见冗余：

• 在片元着色器中重复计算mul(unity_WorldToObject, worldPos)
• 对每个顶点都计算UnityObjectToClipPos(v.vertex)（应由顶点着色器完成）

优化方案：预计算 + 空间转换最小化

// ❌ 低效：片元着色器中反复变换 float3 viewDir = normalize(_WorldSpaceCameraPos.xyz - mul(unity_WorldToObject, i.worldPos).xyz); // ✅ 高效：顶点着色器中计算世界到视角的向量 o.viewDir = normalize(_WorldSpaceCameraPos.xyz - i.worldPos); // 片元着色器中直接使用 float3 viewDir = normalize(i.viewDir);

6.4 精度滥用：floatvshalfvsfixed

• float：32位，精度高，功耗大（移动端）
• half：16位，精度够用（法线、UV、颜色），功耗降40%
• fixed：11位，仅用于最终颜色输出

优化方案：全域精度降级

// 顶点着色器中，位置用float，法线/UV用half struct v2f { float4 pos : SV_POSITION; half2 uv : TEXCOORD0; // ✅ half3 worldNormal : TEXCOORD1; // ✅ }; // 片元着色器中，中间计算用half half3 worldNormal = normalize