GPU带宽成移动端发热元凶？纹理压缩与后处理优化全解析

发烫优化做了好几轮之后，你会慢慢发现一个规律：真正让手机变成暖手宝的，往往不是那些看起来很复杂的shader，也不是场景里的三角形数量，而是那些藏在管线深处、每天都在疯狂搬运数据的环节。纹理采样算是其中一个，后处理更是另一个。这两个东西在优化工单里出现的频率极高，所以我直接把它们拎出来单独写一篇。

先说个背景：这是“发烫优化系列”的第4篇。前几篇聊了CPU侧的负载拆分和GPU侧的overdraw控制，这一篇聚焦在GPU里两个最容易吃带宽、最容易让芯片温度失控的环节——纹理与后处理。如果你正在做移动端渲染优化、Unity/UE项目性能调优，或者纯粹被真机发热搞得焦头烂额，这篇应该能给你一些可以直接拿去用的思路。

1. 为什么纹理和后处理是“搬运量”最大的惯犯

1.1 GPU发热的本质：功耗来自哪里

很多人以为GPU发热是因为计算量大，其实不太准确。移动端GPU大部分功耗消耗在“数据搬运”上，而不是“数据计算”上。芯片内部有一堆总线、缓存、内存控制器，数据在它们之间流动，每一次流动都在给芯片加温。总线翻转要耗电，缓存命中率低了要访问外部DRAM要耗电，带宽吃满了整个内存子系统都在高压运转，发热自然就上来了。

纹理采样和后处理正好是数据搬运的两个极端典型。纹理采样要把纹理数据从显存（或者内存）搬到GPU的texture cache，再经过采样器送到shader里做计算；后处理则是把整张渲染结果从渲染目标（RenderTarget）里读出来，经过一遍又一遍的全屏Pass处理，再写回新的渲染目标。每一帧都在搬，一秒钟60次，全年无休。

所以优化纹理和后处理，本质上就是在给芯片“减负”，把那些不必要的搬运路径砍掉。芯片不搬数据了，功耗自然降下来，温度也会跟着回落。

1.2 带宽计算公式：先算算你在搬多少数据

要量化搬运量，我一般会做一个简单估算。这里有一个很实用的带宽计算公式：

单帧带宽 = 渲染目标读写流量 + 纹理采样流量 + 顶点数据流量 + 其他杂项

拿后处理举例，一个1080p的分辨率，RGBA8格式，一张RT的大小大概是：

1920 × 1080 × 4 bytes ≈ 8.3 MB

读写一次就是16.6MB，如果你用了bloom（高光提取+水平模糊+垂直模糊+合成，中间还有降采样），随便就是四五次全屏RT读写，那就是80MB左右的流量。这还没算纹理采样流量。

如果再做一次MSAA，4x MSAA的resolve过程还要把4倍于屏幕像素的样本数据读出来再合并，带宽消耗直接翻好几倍。这些数据全部堆在内存总线上的时候，芯片温度想压都压不住。

1.3 纹理搬运路径：从DRAM到Shader的长途运输

纹理数据在GPU里的搬运路径大致是这样的：显存/内存 — 纹理缓存（texture cache）— 采样器 — ALU。每一步都有成本，但最贵的是第一跳——从外部DRAM拿数据。纹理缓存的大小有限，如果纹理太大、mipmap缺失、采样方式低效，缓存命中率就会下降，GPU就不得不频繁访问外部内存，这时候最费电。

后处理也是一样的逻辑。它的问题在于每一个Pass都涉及一次“整张屏幕的读写循环”，这是一个不折不扣的带宽黑洞。而且后处理Pass还有个特点，越往后叠加消耗越非线性——多个后处理效果如果串在一起做，每一层都要把前一层的完整图像搬一遍，这个成本是线性叠加的。

2. 纹理篇：搬得少才能凉得快

2.1 纹理压缩格式：首选项从ASTC开始

纹理优化的第一道关卡是压缩格式。很多人习惯了在PC上直接存RGBA/BGRA纹理，到了移动端还是这么干，这是个大坑。RGBA8每个像素占用32bit，而ASTC 4x4可以做到每个像素占用8bit，ASTC 8x8只要4bit。同样一张1024×1024的图，RGBA需要4MB，ASTC 8x8只需要1MB，搬运量直接节约了75%。

下面是几个常用格式的对比：

注意：ASTC是OpenGL ES 3.0和Vulkan时代的主流选择，苹果的A8+芯片和绝大多数安卓中高端芯片都支持。如果你的项目还需要兼容比较老的设备，ETC2是底线。别在移动端用RGBA8做UI大图，尤其是全屏背景图，一次采样就要搬好几MB数据。

关于纹理压缩的块尺寸选择，我的经验是：UI和需要锐利边缘的贴图用ASTC 4x4或6x6，普通漫反射纹理用6x6，Normal Map这种对精度敏感的用4x4（因为有channal packing需求），大块地形和天空球可以退到8x8。项目里跑一轮真机测试，同一张图分别压缩成不同块比大小，画面对比一下很快就能定标准。

2.2 mipmap不只是画质问题，是带宽问题

纹理的mipmap链经常被忽略，但它直接影响缓存命中率。试想一下，一个没有mipmap的地表纹理，在近处采样时GPU要读大图，在远处采样时还是读大图。远处的像素明明只需要几个texel的信息，却被迫读入一大块纹理数据。这相当于你要从图书馆搬一本书到教室，只为了看第3页的一句话——为什么不把目录撕下来带着走呢？

mipmap就是那本“精简目录”。它为纹理生成了从大到小的一系列缩小版本，远处的像素采样时可以直接命中小的mip层，数据量大幅下降。对于地形、墙体这些大纹理，mipmap带来的带宽节省非常可观。

开启mipmap很简单，但真正要做的其实是合理性检查：哪些纹理其实根本不需要mipmap？UI纹理、图集中的小元素、需要保持像素精确排布的贴图都不需要。给不需要的纹理开mipmap，反而会多占33%左右的额外显存，还白白增加了生成时间。

2.3 纹理尺寸上限：1024大于2048

纹理尺寸和发热的关系很直接——尺寸每翻一倍，带宽需求翻四倍（面积是平方关系）。一个2048的纹理，单次采样需要的纹理数据量是1024的4倍。所以，控制纹理最大尺寸是一个性价比极高的策略。

我在项目里常用的一个原则：凡是屏幕占比不超过1/4的物体，纹理尺寸压到512基本够用；全屏或接近全屏的背景、主角特写，才用到1024或2048。这个原则直接能砍掉相当一部分内存和带宽压力。透贴和法线贴图尤其要注意尺寸控制，这两类纹理在shader采样的开销比普通漫反射更高。

如果你做的是Unity项目，纹理的Max Size可以在导入设置里改；如果做的是引擎侧的底层优化，建议在资源导入管线里加一条自动校验，超过指定尺寸的纹理直接告警或者自动压缩。让策划和美术在上传资源时就被拦住，比事后排查要高效得多。

2.4 图集和纹理数组：减少“换纹理”这个隐性开销

每次切换纹理，GPU的纹理缓存都可能要重新加载数据。如果你的模型是这种场景：一个角色身上用了6张64×64的小贴图（皮肤、衣服、裤子、鞋子、配饰……），每切换一次贴图，缓存就会被冲一次。对比之下，把所有小贴图打成一个1024×1024的图集，角色渲染时只需要绑定一次纹理，采样的数据量大减，缓存命中率也高得多。

图集在小尺寸纹理多的项目里效果尤其明显。UI、场景物件、角色服装贴图，都适合做图集合并。纹理数组（Texture Array）是另一个方向，它比图集更好的一点是避免了图集相邻区域间的采样漏边问题，适合用在地形和多物件合批的场景里。

当然图集也不是完全没有代价。图集越大，单次纹理绑定时进入传输通道的数据就越大，所以图集大小也要控制。一般来说，移动端单张图集不要超过2048×2048，1024×1024是更稳妥的选择。

2.5 纹理流送：大世界项目的救命稻草

如果你的项目是大地图、开放世界类型，纹理流送基本是必选项。场景里同时存在的纹理总量远超显存容量，不可能一次性都加载进来，就必须按需加载、按区域卸载。这里面最核心的就是优先级管理——靠近摄像机的纹理高优先级，刚进入视野的纹理高优先级，远离视野且长时间不出现的纹理就可以卸载或降精度。

纹理流送的难点在于避免“突然加载”造成的卡顿。我的做法是：在视锥体的范围基础上外扩一段距离，提前做纹理加载；同时把每个纹理拆分成多个mip层级依次加载，先加载低精度版本保证画面不至于空洞，再渐进式加载高精度版本。这和地图的LOD思路本质上是相通的。

3. 后处理篇：每一趟全屏Pass都在烧电

3.1 后处理开销的度量方式：别只看帧率

后处理优化的第一个问题是度量。很多团队只看帧率，但其实帧率对于后处理瓶颈的敏感度不够——因为后处理通常发生在渲染管线的后半段，它只影响GPU一小段时间，帧率掉得不一定明显，发热却会很真实。

我更建议用GPU Profiler的Render Pass数据来度量。Unity的Frame Debugger能帮你看到每个后处理Pass的执行时间，高通平台的Snapdragon Profiler能给出各Pass在GPU上的耗时和带宽占用。用工具把Pass逐一列出来，你会很直观地看到哪一步是“带宽刺客”。

有了Pass级别的数据，优化优先级就清楚了：先砍那些耗时高、效果不明显的Pass，再合并小Pass，最后再考虑降分辨率。别一上来就整体砍后处理，那等于把整个画面质量一刀切了。

3.2 动刀顺序：砍效果先于降分辨率

后处理优化里有两条路线：一条是减少Pass数量（砍特效、合并效果），另一条是降低每个Pass的渲染面积（降分辨率）。两条路线各有侧重，但实际项目中，我建议先走砍效果这条路。

为什么？因为很多后处理特效是可以放在一个Pass里合并计算的。比如Color Grading和Tonemapping，如果分开做，每个都要读写一次全屏RT；合并成一个Pass，只需要一次读写，带宽直接减半。Bloom和Glow这类效果如果美术上够了，也不一定需要bloom和色差的多次迭代采样。先做Pass合并和效果取舍，再考虑降分辨率，这样才能保住画质底线。

3.3 半分辨率后处理管线：省一半还看不出来

半分辨率后处理是一个性价比极高的方案。做法是：在主渲染结束后，先把最终场景RT降到一半分辨率（比如1080p降到540p），然后在半分辨率上跑那些对精度不敏感的后处理（Bloom、Color Grading等），最后再升采样回全分辨率做合成。

这个过程里每一个全屏Pass的带宽消耗都直接减半。比如一个原分辨率Pass要读写16.6MB×2，半分辨率就只要4.15MB×2。如果管线里有四五个后处理Pass叠加，省下来的数字非常可观。

有人担心半分辨率后处理会导致画质劣化严重，其实还好。像Bloom这种效果本身模糊的，低分辨率跑反而有一种柔化的美感——前提是升采样时用双线性滤波，不能用最近邻，不然会有明显的锯齿。Color Grading这种也是对分辨率不敏感的，直接在半分辨率上跑完全没问题。但像景深（DOF）这种对边缘敏感的，半分辨率处理可能会让边缘闪烁，要不要降需要具体测试。

3.4 Pass合并与RT复用：少切换就是省电

后处理Pass多了，渲染目标之间的切换也会带来额外开销。每切换一次RT，GPU都要做一次完整的flush，pipeline state也要重新设置一遍，这些开销虽然单次不大，但叠加起来在移动端是不可忽视的。

Pass合并的原则很简单：能够在一个Pass里算完的效果，就不要拆成两个。举个例子，如果同时要做高斯模糊和锐化，完全可以在一个pass里先做横向模糊再做纵向模糊，甚至多做几次采样合并输出，而不是拆成blur_pass1、blur_pass2、sharpen_pass三个独立Pass。

RT复用是另一个容易被忽略的点。如果后处理管线里有多个临时RT，尽量让它们复用同一块内存，避免频繁分配和释放。Unity里可以通过RenderTexture的临时分配接口（RenderTexture.GetTemporary）来复用临时RT，切记用完要释放。

3.5 抗锯齿选型：MSAA在移动端是重度发烫源

抗锯齿在后处理优化里总能碰到，而且这里有一个容易踩坑的点。很多人从PC端过来，习惯性开MSAA 4x或8x。在PC上这么做没问题，但移动端MSAA的代价极高——因为它需要在内存里存储4倍或8倍于屏幕像素的样本数据，resolve过程也很耗带宽。

移动端我更推荐FXAA或TAA。FXAA是一个后处理Pass，开销极低，虽然画质相比MSAA稍差，但对于移动端的视觉影响完全可以接受。TAA画质更好，但需要处理历史帧数据，内存和带宽开销比FXAA高一些。移动端如果要做TAA，建议配合TSR这类超分辨率技术一起做，效果会有意外惊喜。

我这里给出一个简单的抗锯齿方案对比：

实操中我还会做一个额外判断：如果项目帧率目标不高（30帧以内），MSAA 4x其实还可以用；但如果目标是60帧或120帧，MSAA直接pass，选FXAA或者TAA。发烫和帧率目标永远是强相关的。

3.6 动态分辨率与自适应性能：让发烫降下来

除了砍Pass、降分辨率，还有一个“运行时”的思路——动态分辨率。这个方案的核心逻辑是：GPU负载高、温度升高时，自动降低渲染分辨率；GPU空闲、温度下降后再恢复。相当于给画面质量加了一个自适应阀门，用动态画质换取温热稳定。

动态分辨率的实现并不复杂。在Unity中可以通过调节渲染纹理的分辨率实现，也可以用RenderScale来实现。关键是要有一个可靠的性能信号来判断负载情况，比如用GPU帧时间（FrameTime）来做反馈控制。设定一个目标帧时间（比如16.7ms），如果长期超过目标值，就逐步降低分辨率；如果回到目标值以下，就逐步恢复。

这个方法尤其适合那种温度天花板的场景：玩家玩久了手机会烫，烫了以后降帧，越降越难受。用了动态分辨率之后，温度被压在可控范围内，帧率能相对保持稳定，虽然画质会稍微波动，但体验比“掉帧+降频”好太多了。

4. 实操记录：一次真实项目的纹理+后处理削减

4.1 第一步：用Profiler给Shader和Pass记账

这里分享一个我最近做过的移动端项目优化过程，你可以在自己项目里复现这套思路。

项目特征是角色扮演类实时战斗，目标机型是老款安卓芯片，帧率目标30帧。刚接手时真机稳定输出大概在22~25帧，机身温度在连续运行15分钟后接近烫手边缘。第一步就是用Snapdragon Profiler和Unity Profiler拉了一整帧的带宽和Pass数据。

结果很典型：后处理管线上一次完整链路是 bloom_extract → bloom_h → bloom_v → color_grading → tonemapping → fxaa，整整6个Pass，全部在1080p分辨率下执行。纹理方面，场景里有大量2048×2048的角色高精度贴图和1024×1024的UI贴图，很多压缩格式还是RGBA。

4.2 第二步：具体改动清单和实测数据

列一下这次优化动过的地方和前后对比：

• 纹理压缩格式：角色和场景贴图从RGBA/BGRA统一改为ASTC 6x6（重要贴图4x4），UI贴图改为ASTC 4x4，全场压缩比至少降了一半以上。
• 场景普通贴图尺寸上限：从2048压到1024，UI大图从1024压到512，个别特写物体保留1024。
• Bloom链路重构：原来的高光提取、水平模糊、垂直模糊、合成四步，改用半分辨率渲染，合并成一个bloom pass + 最后升采样合成，Pass数从4个变2个，分辨率减半。
• Color Grading和Tonemapping合并为同一个全屏Pass，不再单独跑。
• MSAA 4x 切换为FXAA。
• 加入动态分辨率，以GPU帧时间为信号，在16.7ms和22ms之间做两档自动切换。

优化结果：单帧GPU时间从22ms降到13ms左右，帧率从22~25帧稳定到29~30帧。温度表现也更明显，同一台老机型连续运行30分钟，机身从接近烫手的状态缓解到温热。带宽数据上，单帧RT读写带宽大概从200MB/s级别降到了80MB/s级别。

这个过程中我个人最大的体会是：优化前后画质肉眼差距非常小——除非你用放大镜对比单帧截图，否则正常游玩的注意力根本不会注意到那些压缩痕迹。但手感差距是直观的：帧率稳了、温度降了、续航也长了。

5. 常见问题速查与排查技巧

5.1 纹理优化常见问题

5.2 后处理优化常见问题

5.3 几个值得养成的排查习惯

排查纹理后处理发热问题，有几个习惯我觉得特别值得养成。

第一个习惯是用“排除法”定位热点：关掉全部后处理跑一遍帧率，再逐个打开后处理效果，哪个打开之后帧率跌得最狠，哪个就是优化重点。纹理层面同理，可以用一个纯色/低精度纹理替换场景贴图测试帧率变化，如果帧率变化不大，说明纹理不是瓶颈；如果明显掉了，说明纹理采样和带宽问题值得处理。

第二个习惯是“数据对比优先于感觉”：发热问题不是肉眼能看出来的，必须依赖性能分析工具。拉出GPU帧时间、Pass耗时、带宽占用、温度曲线四个维度，用数据说话。不要凭感觉判断哪个效果好哪个效果差。

第三个习惯是保持对老机型的敬畏。你在开发机上看着流畅的画面，在老芯片上可能是灾难。合理的做法是项目里设一个“年度最低档机型”的测试标准，所有优化都以这台机器为主验证目标。这样能避免很多上了线之后才暴露的发热问题。

写在最后：发烫优化的本质是给数据“减负”

这套纹理加后处理的优化思路，我自己在多个项目里反复实践过。我的直观感受是，很多人一听说发热优化就想调分辨率、关阴影、砍特效，结果画质面目全非。但其实在纹理和后处理这两个数据搬运大头上做文章，性价比远远高于粗暴地砍画质。

特别想强调最后一点：纹理压缩格式和mipmap，这两个东西你只要做正确了，基本就是白捡的性能提升。它们不牺牲什么画面表现力，只是在资源的组织方式上动了手脚，带宽和发热却能明显改善。后处理降分辨率和Pass合并也是同理，效果上几乎不可察觉，但温度和功耗的差异是实实在在的。

如果你手头正好有一个发烫严重的项目，我建议你先从本文第2节和第3节的方案里挑两个最容易落地的做起来。先拉一次Profiler数据，再动手改一个纹理压缩格式，合并两个后处理Pass，实测一下帧率和温度的变化。这个流程走通之后，你就有了一套自己的判断标准，知道后续优化的方向应该往哪里走了。