最近在群里聊起手机发烫这个话题我发现很多朋友第一反应是锁帧率、降画质、换散热背夹这些办法不能说没用但都是在“事后补救”。真正高效的思路其实是在渲染源头把开销降下来而光照烘焙就是这个系列里我最想推荐的一招。它省下的不是某个小模块的电而是整个实时光照链路里那一大块GPU计算量效果比简单拉低分辨率来得明显得多对画面观感的影响又小得多。这篇就把它彻底讲透。如果你正在做移动端游戏或者重度交互项目又碰上手游玩几分钟机身就开始温吞吞地发热、帧率一路下跌那这篇文章就是给你准备的。我会先解释发热跟渲染管线之间的关系再拆解光照烘焙为什么能降温然后给出一套Unity里的实操配置最后把常见的翻车现场和排查方法都盘一遍。1. 发烫的本质实时渲染在烧你的GPU1.1 手机发热最核心的源头其实是功耗别把发热想得太玄发热的本质就是功耗。手机里没有一个专门发热的零件所有热量都来自电能转化成热能的那个过程。屏幕一亮、CPU一跑、GPU一渲染电流在芯片里不断翻转能量损耗最终以热量的形式散出来。手机机身就那么点体积没有主动散热风扇只能靠均热板和机身外壳被动散热一旦SoC持续高负载温度就控制不住。这里面最容易被人忽视的是你玩大型游戏的时候发热最狠的往往不是CPU而是GPU。CPU去做逻辑、物理、动画这些工作负载再高也就是几个大核在跑GPU可不一样它要在16毫秒甚至更短的时间内把几百万个三角形画出来每一个像素都要做光照、阴影、贴图采样每一帧都在全速运转。帧率越高、分辨率越高、场景越复杂GPU的功耗就呈线性甚至超线性往上涨。所以你看优化发热这件事本质上就是在优化“单位时间内GPU到底干了多少活”。你跟它说“你慢点跑”它当然能降温但游戏也卡了你让它“别画那么多乱七八糟的东西”画面又可能变得没法看。真正高明的做法是让GPU不去做那些没必要做的重复劳动。1.2 光照计算是场景里最贵的“电费单”之一那在这些重复劳动里最贵的一项是什么我的经验是光照。一个典型的移动端实时场景里光照开销往往排在渲染耗时的前几位。先不说复杂的全局光照GI光是普通的直接光就够吃性能了。你要给场景放几盏点光源每个物体就要单独算一遍这些光源对它的影响你要让光源产生阴影又得从光源视角把整个场景深度渲染一遍这是额外的一整趟Draw Call和深度计算。最麻烦的是阴影的锯齿和边缘闪烁处理起来还要上软阴影、PCF、PCSS这一套采样方案采样次数一多GPU就跑得嗷嗷叫。再往上一个台阶就是间接光了。光线打到墙壁上会反弹反弹后再照亮旁边的物体这种多次弹射的光照效果叫全局光照。它好看是好看但计算量是灾难级的。PC上开个实时光追都要看显卡脸色手机端根本不敢想。所以很多移动项目本质上就没有做任何形式的间接光照画面里的暗部就是死黑一片看起来非常“塑料”。这也是光照烘焙另外一个隐形价值所在它不仅帮你降温还顺便把画面质感提升了一个档次。换句话说如果你发现项目发热严重先别怀疑是不是Shader写得不够极致先从光照这块查一查。很多时候光是把动态灯光的数量和阴影类型控制住GPU负载就已经降下来一大截了。1.3 想降温第一步是看清楚渲染管线里谁在烧钱实操层面第一步不是上来就改代码而是先打开Profiler看清楚耗时分布。Unity里用Profiler能看到Rendering耗时占比进一步用Frame Debugger可以逐Pass查看渲染内容这就很容易定位到光照相关的Shader Pass。有些项目的阴影Pass占整个渲染耗时20%以上有些项目的Overdraw问题严重其实就是因为实时灯光太多同一像素被反反复复地画。我自己排查的时候习惯把RenderDoc也接进来逐帧看GPU的带宽占用和填充率。移动端的GPU是Tiled Based架构最怕的就是过度绘制和带宽爆掉而光照计算在移动端常常是推高带宽的主要元凶之一。等你真正用数据看到“原来这个场景里30%的GPU时间都花在实时阴影和光照上”你就明白为什么光照烘焙这件事这么值得做了。2. 光照烘焙为什么是降温“性价比之王”2.1 原理一句话把实时计算变成预览查表光照烘焙的思路其实特别朴素既然光照计算这么贵那我们别在运行时算了提前在编辑器里把所有结果算好保存成一张张带光照信息的纹理贴图运行时GPU只需采样即可。打个比方这就像你每天中午做菜如果每顿饭都从洗菜切菜开始一天下来光准备食材就累得不行。但你可以在周末把一周的菜全部洗好、切好、分装好工作日回家直接丢锅里炒就行了。光照烘焙就是这个“备菜”的过程把最费时间的那部分工作全部前置运行时的开销自然就低到可以忽略不计。烘焙之后一个原来要用四五盏实时灯、好几个实时阴影源才能撑起来的场景可以做到零动态光源。GPU不再需要为任何一个像素算直接光、阴影、间接光只需要把这几个三角形的位置算好然后从光照贴图里把颜色取出来填进去就好了。这个开销差着数量级。从发热角度来说光照贴图的采样开销跟实时光照完全不是一个量级就跟你打开一张图片看某个像素的颜色一样便宜。而实时光照要考虑光源参数、衰减、阴影贴图、软阴影采样这些一大堆数据为了还原一个真实的光影效果GPU每个像素要做几十次甚至上百次计算。2.2 和几款常见降温方案横向比一比为了帮你更直观地感受光照烘焙的“性价比”我把几类常见的降温手段放到一起做了个对比。这里用“性价比”不是指花钱而是指获得同样降温效果时你付出的画质代价和开发成本。优化手段降温收益画质/体验代价开发成本综合性价比缩放渲染分辨率高整体变糊UI也跟着糊极低前期高后期低锁帧率30fps高流畅度明显下降极低看游戏类型替换低配Shader/砍特效中风格变化大难还原中中减动态灯光光照烘焙高动态光影变弱但静态画面几乎无损中高极高先说降分辨率。这个方案确实立竿见影把渲染分辨率从1080P降到720PGPU负载直接砍掉一大半但代价是画面发糊尤其文字和UI边缘锐度下降做出来很掉档次。再说锁帧率从60帧锁到30帧功耗确实降下来了但对动作游戏来说手感变化太明显玩家能立刻感知到。至于砍Shader特效这个对美术来说简直是灾难很多效果是花了几个月调出来的你说删就删光照烘焙最大的优势在于它砍掉的不是“效果”而是“重复计算的成本”。烘焙前和烘焙后在正常游玩视角下看场景没太大区别甚至因为增益了间接光暗部细节比原来更好看。可GPU负载就这么实打实地降下来了这是我觉得它配得上“性价比之王”这个称号的原因。2.3 哪些场景不适合一上来就烘焙不过光说优点不说限制也不够厚道。光照烘焙不是万能的有些场景你强行用它反而会做得很难受。最大的问题是动态时间。如果你的游戏有昼夜循环随便一个露天场景的太阳角度一直在变烘焙就完全没法用。烘焙出来的光照贴图是某个固定时刻的光照结果太阳角度一变整个场景的光影全对不上。第二个是大面积动态内容。比如一个开放世界地图会拼接、物体随时增删烘焙贴图没法实时更新就会出现“灯光照不到新加进来的物体”这种尴尬情况。第三个是画面风格特别依赖动态光影的。比如恐怖游戏里手电筒扫来扫去或者赛车游戏里灯光追着车跑这些效果必须靠实时光照烘焙帮不上忙。对这些类型要么用混合光照模式兜底要么干脆只烘焙间接光直接光继续走实时渲染一部分收益先吃下来再说。3. Unity光照烘焙实操从配置到出图3.1 场景准备的三个动作静态标记、灯光分类、UV检查讲完原理直接上实操。我这里以Unity 2021及以上版本为例用的是内置渲染管线URP/HDRP思路大同小异就是入口位置和参数名略有差别。第一步是给场景里的物体做静态标记。光照烘焙的逻辑是“谁标记了静态谁才会吃到烘焙的光照”所以你需要把地面、墙壁、建筑、装饰这些固定不动的物体全部选中在Inspector面板右上角勾上Static。注意这里不是简单勾一个Static就完事需要展开Static下拉菜单确认Contribute GI这一个选项是打勾的。没打勾的话这个物体虽然静止但依然不会参与烘焙运行时还是走实时光照。第二步是调整灯光模式。选中定向光在Light组件里把Mode从Realtime改成Mixed这样日光作为主光源可以保留一部分实时阴影再叠加烘焙的间接光。其他补光的点光源、聚光灯如果你确定它们的位置在游玩过程中不会变可以直接改成Baked让它们完全进入烘焙流程。这里我的习惯是主方向光用Mixed辅助灯光全Baked。第三步是检查模型的Lightmap UV。光照贴图需要一张独立的UV展开图就是俗称的第二套UV。导入模型后在Model面板里勾选Generate Lightmap UVsUnity会自动生成一套不重叠的UV用来决定光照贴图怎么展平。如果不勾烘焙时会提示Mesh has no lightmap UVs。对大场景的模型建议先自己用建模软件展好第二套UV不用完全依赖自动生成自动方式的接缝和密度分配未必理想。3.2 五个关键参数决定烘焙速度与质量场景准备好之后打开Window - Rendering - Lighting进入Scene选项卡里面有一串和烘焙直接相关的参数。移动端优化时我重点关注五个。第一个是Lightmapper选Progressive GPU还是Progressive CPU。如果你电脑有一块支持CUDA的N卡果断用GPU模式速度能差到五倍以上。第二个是Direct Samples、Indirect Samples、Environment Samples三个采样数它们决定烘焙时光线追踪采样的密度数值越高光影越平滑但时间成倍增长。移动端场景建议先从Direct 32、Indirect 64、Environment 32起步后面根据效果再往上加。第三个是Lightmap Resolution单位是texels per unit就是每个Unity单位长度分配多少像素。移动端根本上到20就已经够用了我建议从10起步。第四个是Lightmap Padding控制光照贴图里不同UV块之间的间距默认2在复杂模型上容易出接缝调到4比较稳。第五个是Max Lightmap Size移动端我建议直接限制到512或者1024过大的单张贴图既占内存又拖加载速度。这里有个细节容易踩坑就是Compress Lightmap这个选项默认是开着的。它在非移动平台用DXT压缩在移动平台用ETC/ASTC压缩文件体积能小不少。但是压缩有损如果发现烘焙出来明暗过渡出现色块断层可以把压缩关掉试试不过包体会明显变大。折中方案是保留压缩但把Max Lightmap Size调小让单个贴图内部像素密度不至于太低。3.3 完整跑一遍烘焙并验证降耗效果参数调好后点Lighting窗口最下方的Generate Lighting按钮Unity就进入烘焙流程了。进度条会显示当前正在处理的步骤下方Log里会记录每个步骤的耗时。如果用的是GPU烘焙显卡风扇会直接起飞这是正常的。烘焙完打开Window - Rendering - Lighting - Baked Lightmaps选项卡能看到生成的光照贴图列表和每张贴图的大小。到这里操作流程只是走完了一半真正关键的是要用真机验证效果。我建议你在Unity的Build Settings里打一个Development Build包连上Profiler在相同场景里对比烘焙前后的GPU耗时。我实测过的一个室内场景原来有4盏实时点光源全开阴影帧耗在10ms上下。把主方向光改成Mixed、辅助灯全Baked并完成烘焙之后帧耗直接掉到了4-5ms温度也从手摸明显烫手的程度退回到温而不烫的状态。不同项目数字有差异但烘焙后光照相关耗时下降到原来的30%-50%这个量级是比较常见的。3.4 别忘了给动态物体补上光照探针一个场景不完全是静态物体玩家角色、NPC、可交互道具这些动态物体不参与静态烘焙它们如果站在烘焙过的场景里接收不到间接光会显得格格不入。这时候要在场景里布置Light Probe Group也就是光照探针。把Light Probe Group组件挂到一个空物体上然后编辑探针的分布位置。逻辑上就是在场景空间里均匀撒一批“采样点”运行时动态物体会自动选取周围最近的几个探针插值出它所处位置应该接收到的光照信息。探针布置的密度不需要太高但在地形起伏明显、明暗交界多的地方要加密。布置完后重新烘焙一次探针数据会和光照贴图一起生成出来。这样动态角色在阴影区和亮区的过渡就会自然很多。如果项目里有镜面物体、金属质感的材质单纯靠光照贴图是不够的还需要加Reflection Probe反射探针来采样环境反射。移动端这类反射探针会影响性能不建议用得太密反射探针开一个到两个就够用了多了很容易把内存和渲染耗时一起吃上去。4. 光照烘焙常见问题与排查技巧实录4.1 漏光、黑面、接缝五次翻车现场复盘烘焙翻车几乎是每个项目都会经历的事我自己第一次做的时候也折腾了很久这里把最常见的几类问题集中盘一下。第一类是漏光。场景里墙壁跟地板的交界处出现一条条光带好像光从墙脚渗进来的感觉。这个问题八成是建模阶段墙和地板没有完全密封网格之间存在肉眼不可见的细缝烘焙光线就钻进去了。排查方法是在最高漏光处的点一个光源看阴影和几何相交的缝隙或者直接在模型软件里做一次“焊接顶点”操作。第二类是黑面。烘焙完发现某些表面是全黑的明明光照角度正确材质也没有问题。一个常见原因是模型法线方向反了光照从正面打过来结果三角形背面的法线计算出来是零光照。还有一个原因是模型只有单面材质背面没有面。在Unity里可以把材质球的Surface Type改成Transparent临时检查一下或者在编辑器里把Mesh的Recalculate Normals跑一遍。第三类是明暗过度处的色块断层。原本应该是平滑渐变的阴影结果变成了一环一环的色阶很像压缩过度的JPEG图。原因是Lightmap Resolution或者采样数太低光影信息在贴图上本身就不够压缩再一次损失细节。解决办法是把Resolution从10往上提到20Enable Indirect Samples到128左右如果还不行再检查压缩格式是否太激进。第四类是模型上的接缝线。整个模型看起来没什么问题但有一道道明显的阴影边界好像拼图没拼好。这个一般是第二套UV的缝合线没处理好或者Lightmap Padding不够。把Padding从2调到4同时检查Generate Lightmap UVs生成的UV是否有重叠重叠的UV区域会被同一块光照信息覆盖导致渲染结果像布料被拉扯过一样。第五类是动态物体在烘焙场景里像“贴了层荧光”颜色跟环境完全不搭。原因是Light Probe设置的位置太少插值出来的光照跟实际环境不匹配。把探针密度提高尤其在暗部区域加几个探针问题就能解决。4.2 烘焙时间太长怎么把“一晚上”变成“半小时”烘焙慢是很多人放弃光照烘焙的直接原因。场景一大动辄一两个小时改个灯光参数又要全量重烘一次迭代效率很低。这里有几个很实用的提速技巧。一是先用低参数排查。正式开始烘焙前把Lightmap Resolution降到1采样数全部降到4整个过程可能只需要几十秒足够快速验证灯光布局和场景设置是不是对的。等确定没问题了再调高参数跑最终版本。二是烘焙只针对修改过的场景。如果项目是多场景架构在Lighting窗口的Scene选项卡里把不需要烘焙的场景取消勾选减轻单次任务量。三是在烘焙期间不开任何实时反射相关的功能把编辑器里的Scene View的Shading Mode切回Shaded有些版本里实时预览光照会跟烘焙器抢GPU资源。如果你的机器配置不错Progressive GPU模式下还很长那多半是场景物体数量太夸张了。检查一下有没有大量高模被误标成静态一个物体的面数几十万光照贴图光照采样要跑几十万次三角形自然是慢。记住一个原则烘焙时间跟场景Triangle数量和Lightmap Resolution成正比优化瓶颈先看这两样。4.3 Lightmap包体与内存控制移动端绕不开的坎光照贴图本质上还是贴图有分辨率就有文件大小就有运行时内存占用。移动端游戏包体动辄上百兆Lightmap要是控制不住分分钟又吃你几十兆。所以从项目刚开始就要把移动平台的目标定好不要等上线前再优化。我的默认策略是这样的。限制单张Max Lightmap Size为512或1024一个场景生成的Lightmap数量尽量控制在8张以内单张不超过1024x1024。如果场景特别大宁可把Resolution降到8 texels per unit也别靠堆大图来保质量。移动端设备屏幕尺寸窄玩家很难注意到贴图细节的差异但内存爆掉导致的闪退和加载慢是直接影响体验的。还需要留意光照贴图跟AssetBundle的加载关系。如果你用Addressables或AssetBundle做资源管理要将光照贴图Assets与对应场景放在同一个Bundle组里确保加载场景时贴图一起加载进来离开场景时一起卸载掉。光照贴图是不允许跨场景共享的两个场景如果都需要同样一张Lightmap只能各自烘焙各自用这一点容易踩坑。4.4 从“能跑”到“跑得漂亮”适度增益AO与颜色微调烘焙出基础光影之后想让画面更有立体感可以额外叠加一层环境光遮蔽贴图。AO说白了就是物体接触彼此的区域画上一层淡淡的暗色阴影让墙角、桌底这些地方更有“落地感”。在Unity里可以用Amplify或ShaderGraph做一个简单的叠加运算也可以在烘焙阶段用第三方的Bakery等工具直接生成AO信息并写入Lightmap。如果你项目里能接受第三方工具Bakery这种基于光线追踪的GPU光照烘焙器比Unity自带的Progressive Lightmapper快不说烘焙质量和高光处理也更强移动端项目用得很广。不过它需要单独花钱买并且对美术的调参能力有一定要求。从零铺设的时候还是先学会自带的烘焙再考虑进阶方案。还有个颜色微调的小技巧在Lighting窗口Environment选项卡里可以调整烘焙时的环境光颜色和环境光强度。适当把环境光压暗一点能让烘焙出来的光影对比度更强烈画面不那么“平”。很多项目只调灯光不调环境光烘焙出来的效果总感觉少点层次就是环境光设置太亮把层次吃掉了。5. 几套移动端推荐预设参数直接抄作业聊了这么多最后给几套可以直接套用的参数组合都是我在移动端项目里实测过比较稳的方案。第一套是“低配保帧”档适合百元机、骁龙6系这类设备。Lightmap Resolution设8Direct Samples 16、Indirect Samples 32、Environment Samples 16Max Lightmap Size 512Lightmap Padding 2Compress Lightmap开启。这套参数烘焙速度快包体小画面会有轻微糊感但整体完全可玩。第二套是“均衡画质”档适合当期中端机型。Resolution设16Direct Samples 32、Indirect Samples 64、Environment Samples 32Max Lightmap Size 1024Padding 4开启Compress Lightmap。这套是我最常用的一套大多数移动游戏可以无脑用这套起步。第三套是“旗舰画质”档适合在高端机上追求画面表现。Resolution设32Direct Samples 64、Indirect Samples 128、Environment Samples 64Max Lightmap Size可以来到2048Padding 8。注意这套生成贴图数量和体积都会上去如果包体敏感就换成512x512的图集策略光靠提高采样数也能明显改善光影平滑度。各套参数之间不是孤立选项改任意一个都可能影响整体效果。我建议确定一套参数后至少在一个完整关卡上跑通全流程再确认下来不然每个场景各调各的后期维护会非常痛苦。6. 一些经验总结与后续优化方向最后再分享一点我这几年做移动端渲染优化的体会。光照烘焙这个东西第一次接触的时候你会觉得它“不就是点一下生成吗”实际上决定它好坏的恰恰是前面那些容易被忽视的准备工作模型UV合不合理、场景静态标记对不对、灯光模式有没有分清楚、采样参数是不是匹配项目目标。准备工作做得越细后面烘焙越省事出问题的概率也越低。从优化发热的角度来看我一直建议大家把光照烘焙放到优化清单的前三位。原因很简单它是少有的能同时兼顾降温、画质、高效开发三件事的方案。你不需要牺牲太多画面表现不需要写复杂的Shader也不需要在每个帧率档位之间反复调教只要把光照从“每帧实时算”变成“提前算好存起来”GPU的隐形负担就被搬走了大半。如果你的项目还没做过光照烘焙可以先拿一个小型室内场景试试水调一调参数感受下效果。烘焙之后拿真机跑一跑用Profiler看一眼耗时再摸一下机身的温度这个对比是非常直观的。后续如果还想继续压功耗可以在这个基础上配合遮挡剔除、LOD、纹理压缩这些手段继续往下挖每一次省出来的性能预算都会变成更高帧率或者更精致的画面品质。