渲染优化

Frame Debugger 能看什么？

面试高分回答

Frame Debugger 主要用来看一帧画面是怎么一步一步渲染出来的。它会把当前帧拆成一条条渲染事件，让你逐步查看每个 DrawCall、每个 Pass、每次 RenderTarget 切换、每次材质和 Shader 状态。

它能看什么？

可以看这一帧有哪些 DrawCall，每个 DrawCall 画了哪个对象。

可以看当前 DrawCall 使用的 Mesh、Material、Shader、Pass、贴图、渲染队列。

可以看渲染顺序，比如深度、阴影、透明物体、UI、后处理分别在什么时候画。

可以看 RenderTexture 和 RenderTarget 的切换，比如小地图、角色预览、后处理、反射相机。

可以看批次为什么变多，比如材质不同、贴图不同、Shader Pass 不同、渲染状态不同导致无法合批。

常用来排查什么？

DrawCall 为什么多。
比如两个物体看起来一样，但材质实例不同，导致批次分开。

一个物体为什么被画了多次。
比如阴影 Pass、Depth Pass、Forward Pass、描边 Pass、后处理 Pass。

透明物体排序问题。
比如粒子、玻璃、UI 谁先画谁后画。

后处理 Pass 是否太多。
比如 Bloom、Blur、Color Grading、抗锯齿是否带来了多次全屏绘制。

UI 批次是否太碎。
比如图集不统一、材质不同、Mask 或特殊效果太多。

物体为什么没显示。
可以一步步看它有没有被画出来，是不是 Layer、Camera Culling Mask、Render Queue、Shader Pass 出了问题。

它不能替代什么？

它不是精确性能计时工具。 看 CPU 耗时还是用 Profiler；看 GPU 耗时要用 GPU Profiler、RenderDoc、Xcode、Android GPU Inspector 这类工具。

它也不是专门的 Overdraw 热力图工具。 但你可以通过它观察透明物体、粒子、全屏后处理的绘制顺序，辅助判断 Overdraw 来源。

一句话总结

TIP

Frame Debugger 看的是“一帧怎么画出来”；Profiler 看的是“哪里耗时”；Memory Profiler 看的是“内存里有什么”。面试里这样区分，会显得你不是只会背工具名，而是真的知道该用哪个工具查哪类问题。

RenderDoc 能看什么？

面试高分回答

RenderDoc 是一个 GPU 帧捕获和分析工具。它能把某一帧完整抓下来，然后让你逐个查看这一帧里的 DrawCall、纹理、Buffer、Shader、Pipeline State、RenderTarget 和中间渲染结果。

它能看什么？

可以看这一帧有哪些 DrawCall，每个 DrawCall 画了什么 Mesh，用了什么材质、Shader、Pass。

可以看 GPU 资源，比如 Texture、RenderTexture、Depth Texture、Vertex Buffer、Index Buffer、Constant Buffer。

可以看管线状态，比如 Blend、Depth Test、Stencil、Cull、Viewport、RenderTarget、Shader 绑定。

可以看中间渲染结果，比如阴影图、GBuffer、后处理输入输出、临时 RenderTexture。

可以看 Mesh 数据，比如顶点位置、法线、UV、索引，适合排查模型显示异常。

常用来排查什么？

物体为什么没画出来：
看 DrawCall 有没有出现，再看是否被深度测试挡住、是否被裁剪、Shader 是否输出了错误颜色。

贴图为什么不对：
看实际绑定的是哪张 Texture，UV 是否正常，MipMap、通道、格式是否符合预期。

Shader 为什么结果异常：
看顶点输入输出、像素输出、常量 Buffer、纹理采样，有些平台还支持 Shader Debug。

后处理哪里出错：
逐个看全屏 Pass 的输入输出，比如 Bloom、Blur、Color Grading、抗锯齿。

深度和模板问题：
看 Depth Buffer、Stencil 状态，排查物体被挡、描边失败、遮罩异常。

和 Unity Frame Debugger 的区别

Unity Frame Debugger 更偏 Unity 层，适合快速看一帧渲染顺序、Pass、DrawCall 和批次。

RenderDoc 更偏 GPU 层，能看到更底层的证据，比如具体 Buffer、纹理、RenderTarget、Shader 资源绑定、管线状态。

简单说： Frame Debugger 适合先定位“Unity 这一帧怎么画”。 RenderDoc 适合继续深挖“GPU 这一帧到底拿到了什么数据、输出了什么结果”。

它不能看什么？

它不是查 C# 逻辑的工具。Update 慢、GC Alloc、协程卡顿，要看 Unity Profiler。

它不是查内存引用链的工具。资源为什么没释放，要看 Memory Profiler。

它也不是单纯的耗时排行榜。虽然可以提供性能线索，但精确 GPU 性能分析通常还要结合 GPU Profiler、Xcode、Android GPU Inspector、厂商工具。

一句话总结

NOTE

RenderDoc 看的是 GPU 单帧底层细节：DrawCall、资源绑定、Shader、Buffer、RenderTarget 和中间图。面试里可以说：Profiler 看哪里慢，Frame Debugger 看 Unity 怎么画，RenderDoc 看 GPU 实际怎么执行。

DrawCall 多一定是 GPU 问题吗？

面试高分回答

DrawCall 多不一定是 GPU 问题。更准确地说：DrawCall 多通常先增加 CPU 和渲染线程的提交成本，GPU 是否成为瓶颈，还要看 Shader 复杂度、Overdraw、分辨率、阴影、后处理和带宽压力。

为什么不是一定 GPU 问题？

一次 DrawCall，本质是 CPU 告诉 GPU：用这个 Mesh、这个材质、这个 Shader、这些渲染状态，去画一批东西。

所以 DrawCall 多时，CPU 要准备更多渲染命令，Render Thread 要提交更多状态。如果材质、Shader、贴图频繁切换，还会产生很多 SetPass Calls，这通常更容易让 CPU 侧变慢。

什么时候偏 CPU 问题？

Profiler 里 Main Thread、Render Thread、Camera.Render、RenderLoop.Draw 很高。

Stats 里 Batches、SetPass Calls 很多。

Frame Debugger 里看到很多小物体因为材质不同、贴图不同、Shader Pass 不同而无法合批。

这种情况优化方向是：合批、图集、减少材质实例、SRP Batcher、GPU Instancing、减少 SetPass。

什么时候偏 GPU 问题？

GPU Frame Time 超预算。

Shader 很复杂，采样多、分支多、计算多。

透明物体、粒子、UI 叠很多层，Overdraw 高。

分辨率高、后处理多、阴影多、实时灯多。

这种情况优化方向是：降低 Shader 复杂度、减少透明层数、降低后处理和阴影质量、降低分辨率或 RenderTexture 尺寸。

怎么判断？

用 Unity Profiler 看 CPU 侧：Main Thread 和 Render Thread 是否高。 用 Frame Debugger 看 DrawCall 为什么多、批次为什么断。 用 GPU Profiler 或平台工具看 GPU 时间是否超预算。 用 Stats 辅助看 Batches、SetPass Calls、Triangles、Vertices。

一句话总结

IMPORTANT

DrawCall 多不等于 GPU 慢。它更常见的问题是 CPU 提交成本和状态切换成本高；GPU 慢则更多和 Shader、Overdraw、阴影、后处理、分辨率有关。面试里一定要说“要结合 Profiler 和 Frame Debugger 判断瓶颈”，不要直接把 DrawCall 多归因成 GPU 问题。

SetPass Call 是什么？

面试高分回答

SetPass Call 可以理解成：Unity 在真正绘制之前，给 GPU 设置一次材质、Shader Pass 和渲染状态。比如要用哪个 Shader、哪个 Pass、哪些纹理、Blend 怎么开、深度测试怎么做、剔除状态是什么。

它和 DrawCall 的区别

DrawCall 更像是“画一次”。 SetPass Call 更像是“画之前切换一次渲染状态”。

多个 DrawCall 如果使用同一个材质、同一个 Shader Pass、同一套渲染状态，可能只需要较少的 SetPass。

但如果每个物体材质都不同，Shader 变体不同，Pass 不同，就会频繁 SetPass。这个状态切换成本通常在 CPU 和 Render Thread 上比较明显。

为什么 SetPass 多不好？

因为每次 SetPass 都要切换渲染管线状态。 状态切换越频繁，CPU 准备和提交渲染命令的成本越高，也更容易打断合批。

所以面试里可以说： Batches 多说明绘制批次多，SetPass Calls 多说明材质或 Shader 状态切换多。很多时候 SetPass Calls 比单纯的 Batch 数更值得关注。

什么会导致 SetPass 变多？

材质不同。 比如每个怪物都实例化了一份自己的材质。

Shader 不同。 不同 Shader 不能轻易合并。

Shader 变体不同。 比如关键字不同、开关不同、Pass 不同。

贴图不同。 UI 没有打图集，粒子特效用很多不同贴图。

多 Pass Shader。 比如描边、阴影、深度、特殊效果，一个物体可能要画多次。

访问 renderer.material。 这会创建材质实例，容易让原本共享的材质变成很多份。

怎么优化？

共享材质，不要给每个对象都创建材质实例。

UI 使用图集，减少贴图切换。

减少 Shader Pass 和变体数量。

相同对象使用 GPU Instancing。

URP/HDRP 项目里尽量满足 SRP Batcher 条件。

静态物体可以考虑 Static Batching。

只改少量材质参数时，可以考虑 MaterialPropertyBlock，但也要结合具体合批策略验证。

一句话总结

TIP

DrawCall 是画几次，SetPass Call 是切几次渲染状态。SetPass 多通常说明材质、Shader、贴图、Pass 太碎，会增加 CPU 和渲染线程压力。面试里说清楚这个区别，很加分。

Overdraw 如何查看？

面试高分回答

SetPass Call 可以理解成：Unity 在真正绘制之前，给 GPU 设置一次材质、Shader Pass 和渲染状态。比如要用哪个 Shader、哪个 Pass、哪些纹理、Blend 怎么开、深度测试怎么做、剔除状态是什么。

它和 DrawCall 的区别

DrawCall 更像是“画一次”。 SetPass Call 更像是“画之前切换一次渲染状态”。

多个 DrawCall 如果使用同一个材质、同一个 Shader Pass、同一套渲染状态，可能只需要较少的 SetPass。

但如果每个物体材质都不同，Shader 变体不同，Pass 不同，就会频繁 SetPass。这个状态切换成本通常在 CPU 和 Render Thread 上比较明显。

为什么 SetPass 多不好？

因为每次 SetPass 都要切换渲染管线状态。 状态切换越频繁，CPU 准备和提交渲染命令的成本越高，也更容易打断合批。

所以面试里可以说： Batches 多说明绘制批次多，SetPass Calls 多说明材质或 Shader 状态切换多。很多时候 SetPass Calls 比单纯的 Batch 数更值得关注。

什么会导致 SetPass 变多？

材质不同。 比如每个怪物都实例化了一份自己的材质。

Shader 不同。 不同 Shader 不能轻易合并。

Shader 变体不同。 比如关键字不同、开关不同、Pass 不同。

贴图不同。 UI 没有打图集，粒子特效用很多不同贴图。

多 Pass Shader。 比如描边、阴影、深度、特殊效果，一个物体可能要画多次。

访问 renderer.material。 这会创建材质实例，容易让原本共享的材质变成很多份。

怎么优化？

共享材质，不要给每个对象都创建材质实例。

UI 使用图集，减少贴图切换。

减少 Shader Pass 和变体数量。

相同对象使用 GPU Instancing。

URP/HDRP 项目里尽量满足 SRP Batcher 条件。

静态物体可以考虑 Static Batching。

只改少量材质参数时，可以考虑 MaterialPropertyBlock，但也要结合具体合批策略验证。

一句话总结

IMPORTANT

DrawCall 是画几次，SetPass Call 是切几次渲染状态。SetPass 多通常说明材质、Shader、贴图、Pass 太碎，会增加 CPU 和渲染线程压力。面试里说清楚这个区别，很加分。

透明特效为什么贵？

面试高分回答

透明特效贵，核心原因是：同一个屏幕像素会被反复绘制很多次，而且每次还要做透明混合。所以它不只是 DrawCall 问题，更常见是 GPU 的像素计算、Overdraw、显存带宽和混合成本问题。

为什么贵？

第一，Overdraw 高。 透明特效通常由很多粒子 Quad 叠在一起，比如火焰、烟雾、爆炸、光效。同一个像素可能被画十几次，每画一次都要执行一次片元着色器。

第二，深度剔除效果弱。 很多透明材质是 ZWrite Off，也就是不写深度。这样后面的透明层不容易被提前剔除，GPU 可能要把很多最终看不清的层也算完。

第三，Alpha Blend 要混合。 透明不是直接覆盖颜色，而是要读取屏幕上已有颜色，再和当前颜色按 alpha 混合。这会增加显存带宽和混合单元压力，移动端尤其敏感。

第四，透明通常要排序。 透明物体一般要从远到近绘制，否则混合结果可能不对。排序、材质切换、渲染队列都会让渲染流程更复杂。

第五，特效 Shader 往往不简单。 溶解、扰动、软粒子、深度淡化、扭曲、UV 动画、多贴图采样都会增加像素成本。如果再叠加 Overdraw，成本会被成倍放大。

哪些透明特效最危险？

大面积烟雾。 贴近镜头的爆炸。 全屏半透明光效。 大量叠加的粒子。 带软粒子、扭曲、折射的特效。 透明贴图里有大量空白区域的大 Quad。

怎么优化？

减少粒子数量和发射率。

缩短粒子生命周期，避免屏幕上长期堆很多层。

减少粒子屏幕覆盖面积，尤其是贴近相机的大粒子。

降低 Shader 复杂度，少做多次贴图采样、软粒子、扭曲、溶解叠加。

裁剪透明贴图的空白区域，不要用一张很大的透明 Quad 包住很小的有效图案。

低端机关闭软粒子、降低特效等级、减少透明层数。

能用不透明或 Alpha Test 的地方，不要强行用 Alpha Blend。

用 Scene Overdraw 模式、Frame Debugger、RenderDoc 和真机 GPU 工具确认瓶颈。

一句话总结

NOTE

透明特效贵，是因为它往往 ZWrite Off、Overdraw 高、需要 Alpha Blend、屏幕覆盖面积大，并且 Shader 还可能很复杂。面试里可以说：优化透明特效重点不是只降 DrawCall，而是减少像素重复绘制和降低每个像素的计算成本。

后处理为什么影响移动端性能？

面试高分回答

后处理会影响移动端性能，核心原因是：它通常是全屏 Pass，会反复读写 RenderTexture，消耗大量像素填充、显存带宽和 GPU 时间。移动端 GPU 带宽、散热和功耗都比 PC 紧张，所以后处理开多了很容易掉帧、发热、降频。

为什么贵？

第一，后处理通常要扫全屏。 比如 1080p 屏幕，一帧就有两百多万个像素。一个后处理 Pass 就要处理一遍全屏，如果 Bloom、Blur 这种效果有多个 Pass，就会反复处理很多次。

第二，会频繁读写 RenderTexture。 场景先渲染到一张中间图，后处理读取它，再写到另一张图。每多一次读写，就多一次显存带宽消耗。移动端对带宽非常敏感。

第三，很多效果需要多次采样。 比如模糊、景深、Bloom、运动模糊，都可能对周围像素采样很多次。采样越多，GPU 压力越大。

第四，HDR、MSAA、高清 RT 会放大成本。 HDR 需要更高精度的 RenderTexture，MSAA 也会增加渲染目标内存和解析成本。它们和后处理叠在一起，移动端压力会明显上升。

第五，容易导致发热降频。 移动端散热弱，GPU 长时间高负载后可能触发降频，表现就是刚开始流畅，玩一会儿越来越卡。

哪些后处理最容易贵？

Bloom：常见，但可能有提亮、降采样、模糊、叠回多个步骤。

Blur / DOF：模糊半径越大，采样越多。

Motion Blur：需要速度信息和多次采样，移动端通常谨慎开启。

SSAO / SSR：依赖深度、法线或屏幕空间采样，成本明显。

HDR + Tone Mapping：画面好，但 RenderTexture 精度和带宽成本更高。

怎么优化？

低端机关闭重后处理，比如 SSAO、SSR、Motion Blur、复杂 DOF。

降低后处理分辨率，比如半分辨率 Bloom、半分辨率 Blur。

减少 Bloom 迭代次数和模糊半径。

减少全屏 Pass 数，能合并的后处理尽量合并。

关闭不必要的 HDR、MSAA 或高精度 RenderTexture。

做画质分档，高端机开完整后处理，低端机只保留轻量效果。

用 GPU Profiler、Frame Debugger、RenderDoc 和真机温度帧率验证，不要只在 Editor 看效果。

一句话总结

NOTE

后处理在移动端贵，是因为它常常是全屏多 Pass，频繁读写 RenderTexture，并且消耗大量显存带宽和像素计算。面试里可以说：移动端后处理优化重点是降分辨率、减 Pass、关重效果、做画质分档，并用真机 GPU 工具验证。

阴影为什么贵？

面试高分回答

阴影贵，核心原因是：实时阴影通常不是直接画一个黑色区域，而是要先从灯光视角额外渲染一张 Shadow Map，然后在主渲染时再采样这张阴影图，判断每个像素是否被遮挡。

为什么贵？

第一，阴影需要额外渲染 Pass。 实时阴影通常要从灯光视角把能投影的物体再渲染一遍，生成 Shadow Map。所以能投影的物体越多，阴影 Pass 的 DrawCall、顶点处理、蒙皮处理就越多。

第二，Shadow Map 本身占内存和带宽。 Shadow Map 本质是一张深度纹理。分辨率越高，阴影越清晰，但内存、带宽、填充率成本也越高。

第三，主渲染时还要采样阴影。 物体正常渲染时，Shader 还要去采样 Shadow Map，比较当前点是否在阴影里。软阴影还会做多次采样过滤，比硬阴影更贵。

哪些设置会让阴影更贵？

实时灯光多。 每个投影灯都可能需要自己的阴影图。点光源阴影尤其贵，因为它可能要处理多个方向。

阴影距离太远。 Shadow Distance 越远，参与投影的物体越多，阴影图覆盖范围越大，也越难保持清晰。

级联阴影太多。 Cascaded Shadow Maps 可以提升近处阴影质量，但级联越多，阴影计算和管理成本越高。

软阴影。 软阴影边缘自然，但通常需要更多采样。

动态角色太多。 SkinnedMeshRenderer 投影时还要处理骨骼变形，大量角色同时投影会很重。

草、树叶、透明裁剪物体。 Alpha Cutout 植被投影很容易增加像素和采样成本。

怎么优化？

静态场景尽量用烘焙阴影，比如 Lightmap 或 Mixed Lighting。

实时阴影只留主光和关键角色，不要所有灯都开实时阴影。

降低 Shadow Distance，让远处不再计算实时阴影。

降低阴影分辨率和级联数量。

低端机关闭软阴影，改用硬阴影或假阴影。

不重要物体关闭 Cast Shadows，比如小道具、远处装饰、粒子。

远处角色使用 Shadow LOD，或者直接用 Blob Shadow、贴片阴影、简化阴影。

用 Frame Debugger 看 Shadow Pass 里到底画了哪些物体，用 GPU Profiler 看阴影是否真的成为 GPU 瓶颈。

一句话总结

CAUTION

阴影贵，是因为它通常要“先从灯光视角多渲染一次，再在主渲染里采样比较”。灯越多、阴影范围越大、分辨率越高、软阴影和动态投影物体越多，成本就越高。

实时光和烘焙光区别是什么？

面试高分回答

实时光和烘焙光的核心区别是：实时光在运行时计算，烘焙光在编辑器提前计算。

实时光更灵活，可以移动、开关、改变颜色和强度，也能对动态物体产生实时影响；但运行时性能更贵。烘焙光把光照结果提前算到 Lightmap、Light Probe 等数据里，运行时只是采样，所以更省性能，但不适合频繁变化的灯光。

实时光 Realtime Lighting

实时光会在游戏运行时参与光照计算。

优点是动态性强：灯可以移动，颜色可以变，强度可以变，动态角色也能实时受光，还可以产生实时阴影。

缺点是性能贵，尤其是多盏实时灯、实时阴影、软阴影、点光源阴影，会明显增加 GPU 和 CPU 渲染提交压力。

适合：手电筒、技能光效、爆炸光、角色附近的主光、会移动或闪烁的灯。

烘焙光 Baked Lighting

烘焙光是在编辑器里提前计算好的。Unity 会把静态物体受到的光照、间接光、阴影等结果保存到 Lightmap 里。

运行时不需要再复杂计算，只要采样 Lightmap，所以性能很便宜。

缺点是它基本是固定结果。灯光位置、强度、阴影如果运行时变化，烘焙结果不会自动跟着变。另外 Lightmap 本身会占内存和包体。

适合：建筑、地形、墙体、静态场景道具、大型移动端场景。

Mixed Lighting

Mixed 是折中方案。

静态物体可以用烘焙结果，动态物体仍然可以受到灯光影响。比如场景光照大部分烘焙，角色用实时主光、Light Probe 或少量实时阴影补充。

适合：既想要烘焙性能，又希望动态角色和灯光有一定交互的场景。

Light Probe 是干什么的？

烘焙光主要照静态物体，但动态角色不能直接使用 Lightmap。 所以 Unity 用 Light Probe 记录空间中一些点的环境光信息，动态物体移动时采样附近探针，获得比较自然的间接光。

简单说： 静态物体用 Lightmap。 动态物体用 Light Probe 接收烘焙环境光。

一句话总结

NOTE

实时光是花运行时性能换动态效果；烘焙光是花内存和包体换运行时便宜；Mixed Lighting 是折中。移动端项目通常会让静态场景尽量烘焙，动态角色用 Light Probe 和少量实时光补充。

粒子系统如何优化？

粒子系统优化的核心思路

粒子系统优化不要只说“减少粒子数量”，面试里更高分的说法是：先判断瓶颈在 CPU 模拟、GPU Overdraw、材质切换、内存峰值、资源加载 哪一侧，然后针对性优化。

1. 减少粒子数量

粒子越多，CPU 要更新的位置、速度、生命周期越多，GPU 也要画更多透明面片。

常见优化：

• 降低 Emission Rate
• 限制 Max Particles
• 缩短粒子生命周期 Start Lifetime
• 远处特效减少数量
• 低端机使用低配特效
• 爆炸、烟雾不要无脑铺满屏幕

面试可以说：粒子数量是最直接的成本来源，但不是唯一瓶颈，透明重叠往往更致命。

2. 减少 Overdraw

Unity 粒子大多是透明贴图，比如烟、火、光效。透明物体通常不能很好地利用深度剔除，屏幕上同一个像素可能被重复绘制很多次。

比如一团烟雾看起来只有一个特效，但如果 50 个半透明粒子叠在一起，同一块屏幕区域可能被画几十遍。

优化方式：

• 缩小粒子贴图空白区域
• 不要用巨大透明面片
• 控制烟雾、光晕、全屏特效数量
• 减少半透明层叠
• 移动端少用复杂透明 Shader
• 用 Frame Debugger 或 Overdraw 视图检查

3. 减少复杂模块

Particle System 里的某些模块很贵，比如：

• Collision：粒子碰撞检测开销大
• Noise：要额外计算扰动
• Trails：会生成拖尾网格
• Sub Emitters：一个粒子死亡又生成新粒子，数量容易爆
• Lights：粒子带灯光非常贵
• Shape 复杂发射也可能增加计算

如果只是视觉需要，很多效果可以用贴图序列帧、Shader 动画或简单缩放代替。

4. 材质和贴图优化

粒子如果材质很多，会增加渲染状态切换，可能带来更多 SetPass Call。

优化方式：

• 同类粒子共用材质
• 使用图集减少贴图切换
• 控制贴图分辨率
• 使用合适压缩格式
• 不需要 Alpha 的贴图不要带 Alpha
• 移动端 Shader 尽量简单

面试可以说：粒子优化不仅看 DrawCall，还要看 SetPass、Overdraw 和 Shader 复杂度。

5. 使用对象池

频繁创建和销毁特效很容易造成性能波动。

错误做法：

Instantiate(effect);
Destroy(effect, 2f);

战斗里大量这样做，可能导致 GC、内存峰值、加载卡顿。

更好的方式是：

• 提前创建常用特效
• 播放时从对象池取
• 播放完成后回收到池里
• 不频繁 Instantiate 和 Destroy

6. 做特效 LOD

不是所有距离都需要同样精细的特效。

例如：

• 近处：完整粒子、拖尾、光效
• 中距离：减少粒子数量
• 远距离：只保留简单贴图或不显示
• 屏幕外：直接暂停或停止

大规模战斗、怪物多、技能多的时候，特效 LOD 很重要。

7. 控制播放时机

很多项目卡顿不是因为一个特效贵，而是同一帧突然播放太多特效。

比如一群怪同时死亡，同时播放爆炸、掉落、受击、飘字，就会形成瞬时峰值。

优化方式：

• 分帧播放部分特效
• 非关键特效延迟几帧
• 限制同屏最大特效数量
• 同类特效合并显示
• 对低优先级特效直接丢弃

面试高分回答

CAUTION

粒子系统优化我会先用 Profiler 和 Frame Debugger 定位问题。如果是 CPU 高，就看粒子数量、Collision、Noise、Trails、Sub Emitters 这些模拟模块；如果是 GPU 高，就重点看透明 Overdraw、粒子屏幕覆盖面积、Shader 复杂度和材质切换；如果是内存或卡顿问题，就看是否频繁 Instantiate、Destroy，是否需要对象池、预加载和贴图压缩。实际项目里我一般会结合对象池、特效 LOD、同类材质合批、减少透明重叠和低端机降级方案一起做。