Unity手游CPU优化实战：GC、Draw Call与Canvas重建的定位与解决

做手游优化的时间长了，你会发现一个特别有意思的现象：手机一发热，团队第一反应永远是骂 GPU——“是不是特效加多了？”“是不是场景面数超了？”“后处理是不是开太狠了？”但实际用 Profiler 抓一轮下来，真正把帧耗顶穿的，往往是 CPU 侧那几个特别不起眼的开销。

今天这篇继续“发烫优化系列”，前几篇我把 GPU 和渲染管线的降载思路聊得比较多，这次反过来，专门审一审 CPU。在 Unity 项目里，CPU 侧最常出现、也最容易背锅的三大开销就是：GC、Draw Call 和 Canvas 重建。这三兄弟藏在业务代码、UI 逻辑和渲染提交里，一旦发烫或者掉帧，只要顺着主线程的耗时柱状图往下挖，大概率都能挖到它们。本文适合正在做移动手游性能优化、尤其是要做中低端机适配的开发者阅读，不扯引擎源码，不背 API 文档，就聊实战里如何定位、如何取舍、如何落地。

1. 先把锅分清楚：发烫为什么不能全怪 GPU

1.1 手机发热的物理来源

手机发热这事，本质上就是功耗问题。任何芯片工作都要吃电，电变成热，这是物理规律。CPU 和 GPU 都在片内，谁负载高谁发热大，但很多人对 CPU 的发热贡献是有误会的——总觉得 CPU 主要管逻辑，应该“不怎么热”。

实际在移动 SoC 上，CPU 主频可以拉得非常高，满载单核的功耗并不低。芯片温度一旦上来，系统会开始降频，于是出现一种经典现象：手机烫手，帧率反而掉，然后你再看占用率，CPU 和 GPU 都没跑满。这不是玄学，是 CPU 瞬时高负载触发了温度墙，系统在保命。所以在 Unity 项目里说“发烫优化”，核心思路不是看谁占用率高，而是看谁把功耗峰值顶上去的，CPU 和 GPU 都有可能。

回到日常开发，CPU 的每一帧工作是非常杂的：C# 业务逻辑、物理模拟、动画采样、粒子更新、UI 布局和网格更新、渲染命令拼装、网络包处理，这些全在 CPU 上串行执行。哪个环节做得多，CPU 功耗就高。做性能优化最忌讳“谁的饼画得大就改谁”，CPU 侧的细节经常被 GPU 的大块时间掩盖。

1.2 渲染瓶颈：GPU 背了多少锅

很多项目一发热就降画质、降分辨率，结果温度没下来，卡顿反而多了。为什么？因为你降的那些东西，压根就不是瓶颈。这里有个关键认知：渲染的最终执行者是 GPU，但渲染命令是 CPU 拼装和提交的。如果 CPU 提交命令太慢、太多，GPU 反而经常处于等待状态，占用率看起来不高，但帧率已经崩了。

用 Profiler 打开真机数据，常见的情况是：Main Thread（主线程）耗时很高，Render Thread（渲染线程）在等待主线程喂数据。这时候 GPU 有大量的空转等待，但芯片功耗并不低，因为整个渲染管线都在空转。它还表现为“gpu cpu 内存占用都不高但卡”——这就是典型的 CPU 提交瓶颈，尤其是 Draw Call 和 UI 重建引起的 Render Thread 阻塞。

所以我前几篇讲 GPU 降载，今天必须把 CPU 侧放上台面。要判断 CPU 是不是真凶，方法很简单：在 Profiler 里看主线程和渲染线程的耗时分布。如果渲染线程大量阻塞，或者主线程被某个模块卡了几百毫秒，那就别再去折腾 GPU 了，先查 CPU。

1.3 三大高发 CPU 开销：GC、Draw Call、Canvas

在 Unity 移动项目里，CPU 侧的高发开销非常集中，翻来覆去就是这几类：

• GC（垃圾回收）：C# 托管堆的分配和回收，表现为周期性尖峰。
• Draw Call（渲染提交）：CPU 向 GPU 提交绘制命令的开销，表现为持续高压。
• Canvas 重建：UGUI 在 UI 元素变化时重新生成网格的 CPU 开销，表现为点击、界面切换、飘字瞬间的卡顿。

这三样东西还有一个共性：它们往往同时出现。比如战斗界面里，你写了一段代码每秒更新血量文本，这个操作本身会产生字符串分配的 GC 压力，同时会触发 Text 组件所在的 Canvas 重建，再加上 UI 界面的图片和文字还可能拉高 Draw Call，一台中低端机就这么被一点点拖到发烫。排查时不能孤立看某一项，但最先动刀的顺序有讲究，后面逐个说。

2. GC：托管堆上的“定时炸弹”

2.1 Unity 的 GC 机制和“Stop the World”

Unity 项目里 C# 跑在 Mono 或 IL2CPP 上，内存由托管堆管理。你每次 new 一个对象、拼接一个字符串、调用某些会返回新对象的 Unity API，都会在托管堆上分配内存。GC（Garbage Collection）负责回收掉那些已经没有人引用的对象。

GC 是“Stop the World”的：回收过程中，整个 C# 环境会暂停执行，CPU 其他线程也可能被影响，等 GC 结束后才恢复。你可以把托管堆想象成一个仓库，每次 new 就是在仓库里画个格子放东西，东西放乱了、不够放了，维修工就要进场清扫：把所有不用的格子清掉，把小格子拼成大格子，这时候全仓库的人都要停下来等。如果仓库堆得越大，清扫时间就越长。

Unity 在 Mono 下有 SGen 分代 GC，IL2CPP 默认使用基于 Boehm 的保守式 GC，新版 Unity 还提供增量 GC（Incremental GC）选项，可以把一次长 GC 分摊到多帧执行。注意“分摊”不等于“免费”，增量 GC 往往会让每帧都多出一点额外开销，有些项目开启后反而更卡。所以在没有实测前，不要默认开。

2.2 GC 尖峰如何变成“发烫”和卡顿

一次完整的非增量 GC 在低端机上可能耗时几十毫秒，严重时上到几百毫秒，这对应到帧率就是灾难：平时 60 帧的画面，GC 发生时可能直接掉到个位数。如果项目里存在持续的零散分配，系统会每隔几秒触发一次小型 GC，CPU 的占用和功耗一直在高位波动，手机表面温度就会稳步上升。

这里有个非常隐蔽的现象：GC 导致的掉帧不是持续低帧，而是“平时流畅，偶尔卡一下”。这种毛刺很容易被测试人员忽略，但它对功耗的影响很大。因为移动端的调度器发现负载上升，会把 CPU 频率顶上去，顶上去之后就出现“温度升高、降频、继续卡”的恶性循环。

另外，GC 尖峰还会和垂直同步配合产生“假锁帧”现象：某一帧因为 GC 超过了 vsync 间隔，Android 上可能会触发后续帧的一连串掉帧，让你以为游戏被锁在 30 帧了。这种问题改帧率上限没用，必须把 GC 的根因找出来。

2.3 用 Profiler 揪出真正的分配点

排查 GC 问题，不要只盯着 Profiler 右上角的 GC 时间，那只是结果，不是原因。要看分配点在哪。

操作路径：Window > Analysis > Profiler，选择 CPU Usage 模块，在 Hierarchy 视图顶部勾选 “GC Alloc” 列，然后按这列排序。你会看到每个函数单帧分配了多少字节。注意，默认 Profiler 只能看到部分 Unity 内部标记，想要看到具体 C# 方法名，可以开启 Deep Profile，但这个选项会极大拖慢运行速度，不建议在真机上长时间开，可以在编辑器里抓一小段典型操作，比如“打开背包”“释放一次技能”。

拿到数据后，区分“一次性分配”和“持续分配”：初始化时的分配可接受，每帧都在分配的才是问题。比如说一个 Update 函数里每帧都GetComponent或者string +，GC Alloc 就会稳定在一个高水位，这种代码优先级最高。

2.4 降分配实操：对象池、缓存、避免装箱

优化 GC 的核心不是“让 GC 更快”，而是“让 GC 没活可干”。我总结了几个在项目里反复使用的降分配手段，按优先级排：

• 字符串拼接：循环里用StringBuilder，或者缓存模板字符串然后做格式化。Debug.Log 在正式包要全部关掉，它的字符串拼接是隐藏分配大户。
• LINQ：Where/OrderBy/First这类方法会产生迭代器和委托分配，能改成 for 循环就改。团队代码规范里直接禁掉在 Update 里使用 LINQ。
• Lambda 闭包：捕获外部变量的 lambda 会生成闭包类并可能装箱，事件和协程里尤其容易踩。
• Unity API 缓存：GetComponent、FindObjectOfType这类 API 内部有分配，反复调用不仅慢还产生 GC。在Awake/Start里缓存引用。
• 协程：频繁开启协程会产生 IEnumerator 对象，如果一定要用，考虑 UniTask 或自定义状态机。
• 数组和 List：每帧new List然后填数据再清空，是非常差的写法，可以用System.Buffers.ArrayPool<T>或者复用容器。

可以用下面这个表做代码评审时的快速对照：

GC 优化在代码评审阶段就要做，不要等到发热再去翻老代码。我曾见过一个项目，就因为飘字系统每帧string +拼接伤害数字，整场战斗 CPU 多了 10% 的开销，把帧率从 60 拖到 45。改掉那一个文件后，温度和帧率同时好了。

3. Draw Call：被低估的提交成本

3.1 Draw Call 到底在消耗谁的 CPU

Draw Call 在 Unity 里指的是 CPU 给图形 API 下发的一次绘制命令。很多人误以为 Draw Call 高 = GPU 压力大，其实不是。真正消耗 CPU 的是状态切换和命令提交，尤其是 SetPass Call——在切换 Shader、纹理、混合模式时，驱动要做一堆状态绑定和校验。这些发生在 CPU 侧，发生在主线程和渲染线程的命令拼接阶段。

在移动端和 PC 的架构又有区别。PC 上 CPU 和 GPU 通过 PCIe 高速通信，Draw Call 驱动的吞吐能力强一些；移动端是 SoC 内部共享内存，命令提交的固定开销更大。这也是为什么同一个场景在 PC 上 DC 很高没事，打包到手机上就开始卡和发热。所以移动端必须对 DC 数值更敏感。

当 Draw Call 过高时，Profiler 里会看到 Render Thread 大量时间花在阻塞等待上，GPU 占用率反而不高。这种 CPU 与 GPU 的错位是发热优化的重点排查点，因为它不会体现在“降低画质”上，必须从合批和提交数量入手。

3.2 合批机制怎么选：Static、Dynamic、SRP Batcher、Instancing

Unity 提供多种合批手段，但每种都有适用边界，选错反而更亏。我按实际项目经验给你做一个横向对比：

这里特别说一下 SRP Batcher。如果你用的是 URP，且 Shader 是 Standard 或者升级到兼容 SRP Batcher 的方式，那么就算 DC 数字不低，实际 CPU 提交开销也会比旧的 Batcher 小很多。有些项目把 DC 优化到很低，但没用 SRP Batcher，帧耗还是高，反过来又去追求更极端的 DC 数量，其实方向错了。新版 URP 项目第一步应该是先开启 SRP Batcher，再谈手动合批。

3.3 网格与包围盒的隐藏开销

很多场景 Draw Call 不高，渲染线程却依然耗时，问题可能出在包围盒（Bounds）上。Unity 的视锥剔除（Frustum Culling）和遮挡剔除（Occlusion Culling）都依赖包围盒判断。当你合并静态网格后，原来两个相距很远的物体被合成一个大网格，包围盒也会变成能罩住两者的超大型包围盒，只要视角能看到其中一个物体，整个合并网格就会全部提交给 GPU，DC 是降了，但顶点和像素白算了一大堆。

SkinnedMesh 和粒子系统也经常出现包围盒虚大的情况：骨骼动画如果某个动画帧脚踢得很远，Bounds 会被拉得很大；粒子系统生命周期长、喷射范围大，Bounds 也会铺满全场。结果就是物体根本不在视锥内，却仍然在提交绘制，CPU 和 GPU 都在做无用功。

排查技巧：打开 Scene 视图，选中 Renderer 看 Bounds 线框，或者用 Profiler 的 Rendering 模块对比“可见物体数”和“总物体数”。如果不可见物体还在渲染，优先处理包围盒。对于超大网格合并，必要时拆回多个小网格，不要让合批的收益被剔除失效吃掉。

3.4 DC 优化的边界：不要盲目追求低数字

“Draw Call 小于 100 才算合格”“DC 必须是两位数”——这种拍脑袋的目标很容易把项目带偏。DC 是手段，不是目的。正确的做法是看目标设备上渲染线程的耗时：如果 Render Thread 占帧耗不到 10% 且没有阻塞，DC 数量没必要硬压。

优化 DC 的实践顺序，我会这么排：

• 第一优先：确认 SRP Batcher 开启了，且 Shader 兼容。这是性价比最高的。
• 第二优先：相同网格的重复物体上 GPU Instancing。草、树木、路灯、重复的小道具，收益极明显。
• 第三优先：静态场景做 Static Batching，但提前评估内存预算和包围盒问题。
• 第四优先：UI 部分用图集合并 Sprite，减少 UI 的 Draw Call。注意要重新权衡 Canvas 数量，UI 的 Canvas 拆太碎也会增加开销。

我见过一个反例：团队为了把 DC 从 400 压到 150，把所有静态物体强行合并成一个大网格，结果内存暴涨，包围盒问题导致远处可见物体全部被提交，实际帧耗时反而变长了。冷静下来一测，发现 DC 300 的时候 Render Thread 才 3ms，根本没必要动。先看数据，再定目标。

4. Canvas 重建：UI 卡顿里最隐蔽的那一环

4.1 UGUI 的“画布重绘”到底在干什么

UGUI 的 UI 渲染不是“每个图片单独画”，而是 Canvas 统一收集所有 Graphic 组件的网格，打包成一批数据再提交给 Canvas Renderer。这个打包和网格生成的过程，Unity 内部叫 Rebuild（重建）。它有两大块：Layout Rebuild（布局重算）和 Graphic Rebuild（图形网格重生成）。

你可以这样理解：Canvas 是一块电子画板，每个 UI 元素是画板上的图案，当你改动其中一个图案的位置或内容时，为了让所有图案的遮挡关系正确，Unity 可能需要把这块画板上涉及脏区域的图案全部重新画一遍。你只是给一个按钮挪了 1 像素，但如果这个 Canvas 下有几十个元素，那这几十个元素的网格都可能要重算。

而且 Layout 组件的开销更大。如果 Canvas 下挂了一个 VerticalLayoutGroup，子元素变化时，Unity 要重新计算所有子元素的布局，再同步布局结果给锚点和 RectTransform，最后才进 Graphic 重建。这一步的 CPU 消耗是呈指数级反应的，子项一多就卡。

4.2 触发重建的高危操作

在我经手的项目里，UI 重建的高危操作其实非常集中，写在这里给各位排雷：

• SetActive切换显隐：对 UI 游戏对象频繁 SetActive，尤其是挂在 Canvas 根节点或带 LayoutGroup 的父节点下，会造成整棵子树的布局和图形重建。
• 修改 RectTransform：sizeDelta、anchoredPosition、pivot、rotation、scale这些属性的改变都会把 Canvas 标脏。
• 修改文本内容：Text 组件的 text 变化会重新生字网格，TextMeshPro 也一样。
• 修改 Image 的属性：比如切 sprite、改变 fillAmount、开 raycastTarget。
• LayoutGroup 被打扰：任何子项增删或尺寸变化都会触发整个布局组重排。

其中坑最深的是“飘字”和“血条”这类高频更新元素。如果你把它们和整个战斗界面的背景、按钮、头像放在同一个 Canvas 里，那么每帧更新飘字位置或血量文本，都会让那个巨大的 Canvas 持续重建。这不是“优化图片不清晰”能解决的，必须从 Canvas 结构上拆。

4.3 划分 Canvas 的黄金法则

对于 Canvas 重建，最有效的策略就是“拆分”。但拆分不是随便拆，要按变化频率来拆。

我的实践原则很简单：

• 静态 UI 一个 Canvas：背景、常驻按钮、标题栏这类几乎不变的元素，放在一起。
• 高频动态 UI 单独 Canvas：飘字、血条、伤害数字、倒计时、进度条，每个高频区域独立 Canvas，或者至少独立于静态 UI。
• 界面级大切换单独处理：比如背包界面、弹窗、任务面板这种从隐到显的整个界面，如果要经常开合，它们自成一个 Canvas 比隐藏在根 Canvas 下反复 SetActive 要好。
• 控制 Canvas 数量：不要为了优化把一个界面拆成几十个 Canvas，每个 Canvas 又是一次批处理提交。移动端经验是，一个主战斗界面控制在 3-6 个 Canvas 比较合理。

这样拆分之后，战斗飘字变化时，只会重建它所在的小 Canvas，静态背景的 Canvas 完全不用动，收益是立竿见影的。

4.4 从 Profiler 的 Canvas 模块定位问题

定位 Canvas 重建，可以在 Profiler 里切到 CPU Usage 模块，搜索Canvas相关的函数名，比如Canvas.SendWillRenderCanvases、Canvas.BuildBatch、Canvas.RenderOverlays。如果这些函数单帧耗时不低，并且每帧都在出现，说明确实有 Canvas 在持续重建。

更直观的方式是用 Frame Debugger：打开后选中“UI”相关的 Draw Call，可以看到每个 UI 网格的来源和顶点数据，配合 Scene 视图能快速反查是哪个 Canvas 下的哪些元素太杂。

还有一个土办法：拆分前在 Canvas 上挂一个 DEBUG 脚本，在OnRectTransformDimensionsChange或Canvas.willRenderCanvases事件里打印日志，看看哪些 Canvas 每帧都在被标记重建。实际项目中我用这个方法快速定位过某活动的“礼包小红点”，它每帧改 position，导致整个主界面 Canvas 每帧重建。

UI 优化和 GC 优化经常要一起做：比如文本更新时用缓存字符串避免分配，同时也减少了 Text 内容变化导致的 Graphic rebuild。TextMeshPro 比普通 Text 在内存和重建方面有一定优势，但也需要注意字体 fallback 和多语言动态字体，这块也是移动端发热的隐形地雷。

5. 一套可落地的排查流程与防回退

5.1 发热/卡顿问题的排查顺序

真机发热问题的排查，我认为按这个顺序走最不容易漏：

1. 先接真机 Profiler，截取一段有代表性的操作（比如打一场战斗，或者打开 3-4 个核心界面）。
2. 看 Main Thread 总耗时，确定掉帧源头是 CPU 还是 GPU。GPU 高就查渲染设置，CPU 高就继续往下分。
3. 把 CPU 耗时按模块排序：Scripts / Rendering / UI / Physics / Animation，看哪个占比高。
4. 如果 Scripts 高，切到 Hierarchy 并按 GC Alloc 排序，查分配热点。
5. 如果 Rendering 高，看 Draw Call 数和 Render Thread 阻塞情况，再用 Frame Debugger 分析合批。
6. 如果 UI 高，重点看 Canvas 重建，检查是否有高频元素和静态元素混在同一个 Canvas 下。

这套流程里最容易被忽略的是第 4 步和第 6 步，因为它们经常同时发生。比如血量数字更新，既产生 GC Alloc，又触发 Canvas 重建，你只修一个，另一个照样拖累性能。

5.2 设定性能指标：从“感觉卡”到“数据说话”

优化没有指标就是空谈。我在项目里通常会定这几条硬指标，分别卡住本文说的三座山：

• GC Alloc：战斗场景平均每帧不超过 2KB，峰值不超过 8KB（低端机还要更严）。
• Draw Call：以目标机型实测为准，一般中端机除 UI 外场景 DC 控制在 200-300 以下，Render Thread 每帧耗时不超过 8ms。
• Canvas 重建：单帧Canvas.BuildBatch耗时不超过 1ms；战斗中高频刷新区域必须是独立小 Canvas。
• 帧耗时：取 P95 不超过 33ms，也就是 95% 的帧不能掉出 30 帧的节奏。

这些指标要写成文档，挂到 CI 上做检查。Unity 有 Performance Testing Extension，可以写自动化用例跑固定场景的 CPU 耗时和 GC 分配，一旦超过阈值就标红拦截。新功能合入主分支之前先跑一遍性能门禁，比等用户反馈发热再返工靠谱得多。

5.3 常见问题速查表

关于最后一个问题多说一句：有时你看到 CPU 不忙、GPU 也不忙，但游戏就是卡。这种情况大概率是某一帧出现了一个极长的任务（比如 GC 或磁盘读取），把整体节奏打乱了。不要被平均占用率迷惑，回来拉时间轴找尖峰，比什么都能解决问题。

这次把 CPU 侧的三座山搬了一下，我实际带项目的体感是：GC 优化收效最快，Draw Call 排查最直观，Canvas 重建最容易被忽略。建议新项目从立项就把这三项指标当成硬门禁，别等线上用户反馈发热再来救火。最后再分享一个排查小技巧：真机上发热问题不要只盯着 Profiler 的平均值，多看看帧时间的“毛刺”。很多发热不是一直高，而是偶尔一次全量 GC 或 UI 重建把频率顶上去，这时打开 Profiler 的时间轴，拉一条标尺对准尖峰，基本都能找到真凶。优化到后面你会发现，CPU 不是不肯背锅，是大家一直没让它在 Profiler 里把话说清楚。