说个我最近真实碰上的场景。项目里同一个战斗场景在PC编辑器里跑得好好的稳稳一百多帧打包到安卓旗舰机上帧率直接掉到二十出头UI还一卡一卡的。团队里刚开始接触移动端优化的同学第一反应就是代码一模一样凭什么移动端这么拉胯这个问题几乎每个从PC转Unity移动端的开发者都会问一遍。说“凭什么”之前得先搞清楚一件事移动端和PC虽然都叫“跑游戏”但底层那套东西完全不是一回事。这篇是《Unity 卡顿·帧率保卫战》系列的第二篇咱们不聊虚的直接拆开“同样的代码性能差距为什么这么大”这个问题的底层原因顺带把我自己踩过的坑和实测方法都摆出来。这篇内容适合正在做Unity项目优化的开发者、准备从PC端转向移动端的人以及被线上卡顿问题折磨到秃头的同学参考。1. 先搞清楚一件事移动端的“瓶颈墙”到底长什么样1.1 不是你代码不行是硬件底牌差了好几个量级同样的代码之所以性能差距巨大最直接的原因是硬件本身就不是一个物种。PC端的CPU通常有4到8个高性能大核单核频率动辄4GHz以上整机功耗可以跑到几十瓦甚至上百瓦而移动端手机SoC虽然宣传“八核”但绝大多数是134或者1232这样的大小核架构真正能干重活的大核可能就一两个而且为了控制发热和功耗频率还经常被限制在2.5GHz到3.2GHz之间。整个手机平台的持续功耗大概只有5到10瓦这个数字连一颗PC桌面级CPU的零头都不到。GPU差距就更夸张了。PC上的独立显卡功耗几百瓦显存带宽动辄几百GB/s移动GPU和CPU做在同一颗SoC里没有独立显存和系统共享内存带宽通常也就几十GB/s的级别。这就意味着同样一个复杂的Shader在PC上可能毫秒级完成到了移动端就会被带宽卡脖子。这里有一个非常典型的例子一次全屏后处理模糊效果在PC上需要从显存里反复读写整张屏幕纹理显存带宽高所以毫无压力但在移动端GPU要反复访问同一片内存区域带宽瞬间吃满帧率直接腰斩。所以你在PC上做品质验证时觉得很流畅的效果搬到移动端会变得很吃力这非常正常。1.2 功耗散热移动端最容易被忽略的“隐形降频”很多团队在优化时只盯着CPU占用和GPU渲染时间却忽略了一个移动端独有的变量散热和降频策略。PC机箱里风扇呼呼转散热器压得住手机没有任何主动散热长时间高负载运行后机身温度升高系统就会强制降频来保护硬件。你会发现同一台手机刚开机时能跑满帧率玩五分钟之后帧率就开始往下掉这不是你的优化变差了是芯片在“自我保护”。我做项目时遇到过一种情况在Profiler里看单帧CPU耗时并不高但真机上就是掉帧。后来盯着温度数据才发现是长时间运行后芯片降频导致的。所以移动端性能测试必须做“持续热跑”不能只跑一两分钟至少要跑15到30分钟记录帧率和温度曲线才能看到真实表现。下表是我整理的一个粗略对比方便直观感受两者的差距项PC平台移动平台CPU典型功耗65W 200W以上2W 8WGPU架构独立显卡Immediate Mode集成在SoCTile-Based显存/内存带宽数百GB/sGDDR6几十GB/sLPDDR存储读取速度NVMe SSD可达数GB/sUFS持续读写易降速散热能力主动风扇/水冷被动散热持续性能受限典型帧率目标60 240fps30 60fps看到这你应该明白移动端的底层资源比PC紧张得多所以同样的代码表现差距巨大本质是硬件资源不匹配造成的。接下来我们深入渲染层面看移动GPU的工作方式差异。2. 渲染层面的巨坑移动GPU和PC GPU根本不是一种工作方式2.1 从即时光栅化到Tile-Based移动GPU为什么这么设计PC GPU普遍采用Immediate Mode RenderingIMR简单理解是“现场直出”CPU提交一个三角形GPU立刻处理、光栅化并写入帧缓冲区整个过程直接。这种模式适合性能强劲、带宽充足的硬件环境。移动GPU则几乎全是Tile-Based RenderingTBR或Tile-Based Deferred RenderingTBDR常见于高通Adreno、ARM Mali、苹果自研GPU。TBR的工作方式是把屏幕划分成一个个小块Tile通常是16x16或32x32像素先在片上高速缓存里完成每个Tile的几何处理、光栅化和着色等这个Tile全部处理完才把结果一次性写回主内存。这么做的核心目的是省带宽、省功耗——PC可以豪爽地频繁读写显存移动端必须精打细算因为每次访问内存都要付出功耗代价。这个架构差异对性能的影响极其深远。在PC的IMR架构下如果一个像素被反复绘制多次每次绘制都层层往上盖可能只是浪费一些着色计算但在移动端TBR架构下Overdraw过度绘制不仅浪费计算还可能导致Bandwidth带宽压力激增。因为有些GPU实现中每个Tile内部要处理的片段越多片上的负载就越大超出后还得打回主内存性能会断崖式下跌。所以我一直强调一个问题移动端性能优化Overdraw是绝对的敌人。2.2 Overdraw为什么在移动端一碰就炸Overdraw简单说就是一个像素在一帧内被重复绘制的次数。PC上轻微Overdraw几乎无感移动端则会非常敏感。我曾经接手过一个项目PC端测试时特效全开满屏粒子平均帧率70多到手机上帧率只有15到20。后来用RenderDoc抓帧分析发现粒子系统的半透明混合层层叠加一个像素被绘制了十几遍画面的Overdraw峰值达到了夸张的15左右移动GPU直接卡死在带宽上。当时优化的方法是三个方向同时下手一是把粒子发射器的渲染层级拆开减少重叠区域二是把部分全屏粒子改为Shader里用圆形遮罩绘制减少混合层的实际覆盖面积三是开启Unity的Frame Debugger逐个检查DrawCall对应的Overdraw区域把多余的全屏半透明特效直接砍掉。改完后真机帧率恢复到了45以上不能说满血复活但至少能玩了。实操建议用Unity的Frame Debugger查看单个DrawCall时可以开启Overdraw视图Scene视图左上角的着Draw Mode选Overdraw用颜色渐变判断哪里绘制次数最多。色调越白、越亮的地方就是Overdraw的重灾区。移动端的目标是平均Overdraw尽量控制在2倍以下复杂场景也尽量别超过3倍。2.3 纹理压缩格式一个全屏纹理读取到底要花多少钱纹理带宽是移动端另一大开销。PC显卡直接支持DXT/BC系列压缩纹理读取时带宽占用小移动端不同GPU平台对纹理压缩格式的支持五花八门最稳妥的选择是ASTCAdaptive Scalable Texture Compression它是主流移动GPU都支持的标准格式压缩率可以灵活调整从4x4到12x12块大小块越大压缩率越高但画质损失也越高。这里用数据说话。一张1024x1024的RGBA8未压缩纹理占用内存约4MB读取一次到GPU要搬约4MB数据如果转成ASTC 6x6内存占用大概0.9MB读取带宽成本直接降到原来的四分之一左右。别小看这个数字场景里几十张贴图每帧都会被Shader反复采样累计起来的带宽差别非常可观。纹理格式位宽每像素1024x1024占用移动端兼容性RGBA32未压缩32bit4MB所有平台支持ETC24bit 8bit0.5MB 1MBOpenGL ES 3.x强制支持但画质一般ASTC 4x48bit1MB主流移动GPU广泛支持ASTC 8x82bit0.25MB主流移动GPU广泛支持DXT/BC4bit 8bit0.5MB 1MBPC显卡友好移动端兼容性较差需要注意在Unity中纹理压缩格式需要在导入设置里按平台分别设置。PC平台保留BC7格式保证画质Android/iOS平台统一设置ASTC。很多人图省事直接把纹理设为RGBA32或DXT结果移动端要么内存暴涨要么GPU根本不支持最终全走CPU解码性能自然崩。3. Shader和API移动端的隐形税你交了没3.1 浮点精度highp、mediump、lowp的取舍PC GPU的Shader里默认用32位浮点float跑得飞快移动GPU为了省功耗通常支持半精度16位浮点half甚至定点数fixed。Unity shader里常见的float、half、fixed在移动端有完全不同的性能待遇。但很多人的误区是“把所有的float改成half就能提速”。实际上在某些移动GPU上half的运算单元是单独设计的处理半精度向量确实比全精度快但如果你的数据超出了半精度的表示范围指数范围大概±65504精度约3位小数就会出现精度撕裂、闪烁、颜色断层甚至黑块。而且部分旧架构对half运算还要“反转义”处理反而更慢。所以正确的做法是在片元着色器里颜色、UV、法线等对精度要求不高的数据用mediumphalf或lowpfixed世界坐标、大范围距离、深度计算等必须用fullpfloat不要一刀切。3.2 动态分支在移动端的代价比你想的更高在PC上GPU的着色器里写if分支只要分支收敛得当性能影响不大移动GPU为了压面积和功耗很多不支持或低效支持动态分支部分架构会对分支内的所有路径都执行一遍再选结果这意味着你的“优化分支”反而变成了性能毒药。所以移动端的Shader里尽量用lerp、step、saturate这类数学函数来替代动态分支如果确实需要分级效果可以用#if这种变体开关做静态分支让编译器在编译期就决定好走哪条代码路径而不是在运行期做判断。3.3 API层面的差距OpenGL ES、Vulkan、Metal与DX11PC端游戏大多跑在DirectX 11/12上特性的上限很高移动端主流是OpenGL ES 3.x、Vulkan、Metal。这些API在着色器指令数、纹理单元数量、Uniform上限、RenderTarget格式支持上都有各自限制。Unity的Built-In渲染管线里写一个在PC上效果华丽的Shader可能Fog、Lightmap、Shadow等多个Pass塞进去编译到OpenGL ES 3.0后容易超过指令数限制甚至直接编不过。所以移动端项目我建议尽早切换到URPUniversal Render Pipeline它的SRP Batcher设计就是冲着合批和降低DrawCall去的Shader有标准化的Lit/Unlit模板复杂度可控对移动端的生态适配也好很多。另外注意移动端不建议开太多实时阴影和多Pass效果前向渲染下每多一个Pass就意味着场景里所有相关物体都要多画一遍这比PC端的代价大多了。4. 代码逻辑层的隐形杀手DrawCall、批处理和GC4.1 移动端DrawCall的“真实成本”PC端的驱动和CPU性能允许你在Editor里跑上千个DrawCall移动端可不行。每个DrawCall从CPU提交到GPU执行要经历状态切换、驱动校验、指令缓存刷写等流程这部分CPU开销在移动端比PC高得多。我见过很多项目PC上200个DrawCall轻轻松松跑满60帧到手机上200个DrawCall直接CPU卡死帧率上不去。具体操作上Unity的Profiler里能看到Batches和SetPass Calls两个指标移动端的优化目标一般建议普通场景DrawCall控制在100到200之间复杂场景也不要轻易超过300。要压DrawCall优先检查是否有大量未合并的材质、交错的网格渲染顺序以及动态光照导致的额外Pass。4.2 动态批处理为什么在移动端经常“失灵”Unity的动态批处理在很多场景下会自动合批但它的限制并不少物体顶点数要少通常小于900顶点、材质必须相同、Shader一致而且一旦有缩放非1的物体、旋转的半透明物体、或者光照方向不同合批就会被打破。移动端Shader更复杂多Pass、变体多动态批处理很容易失效。更靠谱的方案是GPU Instancing静态物体和SRP BatcherURP下动态物体。特别是SRP Batcher它不要求网格相同只要求Shader兼容能大幅降低CPU侧的SetPass开销。如果你还在用Built-In管线又不想换那就尽量把同材质物体放进一个“材质球”然后调整渲染队列让相同材质的东西连在一起提交。4.3 别忽视GC Alloc移动端的“小卡顿”元凶在PC上偶尔一次的GC垃圾回收停顿可能只有几十微秒玩家毫无感觉移动端CPU性能弱内存管理更加敏感频繁的GC Alloc会造成明显的帧尖峰Frame Spike表现就是画面一顿一顿的。尤其是一些低频但批量的分配会在某几帧集中触发GC让帧率忽高忽低。我排查项目时最关注的几个GC源头Update里字符串拼接Debug.Log、UI文本更新、Linq操作、foreach在旧版Mono上的装箱、GameObject.Find等查找操作、频繁创建临时List/数组。优化思路很简单循环内不要做字符串拼接提前用StringBuilder查找和缓存对象引用不要每帧Find临时集合用对象池或复用静态数组能用TryGetComponent就别用GetComponent。这些改动单看都不起眼合起来对移动端帧率的稳定帮助巨大。5. 实战排查用Profiler和Frame Debugger找出卡顿根源5.1 不要只盯着Editor里的Profiler我一直强调一个原则Unity编辑器里的性能数据没有任何“移动端参考价值”。编辑器运行在PC CPU上GPU也是PC显卡跑的是DX11不是你手机上的OpenGL ES/Vulkan。所以在移动端项目里做性能调优至少要做到以下几步用Android真机连接开启Development Build和Autoconnect Profiler通过adb连接Unity Profiler观察CPU耗时。用Unity Profiler的CPU Usage模块勾选Player Loop重点看Update、LateUpdate、Animation、Physics、UI等关键流程各自占用的毫秒数。GPU侧时间可以在Frame Debugger里看或者用手机厂商的GPU性能分析工具比如高通的Snapdragon Profiler、ARM的Mali Offline Compiler。一定要测多台不同档位的真机覆盖高、中、低三档而不是只信顶配旗舰机的表现。5.2 Frame Debugger的实用排查链路Unity自带的Frame Debugger是一个极好用的工具打开Window Analysis Frame Debugger可以逐帧回顾每个DrawCall的执行情况。排查合批失效的时候我习惯用它看三个关键信息第一个是当前DrawCall的Shader Pass数量很多物体一旦出现额外Pass比如阴影、描边合批就断了第二个是看Override的渲染队列同材质物体如果被不同渲染队列插队批处理也无法合并第三个是确认有没有动态阴影之类的额外渲染步骤插在其中。举个例子我接手过一个UI卡顿问题表现为打开商城界面的时候特别卡。用Frame Debugger一看商城界面的一个ScrollView里几十个按钮每个按钮都带了自己的阴影和图集外单独纹理导致DrawCall直接飙到400多而且中间还混着大量SetPass calls切换。后来把图集集中整理、阴影改为Shader内生成DrawCall压到60左右帧率马上稳了。5.3 一个“PC流畅但移动端卡”的完整排查案例我拿一个典型的RPG战斗场景来说明排查思路。这个场景在PC上稳定120帧真机上只有22帧。我的排查步骤是先判断瓶颈在CPU还是GPU用Profiler的真机连接发现CPU耗时并不高单帧CPU大概12毫秒说明不是逻辑脚本拖慢但帧率依然60帧不到于是判断大概率是GPU Bound或带宽 Bound。降低分辨率测试把屏幕分辨率降到原来的70%Scale 0.7帧率立刻提到35帧。这一步基本可以确认瓶颈在GPU或带宽而不是DrawCall和脚本逻辑。再砍后处理和Overdraw关掉Bloom后处理帧率从35提升到42把粒子特效的数量减半帧率到了50。此时候发现场景里的粒子系统和泛滥的半透明重叠才是首要问题。检查纹理和带宽用Profiler的Memory和GPU模块看带宽占用发现大量角色贴图用的是RGBA32未压缩格式改ASTC后帧率又提升了5到8帧。最终组合拳开SRP Batcher调阴影距离优化粒子发射参数最终真机稳定到了60帧边缘。这个排查链路的核心思路是先确定瓶颈层再用排除法缩小范围。别一头扎进代码里抠细节那是盲人摸象。6. 优化落地的优先级先改什么后改什么6.1 先定目标帧率和目标机型做优化前第一件事是拉上项目组定两个问题目标帧率是多少60还是30最低支持的手机型号是什么以哪台机器作为最低基准。乐观地说市面上任何一台手机都能跑Unity但能在中低端机上稳定60帧的项目优化量可能足足差出一个数量级。所以不要盲目追求“所有机型60帧”这个目标大概率不现实最终只会把自己逼疯。6.2 我的优化顺序表按性价比排序基于这些年的项目经验我一般按下面的顺序做优化收益从高到低优先级优化项预期效果1目标分辨率和MSAA直接砍掉GPU像素填充压力2后处理特效和Overdraw降低带宽消耗效果立竿见影3实时阴影的距离/分辨率减少额外Pass和阴影计算4纹理压缩格式ASTC/ETC2降低内存和带宽占用5粒子特效和UI层级合并减少DrawCall降低合批断层6代码GC分配和脚本性能消除帧尖峰让帧率更稳定7模型面数和动画复杂度降低CPU骨骼和GPU顶点处理压力8LOD和遮挡剔除减少远处/不可见物体的渲染成本实操细节上有几个硬性规约我建议项目里直接定下来所有移动端纹理导入默认ASTC 6x6或根据画质分级用4x4/8x8违例在CI上直接报错。每帧的GC Alloc目标控制在1KB以内用Profiler盯一段时间谁超标就改谁。UI系统最大DrawCall设一个阈值比如120超了就审查图集和层级。不开MSAA时优先用TAA或FXAA替代别动不动开4x MSAA。6.3 性能预算的“口袋笔记”我自己的习惯是给项目定一张“性能预算表”像个口袋笔记一样贴在团队Wiki里。举例单帧CPU总预算16.6ms60fps其中渲染管线占8ms动画2ms物理1msUI 2ms脚本3ms单帧GPU总预算16.6ms其中Overdraw控制2倍DrawCall 150内后处理不超过3个全屏Pass。每当有人新加特效或新场景就用这个预算表去审核。加了就得从别处扣预算用超了就不能上线。这个办法比“感觉差不多”要靠谱得多。我个人在实际操作中的体会是移动端优化的“差距感”其实有个分层逻辑最底层是硬件资源差异决定你天花板在哪中间层是渲染架构差异决定你踩坑方式的独特性最上层才是代码写得好不好决定你能在这个天花板下压榨出多少性能。很多团队一上来就怀疑自己Shader写得有问题或者脚本写得烂优化半天效果却不明显其实是因为前面两层底子没打好。最后再分享一个小技巧给你的项目找一台“基准测试机”选项目支持的最低端真机。每次在PC上做完一个功能习惯性地打到这台手机上跑几分钟看看Profiler里的指标有没有跌破红线。守住这台机器的帧率整个项目就不会失控。这个主题其实还能往下挖很多比如Vulkan和Metal下的底层优化、GPU Instancing实例化上限怎么计算后面有机会再展开聊。