企业官网建设流程全解析

1. 人物渲染的性能账本：先搞清楚瓶颈在哪

人物渲染这件事，在Unity项目里属于那种“不做优化也能跑，但一上真机就露馅”的典型场景。我见过太多项目，编辑器里跑得丝滑流畅，打包到移动端一测，帧率直接腰斩，发热量飙升，玩家玩十分钟就开始烫手。问题出在哪？绝大多数情况下，不是你的模型面数太高，也不是贴图太大，而是渲染管线的每一个环节都在悄悄吃掉你的性能预算，而你根本没有意识到。

先说说人物渲染为什么特殊。场景里的静态物件，你可以烘焙光照、可以合批、可以做各种静态优化，但人物不一样——人物要动，要换装，要播放动画，要响应各种交互。这意味着人物的渲染几乎全是动态的，动态就意味着无法享受静态合批的红利，意味着每帧都要重新计算蒙皮、重新提交绘制命令、重新处理光照。一个场景里如果有十个角色同屏，每个角色又有独立的材质和贴图，那DrawCall的数量会直接爆炸。

我拿一个实际项目举例。之前做过一个ARPG手游，主角加三个队友再加五个敌人，同屏九个人物。初始版本在骁龙865上跑，帧率只有28帧左右，GPU占用率高达85%。用Unity Profiler一查，问题一目了然：DrawCall 320+，其中人物相关的占了将近200个。每个角色身上有武器、头发、身体、披风、饰品等七八个独立Mesh，每个Mesh又用了不同的材质球，材质球之间还没法合批。这就是典型的“美术资源制作时没考虑性能，程序后期擦屁股”的局面。

所以人物渲染优化的第一步，不是急着去改Shader或者换管线，而是先建立性能账本。你得清楚地知道，当前的人物渲染到底消耗了多少资源，这些资源花在了哪里，哪些是必要的，哪些是可以砍掉的。没有这个账本，所有的优化都是盲人摸象。

1.1 用Profiler定位人物渲染的真实开销

Unity Profiler是绕不开的工具，但很多人用不对。打开Profiler之后，不要只看Overall那一栏的帧率曲线，那玩意儿只能告诉你“卡了”，不能告诉你“为什么卡”。你要做的是切到Rendering区域，看几个关键指标：SetPass Calls、Batches、Triangles、Vertices。这四个数字基本上就能勾勒出人物渲染的性能画像。

SetPass Calls是重中之重。每一次SetPass Call意味着GPU要重新配置渲染状态，切换Shader、切换材质、切换光照参数。这个操作在移动端尤其昂贵，因为移动GPU的架构决定了它的状态切换开销比桌面GPU大得多。我的经验值是，中低端移动设备上，SetPass Calls控制在80以内比较安全，超过120就会明显感觉到压力。人物渲染如果贡献了超过40个SetPass Call，那就必须动手了。

Batches是另一个关键指标。很多人分不清Batches和SetPass Calls的关系，简单说，一个Batch可能包含多个SetPass Call，也可能一个SetPass Call对应多个Batch。Unity的合批机制会把使用相同材质、满足合批条件的Mesh合并成一个Batch提交。但人物渲染的麻烦在于，蒙皮网格（SkinnedMeshRenderer）的合批条件非常苛刻，不同骨骼层级的网格基本没法合批。

Triangles和Vertices反映的是几何复杂度。移动端上，单个人物的三角面数建议控制在3万到5万之间，如果是主角可以放宽到8万，但同屏多个角色时，总面数最好不要超过30万。超过这个数，GPU的顶点处理单元就会成为瓶颈，尤其是在低端机上。

提示：Profiler里看到的数字是编辑器环境下的，真机上的表现会有差异。一定要用Development Build加上Autoconnect Profiler，在真机上跑一遍再下结论。

1.2 从渲染管线角度理解人物渲染的成本构成

Unity现在有三套渲染管线：Built-in、URP、HDRP。人物渲染优化在不同管线下的策略差异很大。Built-in管线是老项目的主流，但它的前向渲染路径对多光源的处理非常粗糙，每个逐像素光源都会增加一个Pass，人物身上如果有多个光源影响，SetPass Call直接翻倍。URP管线对移动端友好得多，它的单Pass前向渲染可以把多个光源合并到一个Pass里处理，但前提是你得把Additional Lights设置为Per Pixel，并且控制好光源数量。HDRP管线主要用于高端PC和主机，移动端基本不用考虑。

人物渲染的成本构成，大致可以拆成四块：几何处理成本、蒙皮计算成本、材质渲染成本、后处理成本。几何处理成本取决于顶点数量和网格复杂度，蒙皮计算成本取决于骨骼数量和蒙皮质量设置，材质渲染成本取决于Shader复杂度和纹理采样次数，后处理成本则取决于人物是否参与了景深、Bloom、SSAO等效果。

这四块成本里，蒙皮计算是最容易被忽视的。Unity默认的蒙皮质量是4根骨骼影响一个顶点，但很多美术在做模型的时候，权重刷得不够精细，导致Unity自动计算时用了更多的骨骼影响。你可以在Project Settings的Quality设置里把Skin Weights改成2 Bones，对于大多数手游来说，2根骨骼的视觉效果和4根骨骼几乎没有区别，但蒙皮计算量直接减半。

2. 模型与材质层面的优化实操

模型和材质是人物渲染的基础，基础没打好，后面的优化都是事倍功半。我见过太多项目，程序在那边拼命优化DrawCall，结果美术丢过来一个新模型，面数直接翻倍，贴图从2K变成4K，之前的优化全部白费。所以人物渲染优化必须从源头抓起，建立一套美术资源规范，并且用工具去强制执行。

2.1 模型面数与LOD的合理规划

人物模型的面数分配是有讲究的。不是简单地“面数越少越好”，而是要把面数花在刀刃上。头部和手部是玩家视线最集中的区域，可以适当多分配一些面数；躯干和腿部可以大幅削减；头发如果是片状结构，面数可以很少，但透明排序会带来额外的Overdraw成本。

我的经验值是，手游主角的模型面数控制在5万三角面以内，NPC控制在2万以内，同屏小怪控制在5000以内。这个数字不是绝对的，要根据目标设备的GPU性能来调整。如果是面向高端机型，可以适当放宽；如果是面向低端机型，还得再砍。

LOD是人物渲染优化的标配。Unity的LOD Group组件可以让你为同一个模型设置多个细节层级，根据相机距离自动切换。但很多项目做了LOD却没用对，要么是LOD切换距离设置不合理，导致近距离也在用低模；要么是LOD模型的材质没有统一，导致切换时SetPass Call反而增加。

LOD的切换距离应该根据屏幕占比来定，而不是单纯看距离。一个简单的计算方法是：当模型在屏幕上的高度小于屏幕高度的10%时，切换到LOD1；小于5%时，切换到LOD2；小于2%时，直接Cull掉。这样可以根据实际视觉效果来平衡性能和质量。

2.2 材质合并与纹理图集的实际操作

材质合并是降低SetPass Call最直接的手段。原理很简单：把多个使用不同贴图但Shader相同的材质，合并成一个使用图集的材质。这样原本需要多次SetPass Call的绘制，现在只需要一次。

具体操作上，你需要把人物身上各个部件的贴图（身体、头发、武器、饰品）打包到一张大图里，然后调整每个部件的UV，让它们对应到大图的不同区域。Unity有官方的Sprite Atlas工具，但对于3D模型来说，更常用的是第三方工具或者手动在建模软件里处理。

这里有个坑要注意：图集的分辨率不是越大越好。一张4096x4096的图集，在移动端上占用的显存是64MB（RGBA32格式），如果人物有多个这样的图集，显存直接爆炸。我的建议是，单个人物的图集分辨率控制在2048x2048以内，如果部件太多，可以拆成两张1024x1024的图集，而不是一张2048x2048的。

注意：图集打包时要注意纹理的Mipmap设置。如果图集里的不同区域需要不同的Mipmap级别，可能会出现远处部件模糊、近处部件清晰的情况。解决办法是给图集设置合适的Mipmap Bias，或者对关键部件单独使用一张小图集。

2.3 Shader简化与变体剔除

人物Shader的复杂度直接影响GPU的像素处理成本。很多项目的人物Shader里塞了各种效果：边缘光、高光、法线、自发光、细节贴图、遮罩贴图……每多一个纹理采样，GPU就要多花一份带宽。移动端的GPU带宽是极其宝贵的资源，尤其是在高分辨率下。

我的做法是，把人物Shader拆成几个档次：高品质档用于主角和近距离特写，保留所有效果；中品质档用于队友和重要NPC，砍掉边缘光和细节贴图；低品质档用于远处的小怪和群众，只保留最基本的漫反射和简单光照。然后根据Quality Settings和距离动态切换。

Shader变体剔除也是必须做的。Unity在打包时会把所有可能的Shader变体都编译进去，导致包体膨胀和加载时间增加。你可以在Project Settings的Graphics设置里，手动剔除不需要的变体。比如，如果你的项目不支持雾效，就把FOG相关的变体全部剔除；如果不支持Lightmap，就把LIGHTMAP相关的变体剔除。

3. 渲染管线的深度调优

模型和材质优化完之后，接下来要动的是渲染管线本身。这部分涉及的内容比较底层，但效果往往立竿见影。我见过一个项目，光是调整了渲染队列和排序策略，帧率就提升了8帧。

3.1 前向渲染与延迟渲染的选择

Unity的Built-in管线支持前向渲染和延迟渲染两种路径。延迟渲染的优势是光源数量不影响DrawCall，但它的缺点是移动端支持不好，而且不支持MSAA，透明物体处理也麻烦。人物渲染通常涉及大量透明部件（头发、披风、特效），所以移动端上基本只能用前向渲染。

前向渲染下，每个逐像素光源都会增加一个Pass。如果你的场景里有多个光源影响人物，SetPass Call会成倍增加。解决办法有两个：一是减少逐像素光源的数量，把不重要的小光源改成顶点光源或者SH光源；二是使用URP管线的单Pass前向渲染，它可以把多个光源合并到一个Pass里处理。

URP的单Pass前向渲染需要在URP Asset里设置Additional Lights为Per Pixel，并且把Max Additional Lights Per Object控制在4以内。超过4个光源，URP会自动降级处理，但降级的过程本身也有开销。所以最好的办法还是从源头控制光源数量。

3.2 渲染队列与排序策略的调整

Unity的渲染队列决定了物体的绘制顺序。不透明的物体从前到后绘制，透明的物体从后到前绘制。这个顺序直接影响Overdraw的量。人物渲染中，头发、披风、翅膀等透明部件如果排序不当，会导致大量的Overdraw，GPU的像素填充率会被白白浪费。

调整渲染队列的方法很简单，在Shader里设置Queue标签，或者在材质面板上手动调整Render Queue的值。但要注意，渲染队列的调整会影响整个项目的渲染顺序，不能随意乱改。我的建议是，把人物的不透明部件放在Geometry队列（2000），把头发和披风放在AlphaTest队列（2450），把特效放在Transparent队列（3000）。

对于头发这种多层透明的部件，还可以使用Alpha Test加Alpha Blend的混合方案。Alpha Test不需要排序，但边缘会有硬边；Alpha Blend边缘柔和，但需要排序。折中的做法是，头发的内层用Alpha Test，外层用Alpha Blend，这样既能减少排序压力，又能保证视觉效果。

3.3 GPU Instancing与SRP Batcher的启用

GPU Instancing可以让多个使用相同材质和网格的物体，在一次DrawCall里绘制出来。对于人物渲染来说，如果场景里有多个相同的小怪，GPU Instancing可以大幅降低DrawCall。但要注意，GPU Instancing要求材质相同、网格相同，而且不能有蒙皮。所以它只适用于那些没有骨骼动画的静态人物，或者使用顶点动画的人物。

SRP Batcher是URP管线下的一个优化机制，它可以把使用相同Shader变体的不同材质合批处理。SRP Batcher的合批条件比GPU Instancing宽松得多，不需要网格相同，只需要Shader变体相同。这意味着，即使人物穿着不同的装备、使用不同的贴图，只要Shader变体一致，就能被SRP Batcher合批。

启用SRP Batcher的方法很简单，在URP Asset里勾选SRP Batcher选项即可。但要注意，SRP Batcher对Shader的写法有要求，所有的材质属性必须放在CBUFFER里，否则无法合批。如果你用的是自定义Shader，需要按照URP的规范来写。

4. 动画与蒙皮计算的性能压榨

人物渲染的性能开销，有很大一部分不在渲染本身，而在动画和蒙皮计算上。一个复杂的角色，骨骼数量可能上百，每帧都要计算蒙皮矩阵，这个计算量在移动端上相当可观。

4.1 骨骼数量与蒙皮质量的平衡

Unity默认的蒙皮质量是4根骨骼影响一个顶点，但你可以把它降到2根甚至1根。对于手游来说，2根骨骼的视觉效果已经足够好了，除非是主角的特写镜头，否则玩家根本看不出区别。把Skin Weights从4 Bones改成2 Bones，蒙皮计算量直接减半，CPU占用率能降5%到10%。

骨骼数量也要控制。一个手游角色的骨骼数量建议控制在30到50根之间，超过80根就会明显影响性能。如果美术给的模型骨骼太多，可以让他在建模软件里合并一些不重要的骨骼，比如手指的骨骼可以合并成一根，脚趾的骨骼可以直接删掉。

4.2 动画更新频率与Culling策略

Unity的Animator组件默认每帧更新，但很多角色的动画其实不需要这么高的更新频率。你可以把Animator的Update Mode改成Animate Physics或者Unscaled Time，或者手动控制更新频率。对于远处的NPC，可以把动画更新频率降到15帧甚至10帧，视觉效果几乎没有区别，但CPU占用率能降不少。

Animator Culling Mode也是一个重要的优化点。默认情况下，Unity会一直更新Animator，即使角色在屏幕外。把Culling Mode改成Cull Update Transforms或者Cull Completely，可以让屏幕外的角色停止动画更新。Cull Update Transforms会停止动画计算但保留Transform更新，Cull Completely则完全停止更新。对于完全不可见的角色，用Cull Completely最省性能。

4.3 使用Job System与Burst加速蒙皮计算

如果你的项目对性能要求极高，可以考虑用Job System和Burst编译器来加速蒙皮计算。Unity的Mesh API提供了Mesh.GetVertexBuffer和Mesh.SetVertexBuffer，你可以把蒙皮计算从主线程移到Job里，利用多核CPU并行计算。

具体做法是，用C# Job System写一个蒙皮计算的Job，把每个顶点的蒙皮矩阵计算并行化。然后用Burst编译器编译这个Job，生成高度优化的机器码。实测下来，这种方式可以把蒙皮计算的耗时降低50%以上，尤其是在骨骼数量多、顶点数量大的情况下效果更明显。

但要注意，Job System和Burst的使用有一定门槛，需要你对C#的Job System有一定的了解。而且，这种方式会绕过Unity的SkinnedMeshRenderer，你需要自己管理网格的更新和渲染。如果项目工期紧，不建议轻易尝试。

5. 常见问题与排查技巧实录

人物渲染优化过程中，会遇到各种各样的问题。有些是技术层面的，有些是流程层面的。我把这些年踩过的坑整理了一下，希望能帮你少走弯路。

5.1 人物渲染性能问题速查表

5.2 那些年我踩过的坑

第一个坑是图集打包后UV错乱。有一次我把人物的身体、头发、武器打包到一张图集里，结果发现武器的UV对不上，贴图显示错位。排查了半天才发现，是建模软件导出时的UV坐标和Unity的UV坐标系不一致导致的。解决办法是在建模软件里把UV的V轴翻转一下，或者在Unity里用脚本批量修正UV。

第二个坑是LOD切换时材质丢失。我给人物做了三个LOD层级，结果发现切换到LOD1时，人物的衣服变成了白色。原因是LOD1的模型用了不同的材质球，而我没有把材质球正确赋值。解决办法是，在LOD Group组件里，确保每个LOD层级的Renderer都正确引用了对应的材质。

第三个坑是SRP Batcher不生效。我按照URP的规范写了自定义Shader，但SRP Batcher的合批数量一直是0。排查后发现，是Shader里的一个材质属性没有放在CBUFFER里，导致SRP Batcher无法识别。解决办法是，把所有需要在Inspector里调整的属性都放在CBUFFER里，并且确保CBUFFER的名字和URP的规范一致。

第四个坑是动画Culling导致角色卡住。我把Animator的Culling Mode改成了Cull Completely，结果发现角色从屏幕外回到屏幕内时，动画没有恢复，角色卡在了原地。原因是Cull Completely会完全停止Animator的更新，包括状态机的转换。解决办法是，对于需要保持状态的角色，用Cull Update Transforms而不是Cull Completely。

5.3 真机调试的注意事项

编辑器里的性能数据只能作为参考，真机上的表现才是最终标准。真机调试时，有几个点要特别注意。

第一，关闭编辑器的VSync。编辑器的VSync会限制帧率，导致你看到的性能数据不准确。在Quality Settings里把VSync Count改成Don't Sync，然后在真机上用Profiler监测真实帧率。

第二，使用Development Build。Development Build会包含调试符号和Profiler连接功能，但也会带来一定的性能开销。所以，最终的帧率测试要用Release Build，Development Build只用于排查问题。

第三，注意设备发热。移动设备在长时间高负载运行后会降频，导致帧率下降。测试时要注意设备的温度，如果发现帧率在几分钟后明显下降，说明设备在降频，需要进一步优化。

第四，多设备测试。不同品牌的手机，GPU和CPU的性能差异很大。至少要覆盖高通骁龙、联发科天玑、麒麟三个平台的中高端和低端机型。我见过一个项目，在骁龙865上跑60帧，在骁龙660上只有20帧，这就是没有做低端机适配的后果。

6. 工具链与自动化检测

手动优化终究是有限的，建立一套自动化的检测工具链，才能保证优化成果不被后续的资源更新破坏。

6.1 资源导入时的自动检测

Unity的AssetPostprocessor可以在资源导入时自动执行检测逻辑。你可以写一个脚本，在模型导入时检查面数是否超标、骨骼数量是否过多、材质数量是否合理。如果超标，就在Console里输出警告，甚至直接拒绝导入。

这个脚本的实现思路是，继承AssetPostprocessor类，重写OnPostprocessModel方法。在这个方法里，你可以通过gameObject获取到导入的模型，然后遍历它的SkinnedMeshRenderer和MeshFilter，统计面数、骨骼数、材质数。如果超过预设的阈值，就用Debug.LogError输出错误信息。

6.2 运行时性能监控

在游戏运行时，你也可以用脚本实时监控人物渲染的性能指标。比如，每隔一段时间统计一次DrawCall和SetPass Call，如果超过阈值就记录日志或者弹出警告。这样可以在测试阶段及时发现性能问题，而不是等到上线后才被玩家投诉。

实现方法是，在Update或者Coroutine里调用UnityEngine.Profiling.ProfilerRecorder，获取当前的渲染统计数据。ProfilerRecorder可以获取到DrawCall、SetPass Call、三角形数量等指标，而且开销很小，适合在运行时使用。

6.3 性能预算的制定与执行

最后，也是最重要的，是制定一套性能预算，并且严格执行。性能预算要具体到每个环节：单个人物的面数上限、骨骼数量上限、材质数量上限、贴图分辨率上限、Shader指令数上限。然后把这些预算写进项目规范，让美术和程序都清楚自己的边界在哪里。

性能预算的制定要基于目标设备。如果是面向低端机，预算要卡得很死；如果是面向高端机，可以适当放宽。但无论如何，都要留出20%的余量，因为项目后期总会有各种意想不到的性能开销。

我在实际项目中的体会是，人物渲染优化不是一次性的工作，而是一个持续的过程。从项目立项开始，就要把性能意识贯穿到美术制作、程序开发、测试验收的每一个环节。等到项目后期再来优化，往往已经积重难返，只能做一些治标不治本的修补。所以，如果你正在做一个新项目，从现在开始就建立性能账本和资源规范，比后期任何优化技巧都管用。