企业官网建设流程全解析

最近在群里聊起手机发烫这个话题，我发现很多朋友第一反应是锁帧率、降画质、换散热背夹，这些办法不能说没用，但都是在“事后补救”。真正高效的思路其实是在渲染源头把开销降下来，而光照烘焙就是这个系列里我最想推荐的一招。它省下的不是某个小模块的电，而是整个实时光照链路里那一大块GPU计算量，效果比简单拉低分辨率来得明显得多，对画面观感的影响又小得多。这篇就把它彻底讲透。

如果你正在做移动端游戏或者重度交互项目，又碰上手游玩几分钟机身就开始温吞吞地发热、帧率一路下跌，那这篇文章就是给你准备的。我会先解释发热跟渲染管线之间的关系，再拆解光照烘焙为什么能降温，然后给出一套Unity里的实操配置，最后把常见的翻车现场和排查方法都盘一遍。

1. 发烫的本质：实时渲染在烧你的GPU

1.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 和几款常见降温方案横向比一比

为了帮你更直观地感受光照烘焙的“性价比”，我把几类常见的降温手段放到一起做了个对比。这里用“性价比”不是指花钱，而是指获得同样降温效果时你付出的画质代价和开发成本。

先说降分辨率。这个方案确实立竿见影，把渲染分辨率从1080P降到720P，GPU负载直接砍掉一大半，但代价是画面发糊，尤其文字和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 UVs，Unity会自动生成一套不重叠的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往上提到20，Enable 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设8，Direct Samples 16、Indirect Samples 32、Environment Samples 16，Max Lightmap Size 512，Lightmap Padding 2，Compress Lightmap开启。这套参数烘焙速度快，包体小，画面会有轻微糊感，但整体完全可玩。

第二套是“均衡画质”档，适合当期中端机型。Resolution设16，Direct Samples 32、Indirect Samples 64、Environment Samples 32，Max Lightmap Size 1024，Padding 4，开启Compress Lightmap。这套是我最常用的一套，大多数移动游戏可以无脑用这套起步。

第三套是“旗舰画质”档，适合在高端机上追求画面表现。Resolution设32，Direct Samples 64、Indirect Samples 128、Environment Samples 64，Max Lightmap Size可以来到2048，Padding 8。注意这套生成贴图数量和体积都会上去，如果包体敏感就换成512x512的图集策略，光靠提高采样数也能明显改善光影平滑度。

各套参数之间不是孤立选项，改任意一个都可能影响整体效果。我建议确定一套参数后，至少在一个完整关卡上跑通全流程再确认下来，不然每个场景各调各的，后期维护会非常痛苦。

6. 一些经验总结与后续优化方向

最后再分享一点我这几年做移动端渲染优化的体会。光照烘焙这个东西，第一次接触的时候你会觉得它“不就是点一下生成吗”，实际上决定它好坏的，恰恰是前面那些容易被忽视的准备工作：模型UV合不合理、场景静态标记对不对、灯光模式有没有分清楚、采样参数是不是匹配项目目标。准备工作做得越细，后面烘焙越省事，出问题的概率也越低。

从优化发热的角度来看，我一直建议大家把光照烘焙放到优化清单的前三位。原因很简单，它是少有的能同时兼顾降温、画质、高效开发三件事的方案。你不需要牺牲太多画面表现，不需要写复杂的Shader，也不需要在每个帧率档位之间反复调教，只要把光照从“每帧实时算”变成“提前算好存起来”，GPU的隐形负担就被搬走了大半。

如果你的项目还没做过光照烘焙，可以先拿一个小型室内场景试试水，调一调参数感受下效果。烘焙之后拿真机跑一跑，用Profiler看一眼耗时，再摸一下机身的温度，这个对比是非常直观的。后续如果还想继续压功耗，可以在这个基础上配合遮挡剔除、LOD、纹理压缩这些手段继续往下挖，每一次省出来的性能预算都会变成更高帧率或者更精致的画面品质。