1. 从“手感不对”说起：发热是Unity游戏最诚实的体检报告
如果你的游戏手机温度稳定爬升，帧率却稳如老狗，我反而会更担心——因为热量守恒，热量不会凭空消失，它只会从芯片转移到外壳，再从外壳转移到你掌心。多数情况下，发热和掉帧是同一个问题的两种表象，只是掉帧发生在CPU/GPU内部，你看到的是结果；发热发生在物理层面，你摸到的是结果。
我在移动端Unity项目上摸爬滚打这些年，最深的体会是：发热不是Bug，而是系统在对你讲真话。它就像汽车的仪表盘报警灯，亮起来不代表灯坏了，而是说明发动机舱里有些东西不对劲。把报警灯拆了（锁帧率、降分辨率、一刀切地砍画质）当然能“解决问题”，但它掩盖了真正需要你关注的病灶。
这个系列，我打算从“症状→病因→病理→治疗→预防”这条路径，系统拆解Unity移动游戏越玩越烫这件事。作为第1篇，我不急着给优化方案，而是先把整个发热链路铺开，帮你建立完整的认知框架——因为你连热量从哪来、为什么积在那里、为什么是“越玩越烫”而不是“一进游戏就烫”都说不清楚，后续所有优化手段都只是在碰运气。
先说结论：移动端Unity游戏发热，绝大多数情况下是“CPU工作时间太长”和“GPU工作强度太高”共同作用的结果，再加上内存分配的“余温”和电池化学反应的“底火”。这四个因素不是孤立存在的，它们会互相放大，形成一个自我强化的发热循环。下面我把每个环节掰开揉碎讲清楚。
2. 热量从哪里来：CPU、GPU、内存和电池的四重奏
2.1 CPU：Unity脚本层是热量制造机的大头
很多刚入行的开发者有个错觉，觉得CPU承担的活儿不多，渲染都交给GPU了，CPU应该很闲。这个认知在纯图形Demo里可能成立，但在真实游戏项目里完全不是这么回事。Unity的脚本层（C#）运行在CPU上，而脚本层干的活儿包括但不限于：游戏逻辑、物理模拟、动画状态机、寻路、UI布局、资源加载、生命周期回调。任何一个环节写得不讲究，CPU都会加班。
举一个我实际踩过的坑。项目里有张大地图，上面有几百个NPC，每个NPC的AI逻辑在Update里每帧都执行一次完整的“感知→决策→行动”流程，里面有几个List的排序，排的是仇恨列表。当时测出的结果是，在主流中端机型上，光AI这块每帧就要吃掉8-12毫秒的CPU时间。什么概念？如果目标帧率是60FPS，整帧预算只有16.6毫秒，AI一个模块就干掉大半。
而且CPU发热还有个隐蔽的地方：越热，频率降得越快，频率降了，同样的逻辑需要更长时间跑完，CPU工作时间更长，热量继续累积。这个恶性循环在移动端尤为典型，也是“越玩越烫”里那个“越”字的重要来源。PC上你可能只觉得帧率波动，但手机上你摸得到温度在节节攀升。
2.2 GPU：渲染压力不只是分辨率的事
GPU的发热逻辑更直观——它要处理的像素越多、着色器越复杂、Overdraw越严重，单位时间内干的活儿就越多，功耗就越高。很多团队优化的时候只盯着分辨率，把渲染分辨率从1080P降到720P，觉得问题就解决了。这当然有效，但它治标不治本。
真正吃GPU的大户，按经验排序大概是：
- Overdraw（过度绘制）：半透明粒子层层叠叠，UI界面嵌套多层全屏半透明面板，每帧每个像素被画了好几遍，GPU白白加班。
- 复杂的片元着色器：尤其是一堆点光源、实时阴影、动态全局光照叠加的场景，片元着色器的计算量会飙到非常恐怖的数字。
- 高分辨率纹理配合糟糕的采样方式：各向异性过滤拉满，再加上纹理压缩格式不合适，带宽被大量浪费。
- 后处理特效：Bloom、景深、抗锯齿、色彩校正，每个都是全屏pass，每加一个，GPU的工作量就成倍往上翻。
我见过最离谱的一个案例，美术在场景里放了上百个实时点光源，每个光源的Range还拉得特别大，导致几乎每个像素都要被几十个光源轮番计算。真机跑起来，帧率倒还是能看——但手机温度在五分钟内就冲到45度以上，机身烫得根本握不住。这种就是典型的“GPU过载型发热”，和CPU没太大关系。
2.3 内存分配：GC的“体温”往往被严重低估
这一条很多人会忽略，但它的杀伤力其实非常大。C#的托管内存分配本身不发热，发热的是垃圾回收（GC）。当你在Update里频繁new对象、拼接字符串、使用LINQ，就会产生大量内存垃圾。Unity的Mono或IL2CPP运行时会在合适的时机触发GC，把不再使用的对象回收掉。
GC是个什么活儿？它会暂停游戏主线程去扫描托管堆，标记可达对象，然后清理不可达对象。这个过程是纯CPU计算，而且会卡顿。但它的危害不只在卡顿上——GC让CPU在原本不需要工作的时间段被迫加班，一加班就发热。而且GC不是匀速发生的，它是脉冲式的，可能前20秒风平浪静，然后某一帧突然触发一个大GC，CPU占用直接飙到顶，温度在几秒内明显上升。
我调过一个项目，UI上有实时刷新的聊天信息，每帧都在拼接显示文本，字符串拼接在半数情况下走的是string.Format，里面还有一堆DateTime运算。这个项目跑起来之后，帧率看着还行，但机器的发热曲线非常难看，每十几秒就有一个明显的温度跳变，伴随的是一阵小卡顿。后来把字符串拼接改成StringBuilder复用，DateTime做缓存，GC压力立刻降了一大截，温度曲线也随之平滑下来。
2.4 电池：被忽视的“底火”
锂电池在放电过程中本身就会产生热量，这是化学特性决定的。高负载场景下，电池要提供的瞬间电流更大，内阻损耗更高，发出的热量也就越多。这部分热量是GPU和CPU发热的“底火”，它的存在意味着：即使你什么都不做，只要电池在放电，就有基础热量。
而且手机的散热设计是层层叠加的——芯片的热量先传导到均热板，再传到中框，再传到后盖。电池的热量也在往里掺和。当CPU和GPU都在满载工作时，电池本身也在高倍率放电，三层热源叠加，机身的温度就会变得非常可观。
这里有个容易被忽略的细节：电池温度过高时，系统会主动限制充电电流甚至禁止充电（如果插着电玩的话），同时有可能触发系统级降频。这就形成了一个尴尬的局面——插着电玩游戏，反而可能比不插电更卡，因为电池为了保护自己不升温，会请求系统限制整体功耗。很多玩家抱怨“边充电边玩越玩越卡”，背后的机制就是这样的。
3. “越玩越烫”的三个反馈循环：为什么不是一开始就烫
前面提到了CPU降频的恶性循环，但整个发热链路中，类似的“自我强化”机制一共有三个，理解它们有助于你明白为什么问题会随着时间推移而恶化。
3.1 频率缩放循环：热→降频→更热
这个循环是所有移动设备都会经历的。芯片在工作时会产生热量，热量堆积导致温度升高。当温度超过某个阈值（通常在45-50度左右），系统会通过DVFS（动态电压频率调节）机制降低CPU/GPU的运行频率，以降低功耗、减少发热。
问题在于：频率降了，性能就降了；性能降了，原本能在一帧内完成的逻辑现在完不成；逻辑完不成，要么掉帧，要么CPU需要工作更长时间；工作更长时间，热量继续产生；热量继续累积，系统继续降频。这是一条螺旋下降的通道，用行话来说就是“撞到了功耗墙”。
一个有参考意义的数据来自Unity官方文档：当CPU频率从2.0GHz降到1.2GHz，性能下降约40%，但功耗可能只下降20%。这意味着降频的“性价比”并不高——你损失了更多性能，但省下的热量有限，温度并不会因为降频而快速回落。这就是为什么很多手机上，降频一旦开始，就停不下来。
3.2 资源加载循环：地图越走越大的内存压力
这个问题在开放世界和大地图游戏里特别明显。玩家从出生点出发，走过第一个区域，加载了第一批资源；进入第二个区域，加载了第二批资源。如果资源管理策略不够严谨——比如说Additive场景加载了不卸载、AssetBundle加载了不释放、对象池没做好——那么随着游戏进程推进，内存里的常驻资源会越来越多，驻留内存越大，GC触发越频繁，内存分配也不得不走更保守的路线。
我见过最典型的情况：一个以关卡推进为主线的游戏，每个关卡都会加载一批新的模型贴图资源。按理说，关卡切换时应该彻底释放上一关的资源，但由于AssetBundle的引用计数没搞对，还有静态类数组里存了GameObject引用，所有资源都被“钉死”在内存里。玩到第10关的时候，内存占用已经是第1关的5倍多。此时系统的内存压力巨大，后台App被疯狂回收，GPU和CPU为了应对额外的内存管理负载也在持续加班。
这个循环的可怕之处在于，它不是瞬间爆发的，而是随着游戏时间线性恶化。玩家感受到的就是“越玩越烫、越玩越卡”——每过一关，温度上限就上升一些，卡顿频率就提高一截。
3.3 玩家行为累积循环：画面复杂度在变高
还有个因素很容易被忽视：很多游戏开场几关的场景复杂度其实比较低，但越往后，特效越密集、敌人越多、场景装饰越丰富。如果性能预算没有按“满负载场景”来定——也就是说，上线标准是按“最复杂场景必须达标”而非“平均场景达标”——那么玩家玩到后期，游戏自身的负载就已经在上升了。
这个循环的本质是：“越玩越烫”不只是系统性的，也可能是内容性的。我见过一个塔防游戏项目，前5关跑起来温度表现很理想，策划和QA都很满意。但玩到第20关，满屏的敌人、满屏的子弹、满屏的爆炸特效叠加，负载直接翻了三四倍。这也算“越玩越烫”，但原因不是代码写差了，而是性能预算没有覆盖到后续关卡的内容负载。
4. 拆解Unity渲染管线：发热与帧时间的关系
4.1 帧时间是衡量热量最直接的标尺
在移动端Unity性能优化里，我们最常盯的一个指标是帧时间（Frame Time）。它不是帧率的倒数那么简单，而是“渲染一帧需要多少毫秒”的真实测量值。用Profiler抓一帧的数据，你能看到每一帧里CPU和GPU各花了多少时间。
帧时间与发热的关系非常直接：单位时间内渲染的帧数越多，GPU和CPU的负载就越高，产生的热量就越多。所以一个看起来反直觉的结论是：如果你的游戏能轻松跑到120FPS，但玩家的手机在60FPS时就已经温热了，那你可能需要主动限制帧率到60甚至更低的30，而不是放任它跑满。
这里的权衡非常微妙。60FPS的体验当然比30FPS流畅，但如果60FPS需要GPU满载工作，温度和功耗的代价非常大。很多竞技类手游干脆提供“高帧率模式”，让玩家自己选择“要流畅还是要凉快”——这个设计是有工程依据的，不是产品经理拍脑袋想出来的。
4.2 Batches与SetPass Calls：Draw Call优化为何影响温度
在Unity的渲染统计面板里，Batches（批次数）和SetPass Calls（切换渲染状态次数）是两个常年被挂在嘴边的指标。它们不仅影响帧率，也直接影响GPU的功耗。
每切换一次渲染状态（换Shader、换纹理、换材质），GPU都要做大量设置工作。如果一帧里有300个Draw Call，GPU就需要在不同渲染状态之间切换300次，每次切换都有额外的时钟周期开销。把这些开销加在一起，GPU的工作时间被人为拉长，发热自然上去了。
我优化过一个项目，场景里大量使用独立材质球，即使它们引用的Shader和纹理完全相同。后来把相同参数的材质合并为共享材质，Draw Call从2800降到了400出头。前后对比非常明显：不仅帧率从40FPS提升到稳定60FPS，机身的温度也有了明显的下降——因为GPU的工作量大幅缩减了。
这句话值得反复强调：减少Draw Call不只是在优化帧率，更是在优化能耗。在移动端，每个不必要的GPU空转周期，最终都会变成你掌心里的一度热。
4.3 URP还是内置渲染管线：关于发热的冷知识
这个话题我现在提出来，估计会有人觉得落后于时代，但在存量项目里，内置渲染管线（Built-in Render Pipeline）依然大量存在。社区里常有人问：“换成URP是不是就能解决发热？”
URP在CPU端的优势是显著的：SRP Batcher可以把同类材质的SetPass Call降得非常低，对移动端CPU负载的优化肉眼可见。但GPU端的发热问题，URP并不会自动帮你解决——如果场景里有大量像素光、复杂后处理、未合批的Mesh，URP该烫还是烫。它优化的是提交效率，是CPU侧的开销，而不是GPU侧绝对的计算量。
所以如果有人告诉你“切URP就不烫了”，别信。切管线能优化一部分性能，但根子上的渲染负担、资源负担、内存负担，不会有任何管线替你背锅。
5. 定位发热源头：先用工具找出“热量大头”再动手
既然发热来源是多元的，优化就不能靠猜。工欲善其事，必先利其器。这里介绍一套我平时排查发热问题的标准流程，第2篇里我会展开讲工具的具体用法，这篇先建立整体思路。
5.1 真机Profiler：模拟器数据参考价值有限
第一步永远是真机。模拟器用的是PC的CPU和显卡，性能和功耗曲线跟手机完全不在一个维度上。你在模拟器上看Profiler可能一切正常，真机上可能已经烫到掉帧。所以无论多麻烦，发热相关的问题必须真机测。
Unity Profiler连接真机有两种常见方式：USB直接连接和Wi-Fi无线连接。USB连接更稳，数据延迟低，但会有一点电流通过数据线给手机充电，反而会额外增加温度。无线连接更接近真实使用场景，但偶尔会有丢帧数据的情况，属于可接受的误差范围。个人经验：先无线连接跑一轮完整测试，记录整体的温度曲线和帧时间曲线；发现问题帧段后，再用USB连接做针对性抓帧。这样兼顾了真实性和可分析性。
5.2 关键面板：CPU Usage、GPU Time、Memory与Battery
在Profiler的CPU Usage面板里，你能看到每一帧的时间都花在了什么地方。重点关注这几项：
- Scripts：C#代码的执行时间。如果这一项长期超过5-8ms，脚本层多半有问题——最常见的原因是GC触发、频繁的GetComponent、Update逻辑过重。
- Physics：物理模拟耗时。场景里大量的Rigidbody、Collider、关节约束，都会让物理引擎加班。
- Rendering：渲染提交耗时。这个和场景复杂度、合批效率直接相关。
- UI：UGUI的布局和重建时间。UI的动态元素越多，这一项的数值越难看。
GPU Time这个指标在部分移动设备上可以通过Profiler直接读取。如果你的设备不支持读取，可以用一个变通办法：开启了垂直同步之后，如果CPU耗时明显少于16.6ms但帧率依然上不去，多半瓶颈在GPU。反之，如果CPU耗时已经接近甚至超过16.6ms，那瓶颈在CPU侧。
Memory面板看的是内存分配和GC情况。重点关注Managed Heap的大小波动——如果它呈现“锯齿状”持续上涨再骤降，说明GC在频繁工作，每一个锯齿都意味着一次CPU加班，每一次加班都在为发热做贡献。
电池状态用系统自带的监测工具或者第三方功耗测量App即可，主要看两个指标：温升曲线和功耗占比。如果能看到CPU的功耗占比远超GPU，那问题在逻辑侧；反过来，则需要从渲染侧入手。
5.3 排除法定位：从“必然耗电”开始砍
定位发热源头的核心思路其实很简单：把负载一项项减少，看温度响应。这个方法虽然土，但非常有效。
- 先把游戏帧率锁到30FPS，如果温度明显下降，说明负载与帧率强相关，优先优化每帧的工作量。
- 再把分辨率降一档，如果温度还是高，说明瓶颈不全在GPU的像素处理上，可能是CPU逻辑或者资源驻留。
- 把后处理特效全部关掉，如果温度骤降，说明后处理是GPU的大头。
- 把场景里所有实时光源换成烘焙光照，如果温度明显改善，说明实时光照的计算量非常吃GPU。
每一轮测试之间，记得等手机温度恢复到室温再测下一组，否则数据会互相污染。这个细节很重要——连续测三组数据，手机的起始温度不同，得到的结果完全没有可比性。我在测试的时候一般在每组之间至少等十分钟，让手机彻底凉透。
6. 第1篇收尾：先别急着优化，把发热的账目理清
这篇的内容到这里差不多该做个阶段小结了——不是套路化的总结，而是给你一个清晰的行动起点。
回顾四个热源：CPU的逻辑负载、GPU的渲染负载、内存GC的脉冲热量、电池放电的底火。再看三个循环：频率缩放导致的降频螺旋、资源累积导致的内存压力、关卡后期内容负载的上升。这四个热源和三个循环，构成了“越玩越烫”的完整图景。
在动手做任何优化之前，我建议你先花几天时间做一件事：给项目建立一份“发热台账”。拿一台中端真机，按正常的游戏流程跑上20-30分钟，每5分钟记录一次：帧率、CPU耗时、GPU耗时（如果工具支持）、内存占用、机身温度。连续记录三四轮数据，你就能得到一个比较完整的“温度-性能”基线。后续每做一项优化，都回到这个基线上对比，优化有没有效果、效果多大、会不会引入新问题，一目了然。
这个台账的做法是我在实际项目中养成的习惯。没有基线的优化，就像闭着眼睛调音量——你根本不知道自己拧到了几格，也不知道拧的方向对不对。
下一篇，我会重点拆解CPU侧的发热大户：Update、GC、物理引擎和资源加载，每一种都会给出具体的Profiler分析方法和优化策略。CPU侧的问题解决了，至少一半以上的“越玩越烫”事故能提前排除掉。
