移动端渲染发热优化：纹理压缩与后处理带宽的减负实战

手机发烫这事，只要你是做移动端渲染的，早晚会被它逼到桌子前面老老实实看带宽数据。前面几篇我聊过顶点处理、overdraw、光照模型这些基础优化，今天要说的这两个家伙，属于那种“看起来人畜无害，实际上每天都在偷偷搬运海量数据”的惯犯——纹理（Texture）和（后处理 Post-processing）。之所以把它们单独拎出来开一篇，是因为在绝大多数发热场景里，这两兄弟的搬运数据量，占整个GPU功耗的六成以上，属于优先级最高的“查水表”对象。

先说清楚一个核心结论：移动端发热的根源，绝大多数不是“算不过来”，而是“搬不过来”。GPU的ALU（算术单元）算力这些年进步飞快，但内存带宽和缓存带宽远远没有跟上。你想象一下，一个装满货物的仓库（显存/内存），旁边有个传送带（总线），传送带就那么宽，单位时间能搬的货物有限。纹理采样的本质，就是从内存里把图片数据搬到GPU核心里去算；后处理则是把一张渲染好的图，从一个“临时缓冲区”搬到另一个“临时缓冲区”，中间还要反复读、反复写。搬得越多，功耗越高，温度自然就上来了。所以，理解了“搬运”这两个字，你就理解了一大半发热问题。

很多人一提到发热，第一反应就是“降频率”“锁40帧”，其实那是最后一步的应急方案。真正的性能优化，是从减少搬运量开始的。

1. 先搞清楚“搬运量”是怎么回事：发热的本质是数据搬运

1.1 移动端SoC的发热曲线与功耗墙

咱们聊手机发热，不能绕开SoC（片上系统）的物理特性。不管是高通骁龙、联发科天玑还是苹果A系列，它们的GPU都是一块独立的大核心，运算时需要的是稳定电压和足够的电流供应。手机不像台式机有主动散热风扇，整机散热的唯一途径就是把热量从芯片传导到中框和后盖，再靠空气自然散热。在这样一个被动散热环境里，芯片功耗一旦超过一定阈值，比如3瓦到4瓦，表面温度就会迅速飙升，然后系统开始降频。

降频是什么？就是GPU从1GHz降到800MHz，再降到500MHz，直接牺牲帧率来保温度。所以当你发现游戏从满帧掉到45、40帧的时候，不要以为是“系统坏了”，其实是GPU已经被热得受不了了，自动降频了。

那么为什么数据搬运会成为功耗的大头呢？这里涉及一个概念：内存带宽（Memory Bandwidth），单位一般是GB/s。移动端LPDDR5/5X的内存带宽大概在40-60GB/s，看起来很大，但你要知道，这个带宽是被CPU、GPU、ISP（图像信号处理器）、NPU等所有模块共享的。分到GPU头上，可能也就20-30GB/s的实际可用带宽。而GPU内部的核心频率越高，对带宽的需求就越大。

一句话总结：在移动端，带宽是比计算单元更稀缺的资源。你省下了1GB/s的带宽消耗，实际节省的功耗比省下同样比例的ALU占用还要明显，因为带宽每跳一次，涉及的总线翻转和电容充放电消耗都不小。

1.2 为什么带宽比算力更值钱

很多朋友是从PC端转过来的，觉得台式机上显卡带宽动辄几百GB/s甚至上TB/s，移动端这点带宽算什么？这就是最大的误区。

台式机显卡有独立的GDDR6/HBM显存，功耗和发热整体预算可以放到200瓦，甚至300瓦。而手机整机功耗预算在玩游戏时大概也就4瓦到6瓦，GPU分到的通常只有1.5瓦到3瓦。你想想，3瓦的功耗要驱动的主控频率本来就有限，如果用一半以上的功耗去搬运纹理数据，那留给真正做运算的ALU的功耗还剩多少？所以移动端图形优化的重中之重，不是让GPU多干活，而是让GPU在干同样的活时少搬数据，少访问内存。

我打个比方。你开了一家餐厅（GPU），后厨能同时炒的菜（ALU算力）其实不少，但传菜通道就那么窄，热气又大。如果每道菜都从地窖里现搬最新鲜的食材（纹理），来回跑好几趟，厨房温度很快就上去了。最省力的方式，是提前把常用食材放在触手可及的地方（缓存），把不用的大堆食材先处理好压缩（纹理压缩），并且优化传菜路线，别用原路绕来绕去（后处理pass合并）。

理解了这段话，下面所有优化你都好懂。

1.3 纹理和后处理为何是“搬运量”最大的两个环节

渲染一帧画面的数据流大致是这样：CPU提交绘制指令，GPU读取顶点数据和纹理数据进行光栅化，生成片元（fragment），最后写入帧缓冲（render target）。在这一整条流水线里，纹理采样是最频繁、最密集的数据访问操作。一个复杂的现代游戏场景，可能同时绑定十几张纹理，每个片元要采样3到5次甚至更多，每次采样都是一次内存访问。如果纹理没有压缩，数据量极其惊人。

后处理则是另一条独立的“数据洪流”。后处理发生在主场景渲染完成之后，需要把整张画面当成一张大纹理，来回滤波、混合、拷贝。一个全屏pass，就要读一次整张图，再写一次整张图。画面是1080P，全屏pass的一次读加一次写，就是1920×1080×4字节×2，约16.6MB的数据量。60帧一秒，就是将近1GB的搬运量，而这个数据你还没算多个pass叠加和重复采样。你说这后处理是不是惯犯？明知故犯的那种。

2. 纹理：从资源格式开始堵住带宽漏洞

2.1 纹理格式的位深账本

默认情况下，美术同学导出的贴图多半是PNG或TGA的八位图，到引擎里设置成了RGBA8888格式，也就是每个像素用32位（4字节）来存储。你问这个格式有什么问题？我们来算一笔账。

一张1024×1024的RGBA8888纹理，显存占用是4MB。把它加载到GPU显存，就算不做任何采样，光是一次加载传输就要搬4MB的数据。如果在游戏中，一个角色装备了8到10张贴图（diffuse、normal、specular、mask等），一个角色加载就是几十MB的数据搬运。而引擎通常还会在场景加载时一次性加载几十上百张纹理，瞬间搬运的带宽压力，就会造成非常明显的卡顿或者功耗尖峰。

更麻烦的是采样。当GPU在执行绘制命令时，每一个像素着色器（pixel shader）采样到这张纹理，就会向内存发起读取。假设一帧中所有物体叠加在一起，平均每个可见像素要采样5次纹理，那么每帧的纹理带宽就是屏幕分辨率×5×4字节。1080P下就是1920×1080×5×4，约41.5MB。60帧就是2.49GB/s。这还只是其中一个环节，没算其他Pass。

所以头疼的第一个问题，是纹理格式的“胖瘦”。有压缩和无压缩，差距可以达到8倍。这就是为什么纹理压缩是移动端优化“第一桶金”，只要做了，收益立竿见影。

2.2 纹理压缩选型：ETC2与ASTC的取舍

谈到纹理压缩，就绕不开两个格式：ETC2和ASTC。这是目前安卓和iOS上的主流选择，但很多新手对它们的理解只停留在“压缩了就行，格式选ASTC”，实际用起来踩了一堆坑。

先讲底层原理。纹理压缩和普通文件压缩（比如ZIP）有本质区别，它不允许“解压后再用”。因为GPU要随机采样纹理上的任意一个像素，必须支持直接读取压缩数据中的任意块。所以纹理压缩都是“块式压缩”，把纹理分成一块一块的小区域，对每块单独编码。ETC2把纹理分成4×4的像素块，每个块占用8字节，也就是每个像素1字节，即8bpp（bit per pixel，每像素位数，值越小越省带宽）。ASTC更灵活，它的块尺寸从4×4到12×12都可以选，对应8bpp到0.89bpp的范围，你可以按需要选择“更小”还是“更清晰”。

那到底怎么选？我的经验是分场景：

这里要强调一句：ASTC不是越小越好。压缩比太高（比如10×10、12×12）会带来明显的色块和模糊，尤其在渐变天空、皮肤这类需要细腻过渡的图上，压缩痕迹会被放大。我个人比较推荐的“黄金比例”是6×6，大约3.56bpp，也就是一张1024×1024纹理只需要约1.14MB显存，比RGBA8888的4MB省了四倍多带宽，画质肉眼几乎无感。

另外，纹理压缩不能在运行时随便“转换”，引擎里对贴图设置的压缩格式是在导入时（Import Time）完成的。Unity的Texture Import Settings里有一栏“Compression”，可以选ASTC、ETC2等。但是注意，如果平台转兼容性配置错了（比如Android端设了ASTC，但有些老机器不支持ASTC），GPU会回退到RGBA32，不但没压缩，可能还要额外转换。所以打包前一定得看准目标机型的GPU能力，高通Adreno和ARM Mali对ASTC都支持，但部分老款入门机还是要确认。

2.3 mipmap与小图集：低成本高收益

聊完了压缩格式，再聊一个“看起来不起眼，实际能省一大堆带宽”的神设置：mipmap。

mipmap是什么？就是预先为纹理生成一组逐级缩小一半的副本，从原始尺寸一直缩到1×1像素。在游戏里，一个远处的小物体在屏幕上可能只占指甲盖大小，如果采样原图1K贴图，GPU仍然要把一大块纹理读出来再算平均值，这种浪费极其恐怖。而mipmap机制会自动选择接近屏幕尺寸的那个缩小版本去采样，同样效果，读的数据量小得多。

带宽能差多少？我做过一次简单测试：同一场景里，将所有开启mipmap和关闭mipmap进行对比，在GPU带宽占用上，开启mipmap后采样带宽平均能降低30%-40%。这个数字在纹理尺寸较大的场景里可能更高。更关键的是，mipmap还能减少纹理闪烁（就是远处物体表面高频细节放大后出现的摩尔纹和抖动），对画质也是正向帮助。

那为什么还有人不开mipmap？因为mipmap会额外占用约三分之一的显存（各级mip加起来的总面积约是原图的1.33倍）。对于显存极度紧张的项目，有些团队会犹豫。但我的观点是：只要不是能明确看出内存不足导致崩溃，优先开mipmap。因为带宽是发热的核心，显存差一点可以通过压缩格式和加载策略补，带宽差多了，温度压不住就直接完蛋。

还有一个常见做法是纹理图集（Texture Atlas）。把很多小图标、小贴图拼成一张大图，可以减少切换纹理时的状态更改和Draw Call。但要注意，小图拼图集后，如果原图之间留白太多，图集尺寸变大，采样带宽反而可能增加。所以图集一定要考虑“打包率”，尽量减少空白区域，并且建议把同一批贴图按使用频率分组，不要一股脑全塞进一张4096×4096的大图里。

2.4 纹理上传与生命周期管理

还有一个容易被忽视的“搬运”来自纹理资源本身的加载流程。纹理从磁盘（或压缩包）读入内存，再上传到GPU显存，这个“搬运”虽然不发生在每一帧，但发生在加载关卡、进出UI这些关键时刻。如果一次性加载大批高分辨率纹理，瞬时带宽会直接把游戏卡成PPT，甚至被系统判为无响应。

针对这个情况，常用的手段有两个：异步加载和分块加载。异步加载就是在后台线程做纹理解析和上传，避免阻塞主线程；分块加载则是把超大的纹理切成若干小方块（比如把8K大地图切成16块2K），按需加载。这在开放世界和超大地图里是标配级别手段。

Unity里，Resources.Load和Addressables都有异步接口；原生OpenGL ES里，可以通过glTextureStreaming或者动态调度纹理上传时机来操作。但不管是哪种，我都建议在加载时先给玩家一个“loading”过渡，防止中间画面卡住太尴尬。更重要的一点：纹理上传完成后，释放掉CPU端的原始数据。很多团队只处理了GPU端“加载慢”，忘了CPU端内存还占着。CPU端内存一旦吃紧，系统就会杀掉你的应用后台任务，这其实影响到整体调度，旁敲侧击也会让GPU资源被回收重分配，间接增加发热。

3. 后处理：一场全屏pass的搬运大赛

3.1 后处理管线的带宽模型

讲完了纹理这个“惯犯”，下一个就是“从犯”里最气人的一个——后处理。很多人不理解，不就加了个Bloom、加了个景深吗，为什么手机就发烫？问题不在于“加”，而在于“从头到尾搬了多少遍数据”。

后处理管线的每一个特效，本质上都是一个或多个全屏pass。每执行一个全屏pass，GPU要把当前帧缓冲的一张整图读出来，经过像素着色器计算，再写到另一张纹理里去。这个“读一次+写一次”就是固定的搬运成本。我们算个账：假设一张1080P的RGBA16F HDR帧缓冲，分辨率是1920×1080，每像素占8字节（RGBA半浮点），一次读加一次写就是1920×1080×8×2，约33.2MB。60帧的情况下，一个pass就是2GB/s的带宽消耗。你跟我说一个后处理链路上有4个pass？那光后处理一条链路就能吃掉8GB/s的带宽，接近移动端GPU全频段可用带宽的三分之一以上。

所以，后处理优化的第一优先级，不是“把算法写得更聪明”，而是“能不能少搬一次数据”。能合并的pass尽量合并，能裁剪的范围尽量裁剪，这是后处理优化的底层逻辑。

3.2 从Bloom看一张图被来回搬了多少次

以最常见的Bloom（泛光）特效为例，看看一张图能多折腾。标准版Bloom流程大致是这样的：

1. 从主帧缓冲中，按亮度阈值提取高亮部分，得到一张HDR的“亮部图”。
2. 对亮部图进行多次1/4降采样，比如从全分辨率降到1/2、1/4、1/8、1/16。
3. 对每层缩小图做两次高斯模糊（横向+纵向）。
4. 把所有模糊后的层逐级上采样，累加到同一张图。
5. 最后把这张累加亮部图与原始主图进行合成，输出最终画面。

你数一下，这里面到底做多少次全屏数据读写？提取亮部，1个pass；4个mip级别的降采样，4个pass；每层模糊平均2次，4层就是8个pass；4级上采样累加，4个pass；最后的合成，1个pass。合计大约18个全屏pass，还要算上中间有些pass的读写是半浮点格式，数据量更大。这样一条Bloom跑下来，哪怕用半分辨率也需要额外消耗好几GB/s的带宽。而很多项目里还不止一个后处理，景深、动态模糊、色差、暗角、噪点一层层叠上去，不做优化，人家发热你不发热才怪。

所以做移动端后处理，最忌讳的就是照着PC游戏那一套“高大全”效果直接搬。PC有几百瓦功耗预算，手机没有。必须对后处理做“移动端专属简化”。常见的简化套路包括：

第一，能省就省。画面里不重要的地方，不放大镜头，景深可以改成只对中景区域做简单半径偏移的散景近似，不需要全屏高斯。第二，能用“便宜”算法就用便宜算法。Bloom里的高斯模糊，可以用双线性采样的降采样——直接每次降采样时进行一次采点优化，两步模糊可以通过两个pass做近似，而无需完整大半径高斯。第三，把后处理分辨率降低。这个策略效果最猛，后面重点说。

3.3 降分辨率、双线性/双三次恢复与pass合并

后处理分辨率单独拎出来说，因为这是移动端性价比最高的操作之一。经典的思路是：主场景渲染用全分辨率，后处理在1/2或1/4分辨率上跑。也就是把1920×1080的图先降采样到960×540，所有后处理pass在这个半分辨率上执行，最后一步再上采样回1080P。这样做，后处理链路的带宽直接降到原来的1/4，因为每个pass的像素数只有原来的四分之一。配合pass减半，后处理带宽能从8GB/s级别降到1GB/s级别，效果立竿见影。

有朋友担心画质损失。这里要说明，后处理大多是低频效果（模糊、光晕、色调），对高频细节不敏感，半分辨率运行完全能接受。至于上采样，不要用“最近邻”，尽量用双线性。现代GPU硬件里双线性几乎免费，效果比最近邻顺滑太多。如果追求更高画质，可以用双三次（bicubic）上采样，但双三次采样开销更高，移动端不推荐。我一般只在需要“精致散焦”这种特性时用2次采样数量模拟双三次，大部分情况双线性足够了。

还有一个隐藏技巧：后处理链路里的中间结果，尽量使用低精度格式。比如Bloom的亮部提取，用R11G11B10F或者R16F，不要用RGBA16F，因为亮度数据根本不需要Alpha通道和完整RGB精度。把中间RT（render target）从32字节降到4字节，带宽减少8倍。这一步容易做，效果却很猛。

另一个策略是pass合并。比如提亮部、降采样、模糊，三个pass是否可以合并成两个？利用像素着色器里采多个采样点，把横向模糊和纵向模糊合并进一次shader，虽然对ALU压力有增加，但能省下一个全屏pass的带宽。移动端的GPU负责计算的能力一般强于带宽，这种“以算换搬”的交换通常划算，尤其在发热瓶颈在带宽的时候很值得做。

4. 实战下来最管用的几步优化操作

4.1 先用Profiler拍现场：RenderDoc / Unity Frame Debugger / Xcode Instruments

我见过太多优化翻车案例，都是因为不做数据测量，上来就乱砍效果。所以第一步一定是“拍现场，找证据”。我们常用的几个工具，我都试过，给你排个优先级：

RenderDoc适合深度抓帧分析，在PC上用支持Vulkan/D3D11/GL的项目抓帧后，能看到每一个DrawCall绑定的纹理格式、尺寸和采样位置，还能在“Texture Viewer”里看到每张贴图的实际显存占用，是排查纹理格式和尺寸问题的最好工具。

Unity Frame Debugger配合Unity Profiler就够用，能看到每一帧的Draw Call、渲染Pass、RT切换和绑定纹理变化，快速定位哪个纹理被频繁绑定，或者哪个后处理pass过于昂贵。

如果你是iOS/Metal项目，Xcode的Instruments里有一个“Metal System Trace”模板（GPU工作负载里的“GPU Counters”面板），可以看到带宽占用和着色器周期等指标。Android上则可以使用Snapdragon Profiler（高通）或Mali Offline Compiler（ARM）来获取具体计数器。

Profiler的意义不是给你一个“大概印象”，而是把纹理和后处理的实际带宽消耗量化到具体数字。我每次拿到一个新项目的发热问题，第一个动作永远是抓帧，看“每个Texture的内存占用 Top20”和“每个RT pass的带宽占用 Top10”，而不是去猜到底是谁在发热。

4.2 纹理层面落地清单与操作

确定了是纹理问题，按下面顺序来一遍，效率高：

第一，检查所有纹理的格式。把那些还残留RGBA8888的大图，尤其是UI图、场景贴图，统一改成ASTC 6×6或ETC2。这一步操作完，光内存占用就能降70%。需要注意：如果项目里有多个平台，压缩格式要按平台分开设置，不能一刀切。

第二，开启关键纹理的mipmap。特别是场景中大量出现的地面、墙面、树木和UI里的可缩放元素。如果怕mipmap导致远处细节糊，可以配合“Aniso Level（各向异性过滤）”设置，通常设2x或4x就够，太高的各向异性采样开销大，反而对带宽不友好。

第三，梳理纹理尺寸是否过大。很多美术导出贴图习惯用2048或4096，但一个占屏不到1/4的角色，2048贴图完全浪费。我的习惯是：只有在镜头能怼到“特写”的物体才用2048，普通交互物体用1024，远景模型用512甚至256。这个规则写在资源制作规范里，比后期排查高效得多。

第四，查图集和纹理加载流程。确认没有在每帧里创建和销毁大纹理，没有多次上传同一张图。用异步加载替代同步加载，确保真正需要时纹理已经拿到，且释放掉CPU端拷贝。

4.3 后处理层面落地清单与操作

后处理优化，我同样给一个完整的检查清单：

第一步，统计当前后处理管线里总共有多少个全屏pass，以及每个pass在读和写什么RT。把这个数字写下来，你会惊讶于它有多高。第二步，把所有后处理pass的RT设成半分辨率，能合并的pass合并，能去掉的效果直接去掉。第三步，把中间RT尽量换用低精度格式。第四步，看看Bloom的高斯步数能不能从“9-tap”减到“5-tap”，降采样层数能不能从4级减到3级。

加一个真实的项目经验：之前优化一个开放世界游戏，后处理链路里有Boom、景深、动态模糊、色差和暗角，每帧全屏pass数量有24个。我做了这么几件事——暗角直接删掉（没人在开车时会盯着屏幕四角看），色差从全屏改成只在镜头边缘做UV偏移，景深换成半分辨率并减少模糊级数，Bloom的降采样从4级减到3级。最后后处理的带宽占用降低了差不多60%，帧率从掉到40帧以下回到了稳定60帧，手机背面温度也明显降了。

画质损失多少？我自己肉眼在手机上真没看出明显差异。后处理效果在设计上本来就应该是“锦上添花”，不是你画面的主角。给玩家一个流畅、不发烫的60帧，远比你把它满特效堆上去但是只能跑45帧要值。

4.4 实测数据前后对比

为了让你对优化幅度有个直观感知，我列一份当时记录的真实测试数据（项目代号“平原”，场景为野外地图，手机为某骁龙8系旗舰，测试时长为10分钟战斗）：

需要注意，“变化幅度”里的带宽降幅不是单纯某一项优化带来的，而是纹理压缩、mipmap、RT降分辨率、pass合并、低精度RT等多管齐下的结果。但也正因如此，才说明这些优化方向加在一起，解决发热问题的能力有多强。

5. 避坑记录与常见问题速查

5.1 纹理压缩带来的画质与兼容性问题

纹理压缩不是万能灵药。ASTC虽然好，但压缩比开太高，在暗部渐变区域会看到明显的色带（banding）。我遇到过一次案例，天空贴图用了10×10的ASTC，结果傍晚的天空全部变成了一圈圈彩色阶梯，玩家截图发布出来，被吐槽“游戏画质拉垮”。后来改成6×6，配合一点点噪声抖动扰动画面来隐藏色带，才把问题压下去。所以压缩比的选定，一定不要只盯着带宽和内存，还要结合具体纹理的内容和用途。

另外要注意：ETC1格式不支持Alpha通道，很多老项目为了兼容老机器用了ETC1+R分法，结果透明贴图渲染出错。现在OpenGL ES 3.0以上设备基本都能支持ETC2和ASTC，不用再纠结ETC1了。真遇到不支持ASTC的远古机，直接走ETC2通道，不要用ETC1硬扛。

5.2 后处理降分辨率引起的闪烁与细节丢失

后处理降分辨率最典型的坑，是半分辨率下的高光闪烁。比如Bloom在半分辨率上做亮部提取，屏幕上像素太小的高光物体（比如远处的路灯）会在采样时被“丢了”：这一帧还在，下一帧就没了。解决办法一般是提高亮部提取的容差范围，或者做一次小半径膨胀（dilate），也可以把降分辨率从1/2改成1/4后再上采样，再用上一帧的临时缓冲做时间性滤波。不过实话实说，时间性滤波在移动端成本不低，建议先用简单方案，实在不行再上。

还有一个坑：景深在半分辨率下处理，近处主体的边缘很容易出现“毛边”。这时需要保证采样时使用的深度值是从全分辨率深度缓冲里重投影采样来的，不能直接在同一张半分辨率RT上直接取深度。否则深度精度不足，边缘判定错乱。

5.3 优化到一半发现瓶颈转移怎么办

这个现象很常见，以至于我要专门提醒你：你优化了纹理，带宽降了；优化了后处理，带宽又降了。但这时可能发现GPU的ALU占用上来了，或者CPU的DrawCall提交又满了。其实这不算坏事，因为你已经把一个瓶颈疏通开了，下一个瓶颈自然浮上水面。

但如果你发现“优化了一大堆，温度没降”，那就要怀疑是不是CPU侧的问题，比如游戏逻辑更新、物理计算、脚本分配内存这些导致的频率弹跳。CPU频率高，也会让整机功耗和热量上升。所以优化发热，一定要系统看，CPU和GPU一起看，不要只盯渲染。这时候回头翻翻我这个系列前面几篇讲到的渲染批次、Job System和overdraw，配合着调。

还有一个容易被忽略的点：驱动层的纹理采样缓存（texture cache）和行为差异。不同的GPU对纹理压缩格式的缓存命中率不一样，比如部分Mali GPU纹理缓存命中率就比Adreno低。有时候你发现用相同格式，在不同GPU上发热表现差很多，不要怀疑是优化方向错了，先确认目标平台主要集中在哪类GPU，再针对性微调压缩格式和采样规模，这种“平台特性优化”在旗舰机型上尤其有效。

5.4 关于后处理与目标检测场景的小彩蛋

顺便提一句，虽然“后处理”这个词在渲染里指的是画面特效链，但如果你在游戏客户端里做了一些屏幕分析相关的功能，比如目标检测中的yolo后处理流程，那同样要注意：大量的数据在CPU和GPU之间来回“水稻搬运”，也会造成发热。移动端很多开屏识物、辅助瞄准等功能，就是在读渲染结果后做推理再写回，这一来一回的数据量，往往被忽视了。实际项目中，如果在游戏画面里叠加了这类分析任务，建议把推理结果做帧间缓存，不需要每帧全量处理，频率降到原来的1/5，发热就明显改善。

写在最后的一点经验

做纹理和后处理优化这两年，我最深的体会是：发热问题不是靠某一次“大招”解决的，而是一个持续收敛的过程。你不可能指望加一个压缩格式就把所有发热问题消灭，也不可能光靠砍掉几个特效就一劳永逸。真正有效的方式，是建立一套以“带宽”为核心的性能指标体系，每次改动前先量数据，改完再量一次数据，看趋势是否收拢。

而且，纹理和后处理作为“搬运量最大的两个惯犯”，你必须在项目前期就把优化思路定好。如果等到版本末期再改，纹理格式、贴图尺寸、后处理分辨率这些根本不可能顺利改完——牵一发而动全身。我现在接新项目，第一件事就是推进资源规范和渲染管线约束，把这俩兄弟“关进笼子”里，别让它们到处乱搬东西。

如果你今天只记住一句话，我希望是这句：在移动端，发热的本质是搬运，搬运的天敌是压缩、低精度和少折腾。想清楚这句话，大部分发热问题你已经赢了一半。