手机厂家这些年把散热堆得再猛，也架不住游戏内几个毫秒的CPU峰值负载把机身烤成暖手宝。很多团队查发烫问题时习惯性把矛头指向GPU，但拿Unity出的包在真机上跑一遍Profile，你会发现CPU经常比GPU更忙。尤其是GC、Draw Call和Canvas重建这三个隐形大户，它们不直接画像素，却能让CPU在每一帧里做大量无用功，最终反映到温度计上。
这篇是发烫优化系列的第5篇，我把我们在实际项目里踩过的坑和收敛路径展开聊。无论你做的是重度ARPG、数字孪生大屏，还是微信小游戏里的复杂HUD，这篇文章应该都能帮你找到一条可执行的排查思路，而不是看到Profiler一堆数据无从下手。
1. 移动端发烫这事，CPU 的锅一点都不小
1.1 功耗与发热：为什么CPU忙起来手机就烫
芯片发热的本质是电能转化为热能，转化率跟工作负载直接相关。GPU在渲染画面时确实功耗高，但CPU在移动端上同样不可小觑——它要跑游戏逻辑、物理模拟、动画求值、UI布局、渲染状态提交、内存分配回收。很多时候CPU的核心频率被调度器拉满，整机功耗就上去了。
我见过一个典型的场景：一款3D战斗玩法的游戏，发热严重，团队先给GPU做了各种降画质方案，效果不理想。后来真机Profile一看，一帧里CPU侧Rendering模块耗时比GPU渲染还高，Draw Call和SetPass Call占了渲染线程一大半时间。CPU在准备渲染状态的时候，GPU反而在等着喂数据，这种状态下功耗一点都下不来。
要在移动端把温度压住，第一步是承认CPU和GPU是一对需要同时照顾的搭档。只看GPU指标、忽略CPU侧的准备和提交流程，发热问题经常治标不治本。
1.2 站在Profiler面前：CPU时间的三个常见去向
用Unity Profiler连接真机抓一帧数据，CPU耗时通常集中在三块：
- 脚本与GC：Mono或IL2CPP运行时里，Update、协程、事件回调中的逻辑，以及每次分配内存后垃圾回收产生的停顿。
- Rendering与Draw Call：这个模块看起来是“渲染”，但时间并不一定花在GPU上。当Draw Call数量高、合批失败时，CPU需要反复切换渲染状态、提交顶点数据。
- UI与Canvas：UGUI的网格重建（Canvas Rebuild）和批处理（Batch Build）是纯CPU开销，UI越复杂、越频繁变化，耗时越吓人。
这三块对应了开篇标题里的GC、Draw Call和Canvas重建。后面每个部分我都会展开讲它们的形成原理、定位方法和实际优化手段。在这之前，先记住一句话：发烫不是单一指标高，而是CPU侧某一项或多项峰值超出预算。
2. GC：托管堆上的“搬家公司”，该省的成本必须省
2.1 先搞懂GC触发时机和卡顿原理
Unity的托管堆使用Boehm GC（在老版本Mono和IL2CPP环境下常见），它是一种非分代、非移动的Mark-Sweep垃圾回收器。听起来术语多，用大白话讲：你的C#脚本在堆上不断申请内存装临时对象，堆大小不够了就触发一次全局扫描，把还活着的对象标记一下，其余全部回收。
问题出在两点：第一，Boehm GC的扫描是Stop-The-World，触发时所有托管线程暂停，哪怕只暂停3~5毫秒，在60帧游戏里也直接造成掉帧卡顿；第二，每次GC不一定会完全回收干净，堆碎片多了之后，新分配可能触发更频繁的更长的回收周期。这就是GC Alloc高的地方掉帧明显的直接原因。
很多新手以为只要总内存不大就没事，其实GC最伤人的不是内存占用，而是回收时机的不可控。一次性能测试里可能平均只有0.5ms的GC耗时，但波动峰值却到了30ms，游戏体感就是“每隔几秒顿一下”。这个卡顿比持续发热更让玩家崩溃。
2.2 用Profiler找出真正的GC Alloc来源
定位GC问题，我用得最多的还是Unity Profiler的CPU模块。在Timeline或Hierarchy视图里，给每一列打开GC Alloc显示，按分配量排序，能快速锁定哪些函数在每帧疯狂创建垃圾。
这里有个操作细节：普通Profile模式只能看到函数总耗时和分配总量，看不到具体分配点。要拿到准确的调用栈，需要开启Deep Profile，但Deep Profile会大幅拉慢运行速度，通常只在Editor里跑短场景用。我建议日常先不开启Deep Profile，先用Profiler找到GC Alloc值最高的函数，再针对该函数做代码审查，80%的垃圾都能靠肉眼揪出来。
还有一个被很多人忽略的定位手段：Memory Profiler包。它能抓托管堆快照，能直观看到堆里都有哪些类型的对象、哪些大对象一直没被回收。用它分析游戏跑了一段时间后堆大小为何降不下去，比看代码更快。
2.3 高频代码路径上的实战优化手法
场景里的战斗、UI数值刷新、日志输出，是GC垃圾产生最密集的几条路径。我把实际项目中碰到的典型问题整理成下表，每一条都对应一个真实踩坑案例：
| 常见写法 | 隐藏的GC分配 | 推荐改法 |
|---|---|---|
string + string做UI文本拼接 | 每次+运算都会生成新字符串 | 用固定长度的StringBuilder，或在TMPro里用SetText格式化 |
| Debug.Log频繁输出 | 即便日志不显示，参数装箱和字符串格式化也会分配 | 发布版本删日志，调试版用条件编译 |
| foreach遍历非泛型集合（如ArrayList） | 迭代器生成临时对象 | 换成List或数组，或直接for循环 |
| LINQ的Where/OrderBy/Select | 闭包和迭代器分配明显 | 高频路径手写循环和判断 |
协程里yield return new WaitForSeconds(1f) | 每次新WaitForSeconds对象 | 缓存WaitForSeconds实例，或用倒计时变量自减 |
| 把值类型传入object参数的方法 | 隐式装箱产生堆对象 | 重载方法，或改用泛型方法规避装箱 |
高频路径上最狠的一条是字符串拼接。比如血条上每秒更新一次的伤害数字，如果用"HP: " + currentHp + "/" + maxHp这种写法，每帧都会产生若干字符串垃圾。换成统一的StringBuilder.Append，或者TextMeshPro的SetText(string format, int param)接口，GC分配直接归零。
2.4 从数据看GC优化前后差距
我之前接手过一个三消项目，棋盘消除时大量特效和分数文本刷新，Profile看到一帧最高分配3.2MB，GC耗时峰值14ms，卡顿感非常明显。优化手段不复杂：缓存通用特效对象的对象池、把分数文本改成IntToString方式复用、清理所有Debug.Log、协程等待改为缓存实例。
优化后同样场景一帧分配量降到180KB，GC峰值耗时1.8ms，整体帧数从42帧提升到稳定55帧以上，发热体感直接下降一个等级。GC分配的削减还会连带减少芯片核心频率的峰值波动，这才是对温度最实质的帮助。
要注意别做极端优化。有些团队连必要的数据结构都不new，硬用数组模拟链表，结果代码复杂度爆炸。平衡的标准是高频、每帧执行、持续时间长这三条路径优先治理，低频初始化阶段的分配放掉不管。
3. Draw Call：CPU和GPU之间的“订单”，每一单都有成本
3.1 一次Draw Call背后发生了什么
很多人把Draw Call理解成“GPU画东西的次数”，这个说法不准确。Draw Call实际上是CPU向GPU发出的一次绘制命令，但CPU要先做一堆准备工作：设置当前Shader、绑定材质参数、指定网格顶点缓冲区、切换渲染状态（深度、透明、裁剪等），最后才提交命令。
其中状态切换是最贵的，尤其是Shader Pass切换（SetPass Call）。移动端GPU架构对这种频繁状态切换格外敏感，因为驱动层、渲染API层的校验和提交都是CPU开销。Draw Call数量上去之后，渲染线程变成瓶颈，GPU多半时间在等CPU喂数据，功耗自然降不下来。
一个很容易踩的坑是只看Draw Call总数，忽略SetPass Call。两个场景Draw Call都差不多，但一个SetPass Call只有20，另一个有180，后者CPU开销能差3倍以上。所以优化目标应该是同时控制Draw Call和SetPass Call。
3.2 四种合批方案怎么选，别被Batching眯了眼
Unity提供多种合批手段，误区是以为用了SRP Batcher就万事大吉，或者疯狂用Dynamic Batching导致CPU更忙。我按适用场景拆开讲：
- Static Batching：适用于场景里不动的物体（地面、墙壁、静态装饰）。Unity会把多个静态网格合并成大网格，运行时一次提交。代价是内存占用升高，而且要求物体确实不会动。做一个大世界时，Static Batching和遮挡剔除配合，能把场景Draw Call压得很低。
- Dynamic Batching：自动合并符合条件的小物体，但顶点数量限制很严（不同Unity版本约在225~900三角形范围内波动），而且合批计算本身有CPU开销。在移动端，我几乎不推荐依赖Dynamic Batching，除非是很小的物体且数量极少。它经常出现“省了Draw Call反而CPU更高”的负优化。
- GPU Instancing：处理大量相同Mesh、相同Material的物体（草、树、敌人、弹幕）的最优解。同样的物体几千个，用Instancing可能只要几个Draw Call。同一个材质想做出不同颜色，配合MaterialPropertyBlock设置每实例属性，不要复制材质。
- SRP Batcher：使用URP或HDRP时的强力方案。它不看网格是否相同，而是通过Shader中绑定数据的持久缓存，让CPU在Draw Call之间减少绑定开销。只要Shader能走SRP Batcher路径，批处理效果很理想。集成URP的项目建议首个选项就是开启SRP Batcher。
框图说明：Static Batching减的是提交命令数量，SRP Batcher减的是命令之间状态切换开销，两者不冲突，可以同时开启。
3.3 Frame Debugger和Profiler配合定位
定位Draw Call问题，我每次都会先开Window > Analysis > Frame Debugger。它会逐条列出这一帧的每个Draw Call、当前用的Mesh、Material、Shader Pass，以及关键信息——如果某个Batch被拆开，它还提示了Break原因。
最常见的Break原因是什么？材质实例不同、网格不同、光照/Shadow设置不同、网格数据带Lightmap UV而别的没有、材质里某些属性触发了实例化。看到Break原因后，修复方向就清楚了：要么统一材质、要么走图集、要么重新烘焙光照、要么通过脚本把物体按材质分组合批。
Profiler里的Rendering模块则能看到CPU提交这些Draw Call具体耗时。重点是看渲染线程里BatchRendererGroup、CommandBuffer相关的耗时点，如果这些耗时和Draw Call总数同比例上升，基本坐实了CPU渲染提交瓶颈。
3.4 实战合批组合拳：图集、遮挡剔除、材质合并
一个ARPG关卡从2000+ Draw Call缩减到300+，我们组合用了以下几招，顺序很关键，每一步的效果都能叠加：
- 先开遮挡剔除（Occlusion Culling）：Unity会生成遮挡数据和包围盒计算，相机看不到的物体不提交。别小看这一步，户外场景经常能直接砍掉40%以上Draw Call。
- 再上纹理图集：UI、特效、贴花这些小图合并成大图集，材质数量降下来，合批率立刻上升。注意图集尺寸控制在1024以内比较稳妥，过大容易涨内存和加载耗时。
- 材质和Shader统一：同一个项目里出现十几个变体Shader，再好的合批方案也白搭。我通常把同类型物体的Shader尽量统一，用Uniform参数做区分，变体数量严控。
- 最后做Static Batching：对确定不动的静态场景部分开启，同时配合Lightmap烘焙，减少实时光照带来的额外Pass。
还有一个容易被忽略的点：阴影。动态阴影对Draw Call的放大效应非常明显。很多团队优化完主体Draw Call后，阴影一照又翻倍。我建议先检查阴影距离和级联数是否合理，必要时用Single Shadow Map，或者对重要物体单独控制阴影投递。
4. Canvas重建：UI隐形的CPU刺客，尤其复杂HUD或数字孪生界面
4.1 Canvas Rebuild到底在重建什么
UGUI的渲染模型是：Canvas把所有UI元素合并生成一个或多个大网格，再交给Canvas Renderer渲染。所谓重建（Rebuild），就是当UI元素的布局、顶点、材质发生变化后，Canvas要把这些变化重新生成到网格里。
重建分两类：Layout Rebuild（布局重建，比如LayoutGroup重算子项位置）和Graphic Rebuild（图形重建，比如Image改Sprite、Text改字符串、RectTransform改尺寸）。不管哪一类，最终都会走到批量网格合并（Batch Build），这是纯CPU工作。
问题在于，同一个Canvas下的所有UI元素共享一个批处理单元。哪怕只是改了HUD右上角一个血量数字，如果整个Canvas里还有几十个静态按钮和装饰元素，这些元素也可能跟着重新参与合并，浪费大量CPU时间。UI元素越多、挂的Layout组件越深，重建时的计算量越夸张。
4.2 哪些操作会触发UI重建（最常见踩坑清单）
结合线上项目的踩坑经验，我把触发UI重建的常见操作整理成一个速查表：
| 操作 | 影响范围 | 严重程度 |
|---|---|---|
| 修改Text的text字符串 | 该Graphic重建，字体图集可能更新 | 高 |
| 修改Image的sprite或color | 该Graphic重建 | 中 |
| 修改RectTransform的sizeDelta | 该元素及其Layout父级重建 | 高 |
| 修改RectTransform的anchoredPosition | 该元素重建 | 中 |
| 启用/禁用UI元素（SetActive） | 整个Canvas Batch重建 | 高 |
| LayoutGroup内子元素变化 | 整个LayoutGroup重排 | 极高 |
| 改变Canvas.enabled或CanvasGroup的alpha | 整个Canvas Batch重建 | 高 |
注意SetActive这个操作尤其危险：频繁隐藏和显示UI界面元素，导致整个Canvas的Collapse和Rebuild，每帧多次的话CPU直接拉满。以前排查过一个案例，某个UI面板为了做“呼吸灯”效果，每帧切换一个子物体SetActive，Canvas Batch时间从0.4ms涨到6ms，温度飙升。
4.3 Profiler定位与动静分离实践
在Profiler里定位UI开销，看UI模块中的Canvas.SendWillRenderCanvases、Canvas.BuildBatch和Layout.Reorganize几项耗时。如果这几项时间占比高，基本可以确定是Canvas重建问题。
最关键的手段是动静分离：把频繁变化的UI元素（血量、分数、坐标信息）放到独立的Canvas，静态UI元素（背景、按钮、纹理装饰）放到另一个Canvas。这样动态元素变了，静态Canvas不会跟着重建。我在做一个数字孪生大屏项目时，界面左边固定面板、中间地图叠加层、右侧实时参数列表，分了三层Canvas，UI线程耗时从平均7ms降到1.8ms。
除了分层，还要清理Raycast Target。默认创建的Text、Image都勾选了Raycast Target，即使你压根没给它们挂点击事件，系统每帧依然会为它们做射线测试。我见过一个商店界面几百个UI元素全是Raycast Target，UI事件开销直接占了2~3ms。批量把不需要交互的UI元素的Raycast Target关掉，是成本最低但收益很明显的优化。
文本更新是另一个重点。TextMeshPro（TMP）比老Text快不少，但字符串拼接照样产生GC。TMP提供了SetText()的重载，可以传整数、浮点数并指定格式，直接写入内部缓冲区，既省GC又省重建。尽量别频繁改动字体，需求上允许的话，把静态文案拆成不参与动态更新的子物体。
5. 发烫优化的完整排查流程与实测数据
5.1 一套可复用的标准流程
很多人拿到发热问题就开始乱试，这里改一点那里调一下，最后根本不知道哪个改动生效了。我实践中沉淀出一套固定流程，每一步都有对应的量化数据支撑：
第一，选一个稳定复现的发热场景。比如持续战斗2分钟、主城地图旋转镜头、复杂UI大屏自动轮播，场景必须保证可重复，否则前后对比没意义。
第二，真机连Profiler，抓5分钟数据。真机性能数据和Editor完全不同，Editor里Draw Call和GC没有任何说服力。Android上用PerfDog辅助看功耗曲线和帧率曲线，iOS上用Instruments或Xcode自带的帧调试工具。我会同时记录：平均帧率、最低帧率、CPU平均耗时、整体温度曲线。
第三，按“GC峰值 > UI重建 > Draw Call”的顺序横向排查。先看Profiler里是否频繁出现GC Alloc尖刺，有的话先修；再看UI模块耗时；最后用Frame Debugger看Draw Call数量。这个顺序不是绝对的，但通常GC尖刺对卡顿体感影响最大，应该先解决。
第四，每修完一个问题，用同一场景重新测一遍。不要贪多，一次只改一类问题，用Profile Analyzer工具把优化前后的帧数据对比，确认收益。我见过团队一次性改了几十个优化点，结果最后一个也没验证成功，出了问题也不知道是谁引入的。
5.2 优化收益实测与维护习惯
分享一组真实项目数据，这个项目是移动端吃鸡类玩法的原型，发热场景集中在刚枪和跑毒阶段：
| 指标 | 优化前 | 优化后 | 手段 |
|---|---|---|---|
| 平均帧率 | 43fps | 57fps | GC分配砍半 + Draw Call合批 |
| 最低帧率 | 28fps | 47fps | UI动静分离 |
| 帧内最大GC Alloc | 2.1MB | 240KB | 字符串、LINQ、日志清理 |
| 整机温度（30分钟） | 46度 | 41.5度 | 以上综合 |
温度能降下来，核心不是某一招多神奇，而是CPU峰值被压平了。给芯片一个更平滑的负载曲线，调度器就不需要频繁拉高主频，整机功耗自然降低。
维护习惯上，我建议在CI阶段引入批量Profiler测试：用Batch模式跑一段固定场景，解析Profiler数据，把GC Alloc、Draw Call、帧耗时作为门槛，超了直接报警。不要让性能问题靠上线后玩家反馈来发现。另外，版本更新时用PerfDog对比前后功耗曲线，比“感觉流畅了”靠谱得多。
再补充一个容易翻车的细节：优化后一定做兼容性测试。不同机型上的合批策略和GC表现差异很大。低端机上Dynamic Batching可能更慢，高端机上SRP Batcher收益又很明显。优化方案是否通用，要靠三档机型至少各测一轮来判断。
写在最后的一点个人体会
做了这么多年Unity优化，我最大的感触是：发热不是单一指标造成的，GC、Draw Call、Canvas重建经常纠缠在一起。一个人物血条更新，可能同时触发字符串分配、Canvas重建，再加上动态阴影开启，三个坑一起踩。定位的时候不要凭直觉猜，要让Profiler帮你说清楚问题在哪，然后按本篇文章这套策略逐项治理。
最后分享一个小技巧：每次改动前先用PerfDog保存一段功耗曲线，改动后再存一段，把两条曲线叠一起对比。只要功耗曲线整体下移且波动更平缓，这次的优化就一定有效。先降峰值，再降平均，温度自然就下来了。
