企业官网建设流程全解析

1. 发热先别慌：先搞懂"烫"到底是从哪来的

先问个问题：当你拿起手机感觉到机身发烫的时候，你第一个动作是什么？我猜肯定是打开某个监控软件看一眼 CPU 占用率或者电池温度。但说实话，做 Unity 优化这么些年，我越来越觉得"温度"只是表象，真正要盯的是帧时间和功耗曲线。这两者之间有一条非常直接、也非常容易被忽略的传导链：掉帧 → 高占用 → 高功耗 → 发烫。所以第 1 篇系列文章，咱们先把这条链拆开揉碎讲清楚。

先给出一个反直觉的结论：一个稳定跑在 30 帧的游戏，和一个帧率在 20 到 60 之间反复横跳的游戏，后者更容易让手机发烫。原因很简单，帧率不稳意味着 GPU 和 CPU 的负载在短时间内剧烈波动，芯片为了应对"瞬时高负载"会主动拉高电压和频率，而高频率带来的热量远比匀速跑满 60 帧要多得多。这也是为什么很多团队做性能优化时，第一个 KPI 不是"把平均帧率拉高"，而是"把帧率方差压下来"。

回到 Unity 项目的具体场景。你打开 Profiler，看到的 CPU 耗时可能只有 20 毫秒，对应帧率 50 左右，理论上不算差。但此时 GPU 端的压力你根本没看到，因为 Unity 的 Profiler 默认只显示 CPU 侧的耗时（WaitForTargetFPS 之类的占了很大一块），GPU 的 RenderDoc / Xcode GPU Frame Capture / Snapdragon Profiler 这些工具很多人压根没用过。于是很多人在 CPU 优化上疯狂抠细节，把 Update 里的逻辑都快删光了，手机还是烫得像暖手宝——因为真正的瓶颈在 GPU 渲染链路上。

所以这篇开篇，咱们不聊具体某个 API 的优化技巧，而是先把"发热问题的整体认知框架"搭起来。包括：发热的本质是什么、常见误区有哪些、如何用 Android 自带的工具定位到"烫"的源头、以及哪些看起来合理的写法其实一直在偷走你的性能和温度余额。等这套框架建立起来，后续第 2 篇开始就会逐个击破具体的技术点。

另外补充一句：发热不是高端机才有的问题，反而是中低端机（比如骁龙 6 系、天玑 7 系）更容易暴露。因为旗舰芯片（8 Gen 3、天玑 9300）的能效比做得很好，日常负载压不住它们；而中端芯片先天能效差，稍微有点负载就热。所以优化发热问题，测试基准机选 1500 元到 2000 元档位的机子最有代表性，旗舰机上跑不出差距。

注意：本系列文章全部基于 Unity 2021 LTS 以上版本（IL2CPP + Android 平台为主），个别内容涉及 WebGL 和 iOS 会在对应篇幅单独说明。如果你还在用 Mono，部分结论可能不完全适用，建议先升级再谈优化。

2. 为什么"看起来没问题"的代码，会在热量账单上给你一记重拳

2.1 你看到的帧率，不是真正的"用户感知帧率"

在性能优化领域有个概念叫 Frame Pacing（帧节奏）。Unity 的默认设置是"目标帧率内尽可能快地渲染"，也就是说如果目标帧率是 30，但某一帧只用了 20 毫秒，那下一帧会在 10 毫秒后直接开始，导致实际帧间隔不均匀，视觉上表现为卡顿。但这不是最严重的——最麻烦的是，当你开启垂直同步或者 Application.targetFrameRate 时，设备会进入一种"渲染完成→等待 vsync→渲染完成"的循环，此时 CPU/GPU 并没有真正歇着，而是在用空转的方式等待下一次垂直同步信号。

这个"空转"在 Profiler 里会显示成WaitForTargetFPS或者Gfx.WaitForPresent，很多新手看到这两行蓝色或黄色的长条以为无关紧要，直接跳过。你试试看：把项目跑在低端安卓机上，打开 Profiler，点开 CPU Usage Profiler，你会发现 Gfx.WaitForPresent 往往占了 10 到 20 毫秒——这其实不是坏事，说明你的 CPU 提前干完了活，在等 GPU 和屏幕刷新。但如果这个等待时间太长，意味着每一帧的负载不均匀，设备为了保持刷新节奏会频繁调整频率，热量自然就上来了。

真正的优化目标是：让每一帧的耗时尽可能接近目标帧预算（比如 33.3ms @ 30fps），而不是远低于预算再空等。很多团队把"帧率跑到 60"当作目标，却忘了用户端屏幕大多是 90Hz 或者 120Hz 的高刷屏——你按 60 帧跑，在高刷屏上反而会因为 frame pacing 怪异而比 30 帧更难受。

2.2 内存分配：一台手机发烫的隐形推手

C# 的 GC（垃圾回收）在移动端是个很微妙的话题。Mono 时代 GC 是罪魁祸首；IL2CPP 之后 GC 改成了 Boehm，虽然停顿次数少了，但内存碎片和分配开销仍然存在。很多团队做优化只盯着"是否频繁 Instantiate/Destroy"，却忽略了更隐蔽的分配来源：字符串拼接、LINQ、闭包、装箱。每帧几条字符串拼接，看着不痛不痒，但在低端机上，一帧之内触发一次小 GC，停顿 2 到 5 毫秒，帧率瞬间就掉下来；而 GC 又是 CPU 密集操作，掉帧的同时功耗飙升，热量就这么叠起来了。

我记得之前参与过一个模拟经营类项目，UI 上有十几个实时更新数值的 Text。优化前用 Profiler 一查，每帧 GC Alloc 大概 8KB 左右，其中八成来自 string.Format 拼接。我们把这些全部改成 StringBuilder 或者预拼字符串之后，GC Alloc 降到大概 1KB，帧率提升了 30% 以上，手机温度从"烫手"变成"温热"。这个案例我会在本系列后续某一篇里专门讲字符串优化的全套手法，这里先提醒一句：Profile 里看 GC Alloc 的数值曲线，如果持续走高，发热只是时间问题。

2.3 你以为是"骨骼动画"的问题，其实根子在 CPU 上的 Skinning

说到角色动画，很多人第一反应是"骨骼数量太多了""面数太高了"，然后去减面、减骨骼。但如果你用的是 Animator + 普通 SkinnedMeshRenderer，真正吃 CPU 的是Skinning（蒙皮计算）——也就是每一帧把骨骼变换矩阵传到 GPU 的顶点着色器（或 CPU 端计算），再做顶点变换。这个计算量级跟骨骼数量和受影响顶点数成正比，而不是跟骨骼的总数量直接相关。

在 WebGL 和部分低端安卓机上，SkinnedMeshRenderer 的蒙皮计算是放在 CPU 端完成的（因为 GPU 不支持某些特性，或者为了兼容性 Unity 会回退到 CPU Skinning）。这种情况下，一个 1 万顶点、30 骨骼的角色就能让 CPU 单核占用率跑到 50% 以上，发热那是必然的。后续系列会专门讲到：用 GPU Skinning 插件、减少受骨骼影响顶点数、为远处的单位切换为 Simple Animation（烘焙顶点动画），这几个方案在实践中的真实收益和坑点。

这里给个建议：判断你的项目是否为 CPU Skinning，在 Editor 的 Game 视图里打开 Stats 面板，看 Batches 旁边的Skinned Meshes一栏，它会显示当前所有 SkinnedMeshRenderer 的总三角形数；如果想看每个角色的蒙皮开销，需要 Switch Target Android，并打开Profile里的Rendering → SkinnedMesh模块。更直接的判断是：在 Profiler 的 CPU 模块里搜 SkinnedMesh 相关条目，如果它每帧超过 3 毫秒，那就是 CPU Skinning 实锤。

2.4 "ToLua / hotfix" 到底让性能付出了什么代价

热搜词里有dllnotfoundexception: unable to load dll 'slua'和hotfix这两个，说明不少团队在用 Lua 做热更新。Lua 在 Unity 里的性能开销主要在两个地方：一是Lua 与 C# 之间的跨语言调用（P/Invoke 或反射），二是Lua 本身的垃圾回收。虽然 Lua 很轻量，但频繁的跨语言调用（每帧几十次甚至上百次）会让 IL2CPP 的 AOT 优化形同虚设，因为参数要装箱、返回值要拆箱、类型要检查，这些都是纯 CPU 指令，而且没法 JIT 优化。

如果你项目里有一段每帧调用的 Lua 逻辑，里面再套了几个 table 操作和字符串函数，你大概率会在 Profiler 的 Native 插件那一栏看到很高的耗时。实测下来，同一个逻辑用纯 C# 写可能只要 0.2 毫秒，用 Lua 调用可能要 0.8 到 1.5 毫秒，等于是 4 到 7 倍的开销。这在普通战斗场景里可能还好，但在开放大世界、频繁交互、多单位刷新的场景里，累积起来能让 CPU 占用直接飙升 20% 以上。

我的建议是：能用 C# 写成全静态调用的，就别放到 Lua 里做热更。热更应该只覆盖配置表、活动逻辑、少量 UI 逻辑，而不是全量业务逻辑。另外注意：Lua 的 GC 也不要放任不管，所有 Update 里创建的 table 都要记得复用或置空，否则会变成 Lua 侧的 GC 压力，进而是 CPU 峰值，进而是发热。后续如果有机会我会写一篇"Lua 热更项目的性能红线"，里面会有更细的清单。

3. 在信任何优化之前，先学这 3 个 Android 端工具：把"烫"追溯到具体的函数和渲染阶段

3.1 Unity Profiler：先看 CPU 再看 GPU，别搞反了

打开 Unity Profiler，先用CPU Usage模块拿到一份全帧的耗时分布。这个模块的默认视图是可交互的层级树，能看到每一帧里各个系统的耗时占比。当你发现某种调用占了 30% 以上，就点进去一层层下钻：比如PlayerLoop → Update → MonoBehaviourUpdate → YourScript.Update。大多数情况下，你会在这里抓到主要瓶颈。但注意：CPU Profiler 抓不到 GPU 的真实耗时，只能在 CPU 侧的 Gfx.WaitForPresent 里看到一个影子，所以如果你在这一栏看到"惊人"的空闲时间，排除掉帧率设置和 vsync 的影响之外，大概率是 GPU 的压力太大了。

实操建议：在 Android 真机上，关闭 VSync（Edit → Project Settings → Quality → Anti Aliasing 下方没有这个选项，需要在 Player Settings 里勾选Use Default 31Hz或者通过Screen.vSyncCount = 0强制关闭），把帧率限制到 30（Application.targetFrameRate = 30）。这样能避免 Profiler 里 WaitForTargetFPS 干扰你的判断，让 CPU 和 GPU 的负载真实暴露出来。

3.2 Android GPU Inspector（AGI）：GPU 端的时间线才是"烫"的真相

AGI 是 Google 官方提供的 GPU 性能分析工具，用它替换 Snapdragon Profiler 来抓 GPU 的时间线。安装好之后连接设备，选择你的 Unity 应用，能抓到：Draw Call 数量、顶点处理时间、片段着色器（片元着色器）耗时、带宽占用。移动 GPU 是 TBDR（Tile-Based Deferred Rendering）架构，渲染过程分为几何阶段和像素阶段，像素阶段的 Overdraw（同屏多次渲染同一像素）对发热影响极大。

实操中你会经常看到这种情况：CPU Profiler 里没啥问题，GPU 的 Fragment Shader 却花了 60% 以上的时间。这时候把项目里的 translucent 物体数量、贴图alpha测试、Lightmap 和实时光的关系、以及后处理效果一个个排查，通常能解决大量的发热问题。

注意：AGI 需要你的手机开启 USB 调试，且要求 GPU 驱动支持（高通、Mali、PowerVR 都支持）。如果抓不到，建议用Snapdragon Profiler（高通芯片机型）或Mali Offline Compiler配合OpenGL ES Analyzer做替代，方法类似。

3.3 硬件层的测温与功耗数据：别再用"摸着烫"下结论

手机厂商的温控策略差异很大——某些品牌会在温度到 42°C 就开始降频锁帧，有些能忍到 45°C 以上。所以单纯看"手感烫不烫"并不科学。你需要在性能优化时记录CPU 频率、CPU 负载、电池温度、GPU 频率（部分机型支持）。可以使用PerfMon（Android 上的一个悬浮窗工具）实时显示这些数据，或者用Battery Historian分析一段时间的电池温度曲线。

我的习惯是：每个优化的改动都做两组测试——一组跑 20 分钟连续游戏，记录温度变化曲线和帧率曲线；另一组跑 2 分钟最高画质场景（压力测试）。如果第一组的温度曲线斜率明显放缓、第二组的掉帧次数显著减少，就说明优化有效。切忌只看 1 分钟内有没有掉帧就把结论写进周报里。

4. 把 CPU、GPU、内存"三座大山"的数据串起来：一套通用的发热排查脚本

4.1 采集哪些数据？怎么采集？

做项目性能优化，最先要解决的是数据采集的问题。建议别在真机上凭感觉判断——人脑对温度和帧率的感知都不太靠谱，必须靠数据说话。下面这套采集方案是我在多个项目里沉淀下来的，简单、通用、可复现。

环境准备：

• 一台 Android 测试机（建议选中端机型，如 Redmi Note 12 Turbo 或类似档位）
• Unity 2021 LTS 或更高版本
• 模拟器不要用——模拟器无法反映真机 GPU 和温控的真实行为

脚本步骤：

1. 在 Unity 里写一个简单的 Debug 面板脚本，实时输出：
   • 当前 FPS（按最近 60 帧计算平均帧时间）
   • 每帧的 CPU 耗时（UnityEngine.Profiling.Profiler的GetMonoUsedSizeLong和GetTotalAllocatedMemoryLong可以作为内存参考）
   • GC Alloc 值（每帧分配的字节数，Profiler 里叫GC Alloc In Frame）
2. 用 AGI（Android GPU Inspector）给 GPU 拍照抓帧，拿到渲染耗时和 Draw Call 数据。
3. 用top -H -p <pid>（需要设备有 adb 权限）或者cat /sys/class/thermal/thermal_zone*/temp读温度节点，实时记录 CPU 频率。

把这些数据汇总到一个 Excel 表格里，按场景（主城、战斗、UI 结算）和时间段做标记，你就能看到发热问题的全貌：是某个场景一进去就发热，还是随着游玩时间逐步升温；是 CPU 单核打满，还是 GPU 高频运行等等。

4.2 实战案例：一个技术美术优化的完整链路复盘

在某个 3D 卡牌项目的后期优化阶段，我们接到反馈"游戏玩 10 分钟就开始发热掉帧"。第一次用 Profiler 抓到的情况是：CPU 占用大概 35%，GPU 占用 80% 左右，Draw Call 450+，SetPassCall 超过 300。表面看是 Draw Call 太高，于是我们开始合批、合图集、降低阴影质量——一顿操作后 Draw Call 降到 180，但发热问题依旧。

再用 AGI 看了一下，发现 Fragment Shader 的耗时占了 GPU 总时间的 63%，里面有一大半是全屏后处理带来的。项目为了风格化效果，加了一个 Bloom+Color Grading+Vignette 的 Post-process 叠加，而且用的是两个 Camera（主相机 + 后处理相机）叠加渲染。这个后处理在 1850×800 分辨率下的开销非常夸张，尤其 Bloom 的 HDR 采样会把带宽吃满。我们把后处理改成单独一个 Camera 并限制 Bloom 分辨率（降到 1/4），再加了一个开启条件（只在战斗场景开启），发热问题立刻缓解，温度曲线明显下降。

这个案例给我们的教训是：Draw Call 多不等于发热，因为 Draw Call 的主要开销在 CPU 端和 GPU 的顶点索引处理阶段；而像素填充率、带宽、Overdraw 才是 GPU 发热的三大元凶。排查发热问题，一定要用 GPU Profiler 拿到 Fragment Shader 的耗时和带宽占用，而不是只看 Batches 数。

4.3 WebGL 平台是例外：发热问题的形态完全不同

热搜词里有unity webgl帧率稳定控制和unity webgl，我顺势提一嘴 WebGL 平台的发热问题。WebGL 跑在浏览器里，受限于浏览器本身的调度机制和 16ms 帧预算（60Hz 显示器），它的发热是"稳定在高位"而不是"波动"——浏览器为了保证页面响应，通常会强制限制 WebGL 的帧率上限，所以你在 WebGL 上做特效时经常会看到 CPU / GPU 占用不高，但风扇狂转（PC）或者手机温热的情况。

对于 WebGL 项目，发热问题更多表现为 CPU 侧的 JS 层调用开销（Unity 的 WebGL 是把 C# 编成 WebAssembly，浏览器端的 JS 层要负责消息传递和生命周期），以及内存泄漏。内存泄漏会让浏览器逐步变大、变卡、最终导致网页标签页崩溃，但和移动端的发热路径不太一样。后续系列如果有需要，我会单独写一篇"WebGL 项目的发热与性能排查思路"。

5. 一个实用但常被忽略的排查工具：Unity Overdraw 视图，找到"看不见的"热点

5.1 打开 Overdraw 视图的正确姿势

很多人不知道 Unity 的 Scene 视图里有一个Overdraw渲染模式（在 Scene 视图左上角的下拉菜单中，选择 Shaded 旁边的下拉箭头，选 Overdraw）。切到 Overdraw 之后，屏幕会变成黑白，越亮越红的地方代表该区域被反复绘制多次。这在 UI 优化和粒子优化上极其有用。

典型问题：UI 面板叠了 3 层相同大小的半透明图，每一帧都要混合 3 次；粒子系统用了大量的半透明材质，每个粒子都要和背景混合；树和草用 Alpha 测试（Cutout），看似省了混合，但片元着色器的裁剪在移动 GPU 上非常昂贵（需要额外的 discard 指令，而且会打断 Early-Z 优化）。这些都直接推高 Fragment Shader 耗时，进而发热。

在 Overdraw 视图下，你会看到一个"异常亮点"区域，用鼠标悬浮定位到具体物体，通常就是发热元凶。处理手段包括：给 UI 合并层级、用纯色基图代替半透明叠加、将 Cutout 改为使用两遍渲染或 Grad 渐变透明、粒子加Far Fade距离裁剪等。

5.2 最常见的 Overdraw 陷阱：UI 里的"隐形"半透明块

我见过不少项目在做一个"点击空白处关闭弹窗"的功能时，给整个屏幕加了一个全屏半透明黑色遮罩（只有 1% 透明度的黑色，几乎看不出效果），然而这东西每帧都要做全屏混合。在 1080p 的屏幕上，这一个遮罩就能让 GPU Fragment 阶段多 200 万次像素操作，温度上去非常快。

如果你想验证是不是遮罩导致的，把 Shadow Caster 关掉、把材质改为完全不透明、或者直接撤销那个 Image 的 CanvasRenderer 的 Color 里的透明通道，再对比帧率和温度。这类问题通常不会在 Editor 里看出任何"卡顿"，因为 Editor 上 GPU 压力可以被本机桌面级显卡轻松压掉，只有真机才会暴露。

6. 最后一层的防线：GPU 端的 Draw Call 并不是越少越好，片面追求会适得其反

6.1 Draw Call 和 SetPass Call 的区别

很多团队把 Draw Call 数量当成性能优化的唯一信仰。实际上，对于移动 GPU 来说，SetPass Call（切换渲染状态）比 Draw Call 更昂贵，但两者经常被混为一谈。Draw Call 指的是提交一个渲染图元（Mesh 或者粒子）的命令，而 SetPass Call 是切换材质/Shader 状态（贴图、混合模式、深度测试开关等）。

Unity 的 Stats 面板里有两个数字：Batches和SetPass calls。Bathes 数等于 Draw Call 数（大约），SetPass calls 是状态切换次数。如果你的工程有 1000 个 Batches，但只有 10 个 SetPass calls，那性能往往还好——因为所有物体都共用同一份材质和贴图；反过来，如果 Batches 只有 100，但 SetPass calls 有 80，反而更容易发热——因为每画几笔就要切换一次渲染管线状态，GPU 的调度器要频繁做资源重绑定，带宽和延迟都上去了。

所以合批的核心逻辑是：把相同材质、相同贴图、相同混合模式的物体尽量合并到一个批次里，而不是单纯地"把 Batches 数字降下去"。为了降 Batches 乱用 Static Batching 反而会造成内存翻倍、数据包变大，最终让 CPU 在序列化和提交数据上耗费更多。这些权衡我在做大型开放世界项目时经常遇到，建议第 3 篇里专门展开讲。

6.2 一个用"Draw Call 优化"反而发热加剧的经典反例

有一次我们把一座城市的所有建筑用Static Batching合并成一个巨大的 Mesh，Batches 从 400 降到了 30，但发热问题反而更严重了。查了 AGI 才发现：合并后的 Mesh 需要一次性加载进 GPU 显存，带宽瞬时被拉满，而且大部分建筑因为本身用了多种不同材质，根本没被静态合批成功（Unity 的 Static Batching 要求使用相同的材质实例或一致的顶点属性），结果就是数据没少传，GPU 还要花更多时间处理大 Mesh 的裁剪和顶点变换——简直是双重浪费。

那之后我给团队立了一条规矩：优化 Draw Call 前，先确认受优化对象的材质是否统一、贴图是否已经合入同一个图集，以及单个 Mesh 三角形数是否超过 10 万。前期图集没合好，后面一切合批优化都是负优化；反过来，如果图集合理、材质统一，Draw Call 即使到 300 也不会对发热造成致命影响。

7. 退无可退的最后一步：当优化上不去时，用质量分级和内容剔除来兜底

7.1 为什么"一步到位的全画质"只会适得其反

很多团队喜欢把游戏画质做成"全高/全低"两档，或者干脆不给玩家选择。这在发热管理上是失败的：不是所有玩家都在最新旗舰机上玩，但刚上线的新版本会吸引大量中低端机用户涌入。高端机画质全开、发热不明显；中端机画质全开、发热立刻爆表，然后被玩家在商店打低分——这算是比较常见的新手错误。

我的做法是做三档分辨率 + 三档后处理 + 三档阴影，并通过一个Quality Settings面板交给玩家手动选择，同时在启动时自动检测设备性能（几核、GPU 型号、内存）给出一个推荐档位。也就是说让"发热"这件事在一定程度上可以"被用户控制"。这个方法对留存率有显著帮助——至少玩家不会因为"手机太烫"直接卸载，而是会调低一档继续玩。

实操提醒：Unity 的 Quality Settings 里有很多关于 Shadow、Texture 质量的选项，但"关闭后处理"和"降低粒子发射量"这些选项需要你自己在表里配置。别指望一个 Quality Level 能自动帮你处理所有自定义 Shader 的 LOD（LoD 距离）和粒子系统的 Max Particles。

7.2 内容剔除：不渲染 = 不发热 = 最高效的优化

发热优化的最高境界是"什么都不渲染"。这里的"什么"指的是玩家在屏幕上看不到的内容。举几个维度：

• 相机裁剪：检查 Camera 的 Clipping Planes，Far 设成 1000 对移动端来说太高了，500 到 800 就够（具体看游戏空间尺度）。此外，用Occlusion Culling把被遮挡的物体剔除掉。注意 Occlusion Culling 的计算本身也有 CPU 开销，烘焙一个月一次，体积太大的场景可以分区域烘焙。
• LOD 距离：把物体的 LOD0（最高精度模型）切换距离控制在小范围内。具体的距离要根据角色在屏幕上的投影高度来算，参考值是：当角色在屏幕上小于 80 像素时，切换到 LOD1；小于 40 像素时，切换到 LOD2。这个阈值需要真机测试调整，因为屏幕密度不同，对"清晰度"的感知完全不同。
• 粒子系统的 Max Particles：把一部分低优先级粒子（比如溅射、飘尘）的发射数量压到原来的 1/4，视觉差异在人眼感知阈值以下，但 GPU 的填充压力显著下降。
• 手电筒和实时阴影范围：实时阴影（特别是 directional light 的 Cascade Shadow）是发热大户。把 Shadow Distance 从 150 缩到 80，或者让场景里真正产生实时阴影的物体数量减半，降温效果立竿见影。

这些内容剔除方案本质上是替换"渲染优先级"——让 GPU 和 CPU 把算力集中到玩家当前注视的区域，而不是像无头苍蝇一样把整个场景渲染一遍。发热、掉帧、电池电量，三者会在剔除优化之后同时改善。

7.3 动态分辨率适配：让"发热"自动触发画质妥协

现在越来越多的手游（包括 Unity 开发的游戏）用动态分辨率来应对发热。做法是：在渲染流程开始前读取当前帧时间或设备温度，如果超过阈值，就把临时 RenderTexture 的分辨率降低 10% 到 20%，等温度回落后再恢复。Unity 里可以通过 Scriptable Render Pipeline（URP/HDRP）的RenderPass实现，或者简单粗暴地在 LateUpdate 里修改Screen.SetResolution。

我自己的经验是：这个方案至少能保住 15% 的帧率缓冲和 10°C 左右的温度下降，但需要谨慎调节降级步长，否则画面会忽糊忽清晰，玩家会吐槽"画面怎么一下变差了"。推荐每次降 0.8 倍，保持 5 秒再判断，回升时同样缓慢——给玩家的感觉是"画质悄悄下降了一点，不仔细看察觉不到"。

8. 本系列的总结（写给刚入门的同学的一些话）

这一篇没有讲具体的 API 优化细节，而是把 Unity 游戏发热问题的整体轮廓先描了一遍。核心要点大概这六条：

1. 发热的本质是功耗过高，功耗过高的来源是 CPU / GPU / 内存带宽三者之一或叠加，掉帧和发热往往是同一个问题的一体两面。
2. Profile 工具要用到位：CPU 看 Unity Profiler，GPU 看 AGI / Snapdragon Profiler，内存看 Memory Profiler。光靠 Editor 里的 Game 视图可没法抓到真机发热的原因。
3. Draw Call 不是唯一敌人，SetPass Call、Overdraw、带宽、CPU 端蒙皮计算、Lua 调用开销、GC 分配，这些才是真正让手机变暖的大户。
4. 内容剔除是最划算的优化：不渲染的画面、不发射的粒子、不计算的动画，是天然的零成本收益。
5. 动态分辨率和质量分级是发热问题的最后兜底手段，务必要给玩家留一个"画质降级"的自救开关。
6. 用数据说话：定一个测试基准机（比如中端安卓），把温度和帧率曲线记录下来，每次改动前后对比，你再也不会靠"手感"去判断优化是否有效。

后面第 2 篇，我准备聚焦到GPU 渲染链路，比如 Fragment Shader 的 Overdraw 到底怎么降、Unity UI 的半透明陷阱、以及为什么要减少 Alpha 测试。第 3 篇聊动画和物理系统，包括 CPU Skinning、物理引擎的碰撞矩阵配置、以及 Job System 和 DOTS 在性能改造里的真实定位。如果你想先看到某个方向的内容，也欢迎在评论区留言，我按热度安排后续篇幅。

最后分享一个个人体会：性能优化是一项"渐进式"的工作，忌讳在一开始就大改架构。先把 Profiler 数据分析完，找到最大的几个热点，小步快跑地修，每一次修改都用数据验证。这样做的好处是不容易把之前跑得正常的功能改坏，也能在团队内部建立"优化必须有数据支撑"的共识——毕竟，发热问题的终极解是持续度量、持续改进，而不是某次大重构一锤定音。