手机一玩就热发热一上来帧率就崩这应该是移动游戏优化里被吐槽最多的问题之一。我翻了几个正在优化的项目日志最后揪出来的“搬运大户”高度一致一个是纹理一个是后处理。这篇文章是发烫优化系列第4篇前几篇聊了CPU侧的调用、渲染管线的卡点、场景里的资源规划这次专门收拾这两个惯犯。先说结论在很多项目里纹理采样和后处理全屏Pass占掉的GPU带宽比Shader里那些花哨的数学运算高一到两个数量级。手机GPU并没有想象中那么怕“算”它最怕的是“搬”——从显存里搬数据。谁搬得多谁发热就多。而纹理和后处理恰恰是整个渲染流程里搬运量最大的两个环节。我这次会把功耗和带宽的账算明白把纹理压缩格式怎么选、mipmap和各项异性过滤要不要开、后处理哪些值得留哪些建议砍、以及怎么用工具把“搬运量”量化出来全部过一遍。偏Unity引擎的工程做法但思路对UE和自研引擎同样适用。1. 为什么纹理和后处理是“发烫惯犯”1.1 移动GPU的工作模式决定了带宽就是功耗移动端GPU基本都是Tile-Based架构。跟桌面GPU直接往显存里画不同移动GPU会把屏幕分成一个个小块Tile在芯片内部的高速缓存里把这块渲染完再一次性写回显存。这么做是为了省带宽但有个前提纹理必须从外部显存读进来。于是问题就来了。纹理数据在显存里GPU的每个像素着色器只要想采样一张贴图就得先把数据从DRAM搬进芯片。这个搬运路径距离远、频率高、耗电大。SoC上做一次浮点运算消耗的能量可能只是读取同等数据量能量的几十分之一。换句话说一个Shader里算一百次数学公式都不如它多采一张大贴图来得烫。所以判断一个项目发烫不发烫别只看Shader复杂度先看看平均每帧采了多少纹理、每张纹理多大、压缩格式是什么。这些数据直接决定GPU在“搬砖”上花了多少体力。1.2 后处理是“搬运量放大镜”后处理的问题更直观一个全屏Pass意味着GPU要把整张画面从显存里读出来经过处理再写回去。以1080P的一张RGBA8渲染目标为例一次读加一次写就是约16MB的搬运量。你加了三个全屏后处理Pass光是来回搬运就要额外产生五六十MB的流量。更麻烦的是后处理往往会引入中间缓冲。Bloom要做降采样模糊景深要做多级处理抗锯齿要混合历史帧每一个步骤都在成倍放大搬运量。很多游戏看起来场景不复杂、三角面不多但一开后处理整机功耗立刻飙上去原因就在这里。我用一个直白的比喻纹理是每天往家里搬大件快递后处理是把同一件快递从客厅搬到卧室、再从卧室搬到阳台来回倒腾好几趟。快递本身可能不重但来回搬的次数多了人也累手机也热。2. 纹理侧瘦身从压缩格式到采样策略2.1 纹理压缩格式怎么选ASTC、ETC2还是PVRTC移动端纹理优化的第一件事就是确保所有运行时贴图都用了硬件支持的压缩格式而不是原始的RGBA8888。RGBA8888是每像素32bit而ASTC 8×8能把每像素压到2bit光这一项就能省出14倍的带宽。选格式时要按目标设备区分。PVRTC是苹果系的老格式质量一般且只在Apple GPU上原生高效ETC2是OpenGL ES 3.0的强制规范兼容性好但透明纹理的压缩效率不算出彩ASTC是目前最灵活的主流选择块大小从4×4到12×12都有可以根据纹理特征去权衡质量与体积。我实际项目里的默认方案是UI图集用ASTC 4×4或5×5场景漫反射用ASTC 6×6到8×8法线贴图用ASTC 4×4或5×5尽量不用RGBA8888。注意法线贴图压缩后需要把B通道里的法线Z分量重构回来采样后要手动计算Z值这步很多新手会漏掉导致画面出现明显的错误光照。需要特别提醒的是格式兼容问题。如果项目打了一个ASTC包跑到不支持ASTC的老设备上驱动可能会把贴图降级成RGBA32bit处理这时候带宽会瞬间膨胀好几倍发热和卡顿反而更严重。上线前一定要用低端安卓机过一遍所有场景确认运行时实际使用的纹理格式与预期一致。2.2 mipmap与各项异性过滤的功耗账mipmap经常被误认为只是提升画质的选项其实它更是带宽优化工具。场景里一张纹理如果在屏幕上被缩得很小却没有mipmapGPU要读取的是整张最大级别纹理再做降采样过滤cache命中率极低带宽浪费非常严重。开了mipmap后纹理单元会根据像素覆盖面积自动选择合适的小级别来采样加载的数据量大幅下降。所以凡是可能被缩小显示的纹理都应该在导入设置里勾选Generate Mip Maps。代价是纹理体积增加约三分之一但换来的带宽下降通常远大于这个损失。各项异性过滤则是需要谨慎的选项。桌面端随手拉16x没什么感觉移动端ring上16x各项异性过滤会让纹理单元的负担明显加重采样次数成倍上涨。我在移动端项目里最高只开4x绝大多数情况下2x已经够了。什么时候需要开地面、墙面这类倾斜角度大、容易产生模糊的贴图才需要考虑普通道具和角色贴图完全没必要全局开启。2.3 我踩过的纹理坑UI图集和法线贴图滥用第一个大坑是UI图集无限膨胀。Unity的SpriteAtlas为了省DrawCall会把很多小图拼成一张大图图集一旦到了2048甚至4096哪怕大部分区域是空的也要按完整尺寸驻留显存。UI又天天显示在屏幕上每帧都会被采样这就是一个长期运转的搬运热点。我调过一个项目打开背包界面就比战斗场景还烫。查了一圈背包背景那张半透明底图是1024×1024×RGBA8888图集也拼到了2048×2048光是这一层UI的纹理搬运就比整个3D场景还高。处理方法是大尺寸UI背景单独切出来压缩图集控制在1024以内半透明贴图统一用ASTC 4×4。第二个坑是法线贴图滥用。法线贴图在移动端是很贵的资源它不仅要额外采样一张贴图还要在Shader里做TBN变换、解包法线、重构Z分量寄存器压力和指令数都起来。不是所有材质都必须用法线贴图。金属质感、布料纹理这些可以用粗糙度贴图加BRDF模拟的就不要硬上法线贴图。我经常跟美术强调移动端法线贴图是“限量版”每张都要按绩效来考核说不清用途就别放进来。3. 后处理侧瘦身全屏Pass的减法艺术3.1 后处理到底贵在哪一次全屏Pass的带宽账后处理这个名字在不同领域指代的东西五花八门做数控机床的人搜“后处理”找的是把刀路转成机床指令的方法但在图形渲染里后处理就是渲染管线的最后一道工序对整帧画面做加工。它有个共同点都是整个流程中最后一道把关一旦出错前面的功夫全白费。我们先给全屏Pass算笔细账。假设项目跑在1080P分辨率一张RGBA16F的浮点渲染目标大约是16.6MBGPU读写一遍就是33MB流量。普通的颜色分级做一次Pass流量至少33MBBloom如果走全分辨率提取高光、半分辨率水平模糊、半分辨率垂直模糊、全分辨率合成这里里外外搬运量轻松突破100MB。一颗旗舰SoC的显存带宽在理想状态下可能三四十GB/s听着挺多一秒钟60帧单Bloom就能吃掉6GB/s留给其他渲染的资源立刻紧张起来。所以后处理优化的核心思路不是“把某个Shader写快一点”而是“减少整帧数据的搬运次数”。分辨率、像素格式、Pass数量这三项直接决定搬运总量。有一次我把后处理缓冲从全分辨率降到75%再配合半分辨率Bloom帧耗时基本没动整机功耗却掉了将近一成这都能在功耗计上量出来。3.2 后处理取舍清单哪些值得留哪些建议砍我整理过一份后处理取舍清单几乎每个项目都能套用色彩分级LUT性价比极高推荐保留。本质是一张查找表加上一次全屏Pass画面风格化效果立竿见影开销可控。强烈推荐所有项目至少做一版LUT调色。Bloom辉光看设备分级保留。中高端机上开着能显著提升视觉冲击力低端机建议直接关掉或者把Bloom分辨率降到四分之一以下。很多玩家抱怨“画质糊”其实多半是低端机开了高负载Bloom导致帧率不足的动态分辨率下降。景深谨慎使用。它需要额外深度信息还要做多个模糊层级移动端开销非常大。我一般只在过场动画和结算界面用战斗场景坚决不开。非要实时效果的话可以用简单的近景径向模糊模拟成本低很多。环境光遮蔽SSAO移动端慎用。采样多、占用寄存器多部分SoC跑起来直接就是发热油门。如果美术对阴影接触感要求高优先考虑烘焙AO贴图性能几乎为零。色差/暗角/噪点这几个属于低成本氛围后处理单次Pass代价不高但叠加起来也会增加搬运量。建议打包到一个Combine Pass里一次性完成不要让每个效果各占一次全屏Pass。FFXAA抗锯齿移动端优先考虑MSAA 4x在后处理执行前用硬件级抗锯齿解决几何边缘问题。FXAA虽然便宜但会模糊纹理细节TAA效果好但多帧混合在部分平台上有兼容坑不是首选。真正动手做减法时我的习惯是把所有后处理先全部关掉跑一个基线功耗然后逐个开后处理每开一个就在功耗和帧时间上做一次记录。谁影响最大、谁收益最低一目了然。3.3 后处理链路的合并与参数收敛后处理的Pass数量是发热的放大器所以要多思考“怎么合并”。像Bloom这类多级降采样处理每一级模糊都要切换一次渲染目标RT切换非常吃带宽。能原地处理的尽量用FrameBuffer Fetch来做省掉中间RT的读回和写回能在一张渲染目标上完成多个效果的就不要开新RT。参数收敛也很重要。把“后处理分辨率缩放”做成全局统一配置低端机给0.5、中端机给0.75、高端机给1.0像素格式在中低端机上用RGBA16F降为R11G11B10F高端机再考虑更高精度。颜色格式越紧凑搬运量越小画质损失多数情况下很难察觉。我还习惯在项目里把后处理档位和机型档位绑定最低档运行一个Combine Pass加LUT关闭Bloom中档开启四分之一分辨率Bloom高档才允许全分辨率Bloom加额外特效。档位之间切换要平滑不要卡着阈值跳变。4. 用工具把“搬运量”查出来量化与定位流程4.1 帧调试器的几个关键数字优化不能靠猜。我每次排查发烫问题都会按下面这套流程拿数据首选工具是Snapdragon Profiler高通平台和Mali Offline CompilerARM平台。Snapdragon Profiler里有GPU Frequency、GPU Busy、Shader Processing、Texture Fetch这些计数器。重点关注Texture Fetch读数它直接反映纹理采样的忙碌程度GPU Busy高、Shader Processing不高说明瓶颈很可能在带宽而不是浮点运算上。RenderDoc适合查看资源使用情况。绑定纹理列表里能看到每张贴图的尺寸、格式、mipmap层级数量。我经常用RenderDoc导出一帧里所有纹理的绑定情况按“尺寸×格式”排序排前几名的通常就是发热嫌疑犯。Xcode的Metal Capture对iOS项目很有用可以看每个Encoder采样了多少纹理、读写带宽多大。如果项目用的Unity可以直接在Profiler的GPU模块看DrawCall耗时但要区分CPU等待和GPU实际忙碌。真机上我用PerfDog这类工具记录帧率、CPU/GPU占用率、电池电流用来评估各项改动带来的功耗变化。4.2 从帧时间到发烫的换算思路帧率高不代表不发热这可能是优化路上最容易踩的误区。GPU工作在满频就能稳定跑满帧率但同时也在持续产生大量热量。真正应该看的是功耗和温升。框架可以这样拆把一台真机充满电清空后台用统一参数跑同一段场景5分钟记录电池温度、整机功耗和GPU频率曲线。改动前后各测一遍对比这三组数据。功耗下降多少、温度峰值下降多少、频率是否更稳定比帧率数字更能说明问题。温度变化还有一个隐藏连锁反应当SoC温度逼近阈值系统会主动降频GPU频率一旦掉下来帧率跟着崩玩家就会觉得“发热卡顿”。所以发烫问题的优化目标不一定是让帧率更高而是让GPU可以稳定在较低频率完成渲染任务留出温度余量。纹理压缩格式换好、后处理Pass数量降下来之后GPU占用率下降频率自然可以降档温度就稳住了。4.3 制定纹理与后处理的发布门槛数据量出来后一定要把结论转成项目规范否则优化结果很容易在后续版本迭代中回潮。我习惯在项目里推行一份资源发布检查表纹理侧运行时贴图一律硬件压缩格式首选ASTC禁止RGBA8888裸纹理进包需要缩放的贴图必须开mipmapUI图集最大尺寸限制为2048常用面板控制在1024法线贴图数量按特性评审不能无限添加。后处理侧低端机档位只允许LUT加CombineBloom分辨率上限四分之一后处理像素格式不能高于R11G11B10F全分辨率后处理Pass数量不超过2个所有后处理开关必须支持运行时动态切换。这份门槛表发布后我把压力给到程序侧每次版本提测前先跑一遍自动检查脚本扫描资源目录里所有违规纹理和RenderFeature配置不合规不许进主分支。有了硬性门槛发烫问题的复发率会明显下降。5. 常见问题与排查技巧实录5.1 常见问题速查表我整理了优化过程中经常遇到的几类现象和对应的排查方向做成速查表症状常见原因排查方法解决方向帧率不低但手机非常烫纹理带宽过高GPU长时间满频搬运用GPU Profiler看Texture Fetch换ASTC压缩格式缩小纹理尺寸开mipmapUI界面比战斗场景更烫UI图集过大或RGBA8888RenderDoc看UI帧绑定的纹理资源压图集尺寸改ASTC 4×4大背景单独压缩开了某个特效后明显发热后处理Pass数量过多或分辨率过高关闭全部后处理再逐个开启观察降后处理缓冲分辨率合并Pass半分辨率Bloom画质看似不高但负载很重法线贴图滥用或纹理分辨率超规格查看材质绑定的贴图类型和尺寸删除非必要法线贴图用BRDF参数模拟细节低端机比预期卡得多纹理格式降级为RGBA32bit真机上查运行时纹理格式检查设备支持的压缩格式做格式版本分级温度上来后帧率突然掉一半SoC过温降频记录GPU频率曲线降低GPU负载把工作频率压下来5.2 再补几条独家心得定位纹理问题时我有一个小技巧把场景里所有纹理临时换成一个1×1的白色贴图跑一遍对比功耗。如果功耗下降非常明显说明纹理搬运是大头如果下降不多那问题可能出在Shader计算或后处理上。这种“单一变量法”能快速把优化重心指对方向。排查后处理也有个类似的招直接做一版“零后处理”版本把颜色分级、Bloom、抗锯齿全部关掉再跑一遍同样场景。两个版本的功耗差值就是后处理总成本。这个数字能帮你说服团队哪些特效值得留、哪些要砍。最后分享一个经验发烫优化的顺序我始终建议先处理纹理再处理后处理。因为纹理是通路上的基础负载纹理格式压好了后处理读取到的中间结果也小反过来如果纹理没管好后处理的中间缓冲再大也救不回来。有次我先把后处理砍到只剩LUT功耗降了5%后来把图集和法线贴图处理完又降了15%加起来效果才明显。纹理这个惯犯确实比后处理更值得第一个动手收拾。