渲染优化追问链

当前是 CPU 瓶颈还是 GPU 瓶颈？

标准回答 不能只看 FPS 低就判断是 CPU 或 GPU 瓶颈，要看一帧里是谁超过了帧预算。

如果目标是 60 FPS，一帧预算约 16.6ms。 如果目标是 30 FPS，一帧预算约 33.3ms。

判断方法是：

Main Thread 很高：更像 CPU 脚本/逻辑瓶颈。 Render Thread 很高：可能是 CPU 提交渲染命令瓶颈。 GPU Time 很高：更像 GPU 瓶颈。 Gfx.WaitForPresent 高：可能是 CPU 在等 GPU，也可能是 VSync 或限帧，不要误判成 CPU 忙。

底层原理 一帧通常是 CPU 先做游戏逻辑、物理、动画、UI、渲染命令提交，然后 GPU 执行绘制、阴影、后处理、像素填充等工作。

如果 CPU 做得慢，GPU 可能在等 CPU 提交命令。 如果 GPU 做得慢，CPU 可能很快提交完，然后在等待 GPU 或等待垂直同步。 所以瓶颈判断要看“谁决定了最终帧耗时”。

Unity 里怎么看 用 Profiler 看：

Main Thread：脚本、动画、物理、UI、GC、资源加载。 Render Thread：DrawCall 提交、SetPass、材质切换。 GPU：阴影、后处理、Overdraw、复杂 Shader、高分辨率。 Gfx.WaitForPresentOnGfxThread：可能在等 GPU 或 VSync。 WaitForTargetFPS：通常是限帧，不是性能瓶颈。

快速判断技巧 如果降低分辨率后 FPS 明显提升，通常更像 GPU 瓶颈。 如果关掉后处理、阴影、透明特效后明显提升，通常更像 GPU 瓶颈。 如果减少怪物 AI、Update 数量、物理检测后明显提升，通常更像 CPU 瓶颈。 如果减少 DrawCall、合批、减少材质切换后提升，可能是 Render Thread 瓶颈。 如果 Editor 里卡但真机不卡，不要直接下结论，真机 Profiler 更可信。

常见 CPU 瓶颈来源 大量 Update。 AI 每帧全量计算。 频繁 GC Alloc。 UGUI Layout / Canvas rebuild。 Physics.Simulate 过高。 同步资源加载。 大量字符串日志。

常见 GPU 瓶颈来源 透明物体和粒子 Overdraw 高。 后处理过多。 实时阴影过重。 分辨率过高。 Shader 太复杂。 全屏 Pass 太多。 贴图带宽压力大。 移动端使用了过重的 HDR、Bloom、TAA。

IMPORTANT

面试加分说法 “我不会直接说当前是 CPU 还是 GPU 瓶颈。我会先关掉 VSync 和限帧，确定目标帧预算，然后用 Profiler 看 Main Thread、Render Thread 和 GPU Time。如果 Main Thread 超预算就是 CPU 逻辑方向；如果 GPU Time 超预算，或者降低分辨率后明显变快，就是 GPU 方向；如果 WaitForPresent 很高，我会进一步判断是在等 GPU 还是被 VSync 限住。”

DrawCall 多是唯一问题吗？

标准回答

不是，DrawCall 多不是唯一问题。 DrawCall 多通常说明 CPU 需要向 GPU 提交更多绘制命令，可能让 Main Thread / Render Thread 变高；但真正的渲染瓶颈还可能来自 SetPass、Shader 太复杂、Overdraw、透明物体、后处理、阴影、分辨率、显存带宽等。

底层原理

一帧渲染大概可以拆成：

CPU 游戏逻辑 -> CPU 提交渲染命令 -> GPU 执行 -> 显示

DrawCall 多主要影响的是 CPU 提交阶段。 但如果 GPU 在跑复杂 Shader、大面积透明粒子、全屏后处理、实时阴影，即使 DrawCall 很少，也可能很卡。

所以面试里不要只说“降低 DrawCall”，要说：

先定位瓶颈，再决定优化方向。

Unity 里怎么判断

如果 Main Thread / Render Thread 高，可能是 DrawCall、SetPass、脚本、UI 重建等 CPU 问题。

如果 GPU Time 高，可能是 Shader、Overdraw、阴影、后处理、分辨率、带宽问题。

如果 WaitForPresent 高，可能是 GPU 等待、VSync、帧同步或提交节奏问题。

工具上可以用：

Profiler 看 CPU/GPU 时间。 Frame Debugger 看 DrawCall、SetPass、材质切换。 RenderDoc 看具体 GPU Pass 和像素开销。

优化思路

DrawCall 多：用图集、合批、GPU Instancing、SRP Batcher。 SetPass 多：减少材质数量、Shader 变体、Pass 切换。 GPU 压力大：降低透明 Overdraw、简化 Shader、减少后处理和阴影。 场景物体多：用 LOD、Occlusion Culling、视锥剔除。 UI 卡顿：减少 Canvas 重建，拆 Canvas，关掉不必要 Raycast Target。

面试加分说法

TIP

我不会只盯 DrawCall 数字。DrawCall 多主要是 CPU 提交问题，但实际瓶颈要看帧时间分布。如果 CPU 高，我会查 DrawCall、SetPass、UI 重建和脚本；如果 GPU 高，我会查 Overdraw、Shader、后处理、阴影和分辨率。优化前后必须用真机 Profiler 数据验证。

为什么透明物体贵？

标准回答

透明物体贵，核心不是“它一定 DrawCall 多”，而是它经常会让 GPU 对同一个屏幕像素重复计算、重复混合，而且还不好排序。

底层原理

不透明物体通常可以 ZWrite On。 也就是前面的物体把深度写进去后，后面的像素如果被挡住，GPU 可以直接丢掉，甚至不用跑后面的片元着色器。

透明物体通常是 ZWrite Off。 因为透明物体不能简单把后面的东西完全挡住，否则玻璃、烟雾、水面后面的内容就看不到了。所以透明物体往往要放在不透明物体之后渲染，并且尽量按照“从远到近”排序。

问题就来了： 如果一堆透明粒子叠在一起，同一个屏幕像素可能被画很多次。每一层都要采样贴图、跑 Shader、读取背景颜色、按 alpha 做混合。这个就叫 Overdraw，透明特效贵很多时候就是贵在这里。

Unity 工程实践

透明物体常见重灾区有：

烟雾、火焰、技能特效、半透明 UI、玻璃、水面、树叶、软粒子、大面积透明贴图。

它们贵的原因通常是：

ZWrite Off，不能有效挡住后面的透明层。 Alpha Blend，需要读背景色再混合。 Overdraw 高，同一个像素被画很多遍。 排序复杂，粒子、交叉面片、透明网格不一定排得准。 移动端更明显，因为填充率和带宽更紧张。

Alpha Test 和 Alpha Blend 的区别

Alpha Test / Clip 是硬裁剪： 要么显示，要么丢弃。适合树叶、栅栏、草。优点是可以更接近不透明流程，缺点是边缘硬，可能有锯齿。

Alpha Blend 是半透明混合： 前景颜色和背景颜色按 alpha 混合。适合玻璃、烟雾、水、光效。效果柔和，但更贵，也更容易有排序问题。

优化思路

减少透明物体的屏幕面积。 减少粒子数量和粒子层数。 降低透明 Shader 复杂度。 避免大面积全屏半透明 UI。 能用 Alpha Test 的地方别用 Alpha Blend。 特效贴图尽量裁掉无效透明边。 用 Overdraw 视图检查哪里被重复绘制。 移动端谨慎使用大量软粒子、折射、透明后处理。 必要时把某些效果降分辨率渲染到 RenderTexture 再合成。

面试加分说法

NOTE

我理解透明物体贵主要是像素阶段贵。它通常不开深度写入，导致透明层之间不能像不透明物体那样提前剔除；再加上 alpha blend 需要读背景色并做混合，所以 Overdraw、带宽和 fillrate 压力都会上来。实际优化时我会先用 Scene Overdraw、Profiler 和 Frame Debugger 定位，是透明粒子层数太多、Shader 太复杂，还是全屏透明面积太大，再针对性优化。

Overdraw 怎么看？

标准回答

Overdraw 一般先在 Unity 的 Scene 视图里切到 Overdraw 模式看。它会把重复绘制严重的区域显示得更亮，亮区越明显，说明同一个屏幕像素被画的次数越多。

怎么看

在 Unity 里常用三步：

第一步，看 Scene View -> Draw Mode -> Overdraw。 亮的地方重点排查，尤其是烟雾、火焰、技能特效、半透明 UI、水面、玻璃、大面积透明贴图。

第二步，用 Frame Debugger。 Overdraw 视图只能告诉你“哪里亮”，Frame Debugger 可以逐个 DrawCall 看是谁在画，重点看 Transparent Queue、粒子、UI、后处理 Pass。

第三步，用 Profiler / 真机 GPU 数据 验证。 因为编辑器 Overdraw 只是参考，最后还是要看真机上的 GPU Time、帧率、发热和功耗。

底层原理

Overdraw 的意思是：同一个屏幕像素被重复绘制了多次。

比如一个像素位置上叠了 5 层透明粒子，那这个像素可能要跑 5 次片元着色器，还要做 5 次 alpha blend。 如果每层还采样贴图、算光照、做软粒子、做扭曲，那 GPU 压力就会明显上升。

不透明物体通常可以通过深度测试提前挡住后面的像素。 透明物体很多时候 ZWrite Off，后面的透明层不能被简单丢弃，所以更容易产生 Overdraw。

重点看哪里

大面积半透明 UI。 全屏黑色遮罩、渐变背景、弹窗叠弹窗。

粒子特效。 烟雾、火焰、爆炸、技能光效，尤其是粒子很大又很多层的时候。

透明材质。 玻璃、水、树叶、草、半透明角色特效。

后处理。 Bloom、Blur、Depth of Field 这类全屏 Pass 也会增加屏幕像素处理压力。

优化方向

减少透明面积。 减少粒子数量和层数。 裁掉贴图外圈无效透明区域。 避免多个全屏半透明 UI 叠加。 能用 Alpha Test 的地方不要滥用 Alpha Blend。 降低透明 Shader 复杂度。 移动端尽量少用大面积软粒子和折射。 必要时把复杂特效降分辨率渲染，再合成回主画面。

面试加分说法

TIP

我看 Overdraw 不会只看 Scene 视图亮不亮。我的流程是先用 Overdraw 模式找亮区，再用 Frame Debugger 找到具体是哪批透明物体或 UI 在重复绘制，最后在真机 Profiler 上确认 GPU Time 是否下降。因为 Overdraw 视图是定位线索，不是最终性能结论。

阴影怎么优化？

标准回答

阴影优化的核心不是简单“关阴影”，而是控制：哪些灯投阴影、哪些物体投阴影、阴影画多远、阴影图多大、实时还是烘焙。

底层原理

实时阴影通常基于 Shadow Map。 它不是主相机渲染时顺便免费得到的，而是要先从光源视角把会投影的物体再渲染一遍，生成一张深度图。主相机渲染像素时，再去采样这张阴影图，判断当前点是不是被挡住。

所以阴影贵在几个地方：

投影灯越多，额外 Shadow Pass 越多。 投影物体越多，生成 Shadow Map 越贵。 Shadow Map 分辨率越高，显存和采样成本越高。 阴影距离越远，覆盖范围越大，级联压力越高。 软阴影需要多次采样，比硬阴影更贵。 点光源阴影通常要处理多个方向，所以比方向光更贵。

Unity 里怎么优化

优先缩短 Shadow Distance。 远处阴影玩家通常看不清，但成本很高。

降低 Shadow Resolution。 移动端不要默认高分辨率阴影，可以按高中低机型分档。

减少实时投影灯数量。 移动端一般只保留主方向光阴影，额外点光源、聚光灯尽量不开实时阴影。

减少投影物体。 小石头、小草、小道具、远处装饰物可以关闭 Cast Shadows，有些物体也可以关闭 Receive Shadows。

静态场景用烘焙。 建筑、地面、大型静态物体优先用 Lightmap / Baked Shadow，动态角色再使用少量实时阴影。

控制级联阴影。 Cascade Shadow 主要提升近处阴影质量，但级联越多成本越高。移动端常用 1 到 2 级，别无脑开 4 级。

谨慎使用软阴影和 Contact Shadow。 软阴影更自然，但采样更多；Contact Shadow 适合小范围增强接触感，不适合全场滥开。

排查方式

用 Profiler 看渲染耗时。 用 Frame Debugger 看 ShadowCaster Pass。 用 RenderDoc 看 Shadow Map 渲染和采样成本。 如果关闭阴影后 GPU Time 明显下降，说明阴影就是主要瓶颈之一。

面试加分说法

CAUTION

我会先区分静态和动态：静态环境尽量烘焙，动态角色只保留必要实时阴影。然后从成本最大的几个旋钮入手：缩短 Shadow Distance、降低 Shadow Resolution、减少 Cast Shadows 的对象、减少实时投影灯、控制 Cascade 数量。最后用真机 Profiler 对比 GPU Time，确认优化有效。

后处理怎么取舍？

标准回答

后处理不是越多越好，取舍原则是：看视觉收益、看 GPU 成本、看目标平台，再用真机数据验证。

底层原理

后处理通常是全屏 Pass。 也就是场景先渲染到一张 RenderTexture，然后后处理 Shader 再读取这张图，处理完写到另一张图，最后输出到屏幕。

所以它的成本主要来自：

全屏像素处理。 RenderTexture 读写。 多次 Pass 切换。 高分辨率带宽压力。 复杂采样，比如 Blur、DOF、SSAO。

屏幕分辨率越高，后处理越贵。移动端尤其明显，因为带宽和填充率比较紧。

Unity 工程取舍

Color Grading / Tone Mapping 通常收益高、成本相对可控，适合保留。

Bloom 画面提升明显，但要控制阈值、强度和迭代次数，最好低分辨率处理。

FXAA 成本较低，可以作为移动端抗锯齿方案之一。

SSAO 能增强空间层次，但移动端要谨慎，最好降采样或只在高画质开。

Motion Blur 对性能和观感都敏感，动作游戏、竞技游戏里要慎用。

Depth of Field 适合剧情、拍照、过场镜头，不适合长时间战斗常开。

SSR / 高质量 Blur / 复杂景深 移动端低端机一般慎用或关闭。

优化思路

按画质档位控制开关。 高端机开更多效果，低端机只保留核心效果。

降低后处理分辨率。 Bloom、Blur、SSAO 可以用半分辨率甚至更低。

减少 Pass 数量。 能合并的 Pass 尽量合并，减少 RT 读写。

动态降级。 战斗激烈、发热、帧率下降时自动降低后处理质量。

真机验证。 不能只在编辑器看效果，要看真机 GPU Time、帧率、温度和功耗。

面试加分说法

WARNING

我不会把后处理全开，而是按视觉收益和 GPU 成本分层。比如调色、Tone Mapping 这类统一画面风格的效果通常保留；Bloom 控制强度和分辨率；SSAO、DOF、Motion Blur 这类效果按画质档和场景开启。最后一定用真机 Profiler 验证 GPU Time，而不是凭感觉决定。

Shader Variant 怎么控制？

标准回答

Shader Variant 的控制核心是：少生成、会裁剪、可预热、能统计。 它不是单纯“删几个 Shader”，而是一套从 Shader 写法、材质规范、构建裁剪到运行时预热的流程。

底层原理

Shader Variant 本质是 Shader 的不同编译版本。 比如一个 Shader 有这些开关：

是否开阴影是否开雾效是否开法线贴图是否开裁剪是否开 Instancing

每个开关都有开和关两种情况，组合起来就是乘法增长。 4 个二选一开关就是 2 x 2 x 2 x 2 = 16 个变体。 开关越多，Variant 数量就越容易爆炸。

Variant 多会带来几个问题：

构建时间变长。 包体变大。 运行时首次使用可能卡顿。 AssetBundle 或 Addressables 中 Shader 管理更复杂。 移动端内存和加载压力更大。

Unity 里怎么控制

优先用 shader_feature，少用 multi_compile。 multi_compile 通常会保留所有组合，适合管线必须支持的功能。 shader_feature 更适合可选功能，没被材质使用的变体更容易被裁剪。

优先用局部关键词。 比如 shader_feature_local，让关键词只影响当前 Shader，避免污染全局 keyword 空间。

减少关键词数量。 不要每个小功能都做成一个 keyword。能用参数控制的，就不要拆成编译变体。

拆分 Shader。 如果一个 Shader 同时支持角色、场景、特效、UI，功能开关会非常多。可以按用途拆成更简单的 Shader。

裁掉不用的管线功能。 URP/HDRP 里不用的阴影、雾、Lightmap、Additional Lights、Soft Shadows 等功能要关掉，否则会带来大量管线变体。

使用构建期 stripping。 可以通过 Unity 的图形设置、URP Asset 设置、Shader Stripping 设置，或者 IPreprocessShaders 做自动裁剪。

收集和预热必要变体。 常用材质和场景用到的变体可以放进 ShaderVariantCollection，在加载界面或启动阶段预热，避免战斗中首次编译卡顿。

常见坑

不要过度裁剪。 如果运行时会动态切换 keyword，但构建时没保留对应变体，线上可能出现材质变粉、效果丢失或运行时卡顿。

不要无脑 Always Included Shaders。 它可能让不该进包的 Shader 和 Variant 都进包，包体会变大。

不要滥用全局 keyword。 全局 keyword 会影响范围更大，项目一大就很难追踪谁在开关它。

AssetBundle 要注意 Shader 一致性。 主包、热更包、分包里的 Shader Variant 如果不一致，可能出现某些平台或某些场景材质异常。

面试加分说法

IMPORTANT

我会从源头控制 Variant 数量：Shader 里减少 keyword，优先用 shader_feature_local；项目里制定材质关键词规范；构建时根据平台和管线功能做 stripping；常用变体用 ShaderVariantCollection 预热；最后用构建日志和包体分析统计 Variant 数量，避免每次迭代都悄悄膨胀。

移动端贴图格式怎么选？

标准回答

移动端贴图格式选择，我会按：平台支持 -> 贴图用途 -> 画质档位 -> 真机验证 来定。 现代 Android 和 iOS 主流优先选 ASTC，兼容老设备时再考虑 ETC2 / ETC1 / PVRTC。

底层原理

贴图格式影响三件事：

显存占用。 包体大小。 采样质量和加载成本。

比如 RGBA32 是未压缩格式，32 bpp，质量高但很占内存。 ASTC 4x4 质量高，大约 8 bpp。 ASTC 6x6 比较平衡，大约 3.56 bpp。 ASTC 8x8 更省内存，大约 2 bpp，但细节会糊。

所以块越小，质量越好，显存越高；块越大，越省内存，但画质越差。

常用选择

普通场景颜色图： 可以用 ASTC 6x6 或 ASTC 8x8。

主角、重要角色、近景道具： 用 ASTC 4x4 或 ASTC 5x5。

UI、图标、文字类贴图： 尽量用高质量，比如 ASTC 4x4。压太狠会糊边、脏边。

透明贴图： 优先 ASTC RGBA。如果是 ETC1，要注意 ETC1 不支持 alpha，可能需要拆 alpha 通道。

法线贴图： 不要压太狠，否则光照会脏、会出现块状噪点。导入时要按 Normal Map 处理，并注意不要当普通 sRGB 颜色图。

Lightmap： 要看项目管线和 HDR 方案，重点检查色带、脏块和显存。

Unity 工程实践

Android： 新设备优先 ASTC，兼容老设备可以考虑 ETC2。更老的设备可能涉及 ETC1，但 ETC1 不支持 alpha。

iOS： 现代设备优先 ASTC。很老的 iOS 设备才考虑 PVRTC，但 PVRTC 画质限制比较明显。

还要配合这些设置：

Max Size：按屏幕占比限制最大尺寸。 Mipmap：3D 场景贴图通常开，UI 通常关。 Compression Quality：重要贴图高质量，远景贴图低质量。 sRGB：颜色贴图开，法线、Mask、数据贴图一般关。 Read/Write Enabled：不用 CPU 读写就关掉，省内存。 Crunch Compression：能省包体，但加载时可能有额外解压成本，不等于省运行时显存。

常见坑

不要所有贴图都用最高质量。 这样显存和包体会爆。

不要 UI 贴图压太狠。 按钮边缘、文字、图标会很明显变脏。

不要忘记 Mipmap 成本。 Mipmap 通常会额外增加大约三分之一贴图内存，但 3D 场景里能减少远处闪烁和采样压力。

不要只看编辑器效果。 贴图格式最终要在真机上看画质、显存、加载时间和发热。

面试加分说法

TIP

我会默认现代移动端优先 ASTC，然后按资源用途分档：UI、主角、法线用更高质量的 4x4 或 5x5；普通场景用 6x6；远景、地表、低细节贴图可以用 8x8。Android/iOS 分平台设置 Override，并用构建报告和 Memory Profiler 检查包体和显存。最后一定真机看压缩伪影，不能只靠默认导入设置。

粒子特效怎么优化？

标准回答

粒子特效优化的核心是：减少粒子数量、减少屏幕占用面积、降低透明 Overdraw、简化 Shader，并用对象池复用特效对象。

底层原理

粒子特效通常是大量透明面片。 它们会进入透明队列，很多时候 ZWrite Off，所以同一个屏幕像素可能被多个粒子反复绘制、反复混合。

所以粒子贵主要贵在：

粒子数量多，CPU 模拟和提交压力增加。 屏幕面积大，GPU 像素填充压力增加。 透明叠层多，Overdraw 上升。 Shader 复杂，采样、扭曲、软粒子、溶解都会变贵。 频繁创建销毁特效，会带来 CPU 开销和 GC 风险。

Unity 工程优化

控制 Max Particles。 限制峰值粒子数量，避免一个爆炸特效瞬间生成几千个粒子。

降低 Emission Rate 和 Burst。 发射频率和爆发数量要按机型、距离、画质档位调整。

减少粒子屏幕面积。 大面积烟雾、火焰、光晕最容易造成 Overdraw。贴图也要裁掉无效透明边。

简化粒子 Shader。 移动端少用折射、软粒子、多重贴图采样、复杂溶解和高成本噪声。

合并材质和贴图。 同类特效尽量共用材质、图集和 Shader，减少 SetPass 和 Shader Variant。

使用对象池。 特效播放结束后停止并归还池子，避免频繁 Instantiate / Destroy。

做特效 LOD。 近处高质量，远处降低粒子数、缩短生命周期、关闭子发射器或换低配版本。

做同屏限流。 同一时间屏幕上技能、爆炸、命中特效过多时，要限制数量或降低质量。

排查方式

用 Scene Overdraw 看透明叠层。 用 Profiler 看 CPU、GPU Time。 用 Frame Debugger 看粒子 DrawCall、材质和排序。 用真机测试看帧率、发热和耗电。

面试加分说法

NOTE

我优化粒子不会只看粒子数量，而是先看 Overdraw 热区和 GPU Time。因为很多时候粒子数量不算特别多，但屏幕面积很大、透明叠层很多，GPU 像素压力会非常高。实际项目里我会从粒子数量、贴图透明空边、Shader 复杂度、材质合并、对象池、LOD 和同屏限流几个方向一起处理。

如何验证优化效果？

标准回答

验证优化效果不能靠感觉，要靠“优化前后同场景、同设备、同配置”的数据对比。 一句话就是：先采基线，再做单变量优化，最后用真机数据证明收益。

验证流程

先明确优化目标。 比如是解决卡顿、GC、内存峰值、加载慢、包体大、发热，还是 GPU 压力高。

然后采集优化前基线。 同一台真机、同一个场景、同一段战斗流程、同一个画质档位，记录优化前数据。

再做单变量优化。 一次尽量只改一个关键点，比如先只改对象池、只改贴图格式、只改粒子数量。否则你不知道到底是哪一项带来了收益。

最后重新跑同样流程。 对比优化前后的平均帧时间、峰值帧时间、GC Alloc、内存峰值、加载耗时等指标。

要看哪些指标

性能类： FPS、Frame Time、Main Thread、Render Thread、GPU Time。

内存类： Managed Memory、Native Memory、Texture Memory、Mesh Memory、峰值内存。

GC 类： 每帧 GC Alloc、GC 次数、GC 耗时。

渲染类： DrawCall、SetPass、Overdraw、Shader Pass、后处理耗时。

加载类： 首包大小、进场耗时、切场景耗时、资源加载峰值内存。

体验类： 发热、功耗、掉帧、低端机稳定性。

Unity 常用工具

Profiler：看 CPU、GPU、GC、加载耗时。 Memory Profiler：看内存占用、资源是否泄漏。 Frame Debugger：看 DrawCall、SetPass、渲染顺序。 RenderDoc：深入分析 GPU Pass、贴图采样、Overdraw。 Build Report / Addressables Analyze：看包体、资源重复、Bundle 分布。

常见坑

只看 FPS 不够。 FPS 平均值可能很好，但偶发一帧 100ms 还是会卡。

只在编辑器测不准。 要用真机，最好是目标低端机。

没有优化前数据，就证明不了优化效果。 面试里说“我优化后快了很多”不如说“GC Alloc 从每帧 12KB 降到 0B”。

一次改太多，不知道谁有效。 优化要尽量单变量对比。

只看平均值，不看峰值。 游戏体验更怕尖峰卡顿。

面试加分说法

TIP

我验证优化效果会先建立基线数据，然后固定测试场景和设备，优化时尽量单变量修改。优化后用同样流程复测，重点看帧时间、CPU/GPU 耗时、GC Alloc、内存峰值和加载耗时。如果数据下降明显，再把 Profiler 截图、表格和版本号记录下来，防止后续功能迭代导致性能回退。