同样的代码、同一个场景在PC上跑出120帧打包到手机上直接卡成20帧这不是大家技术不行而是移动端和PC之间的差距本来就是一条巨大的鸿沟。很多团队在做Unity项目时习惯先在PC上开发调试等真机测试才发现性能完全撑不住这时候再回头改成本往往是写代码时的好几倍。这篇内容就来拆一拆同样的Unity代码为什么在移动端和PC上表现差距这么大以及面对移动端卡顿和帧率下降到底应该从哪里下手查、怎么改才有用。如果你是做独立游戏、小团队上线、或者刚开始接触Unity移动端性能优化的开发者这篇文章给的思路和排查清单可以直接照抄。已经有一段时间工作经验的开发者也可以借此系统梳理一遍自己的性能优化流程。1. 移动端和PC的差距从芯片设计那天就决定了很多人以为移动端性能差只是因为“手机比电脑便宜”实际上远不止如此。移动端芯片和PC芯片走的是两条完全不同的设计路线这个差异从底层硬件上就决定了你再怎么优化代码也不可能让手机追平台式机的性能。1.1 CPU一个是高功率猛兽一个是低功耗精算师PC的CPU以Intel和AMD的桌面处理器为例单核跑上5GHz是常态功耗可以放开到65瓦甚至上百瓦。而手机SoC里的CPU大核能跑到3GHz左右就已经算很激进而且整个SoC的功耗预算通常只有5到10瓦。这就意味着同样是一条加法指令PC处理器在单位时间里能执行的次数是手机处理器的倍数级差距而且它还能用更高的功耗去维持这个频率。更关键的是指令流水线的深度。桌面CPU有条件做非常深的乱序执行、分支预测、大容量的多级缓存这些都会让高频代码跑得更顺畅。但手机的ARM架构为了省电往往采用更保守的顺序执行或者轻度乱序设计遇到复杂的分支逻辑、密集的函数调用、链式指针访问性能下降比PC严重得多。Unity的主线程本身就是逐帧执行的密集逻辑一旦代码里出现大量函数调用、属性访问、反射移动端CPU就会明显吃力。有实测项目的数据可以参考一个包含大量角色AI逻辑的Unity场景在PC上一只单位每秒更新1000次骨骼相关的Transform访问主线程占用只有0.5毫秒左右放到中端手机上同样的逻辑可能要占到4到6毫秒。如果要求保持60帧每帧只有16.6毫秒的预算这一项就吃掉了三分之一以上。1.2 GPU桌面大核与移动端Tile架构的路线之争GPU这边的差异可能比CPU还大。桌面显卡比如NVIDIA和AMD的独立显卡采用的是Immediate Mode Rendering即时模式渲染每一帧的直接绘制命令尽量立刻执行显存带宽动辄几百GB每秒所以它可以肆意地在屏幕上画三角形、做复杂的后处理。移动GPU的主流架构则是Tile-Based Deferred Rendering基于瓦片的延迟渲染先把一帧分成一块块小区域在片内完成大部分计算再把结果写回内存这样做的好处是极大节省带宽和功耗但对Unity项目的渲染方式提出了很多特殊要求。举个例子在PC上随便用一个GrabPass去抓屏幕图像或者频繁切换RenderTarget做后处理显卡帧率可能纹丝不动。在移动端每一次从当前Tile写到全局内存再读回来代价都高得吓人。很多在PC上无所谓的操作搬到手机上就变成了帧率杀手这就是典型的“同样的代码移动端跑不动”的根源之一。另一个隐藏很深的差异是半精度浮点运算。移动端GPU普遍原生支持fp16的快速运算而PC显卡的fp32性能则强得多。Unity默认Shader在PC上跑的是fp32精度直接跑到移动端很多中低端GPU并不能发挥出位宽优势运算速度自然会下降。很多做过移动端Shader优化的同学应该都见过强制加half修饰符之后帧率立马上来的案例。1.3 散热与功耗压死骆驼的最后一根稻草功耗和散热是移动端永远绕不开的天花板。PC的性能释放可以持续半小时一小时不掉频但手机连续跑大型游戏十分钟后机身温度上升SoC就会主动降低频率也就是通常说的降频。核心频率一下降帧率立刻从稳定60掉到40甚至更低这个变化往往是瞬间发生的你在Profiler里看到的就是一帧突然卡了很久。这就是为什么移动端性能测试必须上真机而且必须跑足够长时间。很多团队在PC上测试十分钟觉得没问题真机上跑了一小会儿就剧烈卡顿其实就是降频机制在起作用。所以移动端优化有一个不成文的规矩超过平均性能的优化都是耍流氓凡是超过一定时长的发热控制都要考虑进去。2. Unity运行时同样的代码在两端走了完全不同的路径理解了硬件差异再来看Unity在运行时做的一系列底层处理。同样的项目因为平台不同绘制流程、Shader编译、纹理格式都可能走不同的分支这个分支差距直接决定了最终渲染效率。2.1 渲染管线移动端的每一个像素都“很贵”先说绘制调用Draw Call。在PC上因为显卡带宽足够、CPU性能强一两百个Draw Call对帧率的影响通常不大。移动端则不然每一次Draw Call除了本身提交命令的开销还涉及状态切换、顶点数据上传中低端手机对高频Draw Call非常敏感。同一个场景100个Draw Call在PC上很轻松手机可能直接占满一帧的耗时。所以移动端项目对合批的依赖远高于PC端。Static Batching、Dynamic Batching、GPU Instancing这些技术在PC上属于“能开就开”在移动端则是“不开就等着卡顿”。我见过不少项目在PC上合批和不合批帧率看不出来一到真机就掉一半帧率就是这个原因。还有Overdraw也就是同一像素被重复绘制的次数。PC像素填充率高多画两层UI、几张半透明特效影响相对可控。移动端的填充率限制严格一旦半透明粒子、面片太多GPU的片元着色器负载猛增主循环哪怕CPU很空闲也跑不到60帧。这也是为什么移动端项目经常限制同屏粒子数量、推荐用不透明Shader模拟透明物体。2.2 Shader与精度一个half可能救回一半帧率Unity在打包Shader时会根据目标平台做精度裁剪。PC平台默认会尽量使用高精度移动端则需要在Shader代码里手动指定half还是float来决定精度。经常有人写Shader时图省事全部用float到了移动端精度浪费不说性能直接被打骨折。具体来说移动端GPU对half类型运算速度远快于float尤其像Adreno和Malifp16的吞吐量通常是fp32的两倍以上。在Shader中把不需要高精度的变量、中间计算改为half经常能获得10%到30%的性能提升。但在PC上GPU的fp32本身性能极强改half反而可能引入精度造成的画面异常这就是“同样代码两端表现不同”的另一种典型。再一个深坑是Shader的动态分支。PC显卡对动态分支处理得好跑起来非常快但移动GPU在分支不统一的时候反而会出现严重性能回退。也就是说Shader里加一个if判断在PC上无关痛痒在移动端可能比多画一张全屏贴图还贵。移动端Shader要尽量避免依赖运行时分支可以拆成多个变体让引擎自己选。2.3 纹理格式与内存带宽压缩格式选择直接影响加载和采样纹理格式也是移动端必须特殊对待的环节。PC上常用的BC格式纹理在移动端支持度很差真机通常用ASTC或ETC2。如果项目没做纹理格式转换Unity会自动在真机上做兼容处理内存占用量会飙升GPU采样带宽也会恶化。举个例子一张1K乘1K的RGBA32纹理未压缩时约4MB在PC上无所谓手机上可能同时加载几百张贴图内存压力立刻上来。换成ASTC 4x4之后同样的贴图大约1MB显存占用和加载时间大幅下降采样带宽也低很多。很多移动端项目所谓“卡在加载场景”的问题有时只是纹理格式不对导致GPU采样效率低。内存带宽是最容易被忽略的一项。移动端的内存带宽相比PC差出好几倍如果场景里大量使用高分辨率纹理、频繁读取大片数据即使GPU算力够带宽也会成为硬瓶颈。这也是为什么移动端推荐纹理不要超过一定尺寸上限并且尽量使用压缩格式的原因。2.4 后处理特效PC的甜品移动端的毒药后处理在PC上是提升画面质感的常用手段抗锯齿、泛光、景深、色调映射随便加帧率几乎不掉。但移动端的后处理每一个全屏Pass都需要对屏幕纹理做一次读写对Tile-Based架构来说就是反复在片上内存和全局内存之间搬数据代价极其昂贵。真正面向移动端的项目要么放弃全屏后处理要么用极轻量的方案代替抗锯齿建议用MSAA代替全屏抗锯齿、泛光改为自适应阈值附近的简单Bloom而不叠加多层模糊、景深干脆不启用。我见过把PC上全套后处理直接搬到手机的团队结果帧率从60直接掉到20砍掉一半后处理之后又恢复到了50多帧。这就是移动端优化的最大现实画面效果要妥协到硬件能接受的范围。3. CPU端的隐藏开销帧率卡顿真正的大头往往在“看不见”的代码里很多人遇到卡顿第一反应是“画面太精致了、需要减面、降低分辨率”但真到了Profiler里一看会发现最耗时的其实是CPU端的逻辑代码。移动端CPU性能弱逻辑上的开销会被放大得非常明显有一类卡顿在PC上完全感受不到到了手机上就变成常态。3.1 主线程忙碌Transform、物理、UI的连锁反应Unity的主线程是游戏逻辑的大总管每一帧要处理Update、物理、动画、UI布局、渲染提交等一系列任务。一旦主线程上有太多同步操作比如频繁读写Transform、在每个Update里创建新物体、在循环里做字符串拼接移动端CPU就会忙不过来。一个常见例子是大量UI元素每帧刷新文本内容。Text组件设置字符串底层会触发重建网格这个操作在PC上也就是零点几毫秒但在手机上一屏UI同时刷新二三十个文本可能就要吃两三毫秒。如果每个文本还带阴影、描边那中文渲染的代价会更可怕。物理也是移动端CPU的重灾区。Unity默认的物理引擎是PhysX移动端跑物理模拟时碰撞检测、关节约束、连续碰撞这些计算都会占用大量CPU时间。尤其是一个场景里挂了太多Collider即使没有主动调用物理接口物理引擎每一帧也会对所有碰撞体做Broadphase检测。PC上挂几千个Collider很轻松移动端几百个就已经有明显压力了。3.2 内存分配与垃圾回收帧率下降的“隐形刺客”另一个让移动端帧率出现明显抖动的元凶是堆内存分配和GC。PC上内存分配快、GC触发频率低、暂停时间短所以哪怕代码写得随意一些用户也不容易感受到卡顿。移动端堆内存相比PC小很多如果每帧都new对象、装箱、拼接字符串很快内存就会告急GC会频繁触发而且是完整暂停式的回收一停就是几十毫秒甚至上百毫秒画面直接卡住。用Profiler观察时会发现帧时间曲线很平稳但每隔一两秒出现一个很高的尖峰多半就是GC在作怪。在PC上这种尖峰可能只有几毫秒用户基本感知不到但在移动端可能持续几百毫秒表现为明显的卡顿和掉帧。解决方案其实都是Unity社区的老生常谈避免热循环内分配、用对象池管理频繁创建销毁的物体、用StringBuilder避免字符串拼接、避免在Update里LinQ查询、用结构体减少引用对象数量等等。但这些在PC上“做了更好”在移动端是“不做就卡给你看”的级别的差异。3.3 批处理合并的“坑”你以为合了其实没有批处理的原理是合并多个物体到一个Draw Call但在移动端合批本身也不是免费的。动态合批需要CPU额外做顶点数据拼接和变换这个计算在PC上可以忽略在手机CPU上就可能得不偿失。如果项目里物体又小又多动态合批的CPU开销高于节省的Draw Call帧率反而更差。静态合批也有自己的代价合批之后的内存占用更高因为合批网格是独立的一份数据而且合批的物体不能单独做移动或者缩放否则Unity会自动断开合批导致原有效果没了。移动端项目经常出现“规则一动不动的时候帧率很好物体一变帧率就掉”的假象其实就是合批状态在反复变化。这就要求移动端开发者在做批处理前先掂量一下CPU的开销和GPU节省之间到底值不值。通常建议是小物体多优先用GPU Instancing大物体考虑静态合批持续的动态物体用对象池配合层级细节简单化不要指望简单的开关能解决所有问题。4. 帧率保卫战实操从定位瓶颈到真正解决问题讲到这很多同学会问我知道移动端这么容易卡那到底怎么定位自己项目里最该优化的那一步这里分享一套我常用的排查流程基本可以照搬到任何一个Unity移动端项目上。4.1 第一步先分清楚是CPU瓶颈还是GPU瓶颈拿到一个卡顿问题不要急着瞎改先确定瓶颈在CPU还是GPU。方法很简单打开Unity Profiler跑一下真机然后分别看CPU帧时间和GPU帧时间。CPU时间约等于主线程耗时GPU时间有Hood可以在Profiler里看到或者用显卡厂商自己的工具。如果GPU时间明显大于CPU优先往渲染方向优化反过来就要优先查逻辑。但这里有一个很常见的误区有些Profiler版本在移动端拿到的GPU时间并不可靠尤其是不同引擎版本对移动GPU的Profiler支持程度不同。更直接的现场判断方式是调节画面分辨率。如果降低分辨率之后帧率明显提升那大概率是GPU瓶颈如果降了分辨率帧率不变那瓶颈多数在CPU或内存。这个土办法在排查时百试百灵。4.2 第二步盯住帧时间曲线的“尖峰”光看平均帧率没用卡顿往往出现在帧时间的不稳定上。用Profiler配合Frame Debugger看每一帧的时间分布特别留意哪些帧的耗时突然翻倍。尖峰出现的位置越集中越容易定位到具体的加载操作、GC触发、或者某个高开销的事件处理。常见的尖峰来源有这么几类首次加载资源时的异步加载回调、敌人或者新的区域生成、某个协程里突然大量实例化、UI的布局重建、音频切换场景等等。在PC上这些事件每秒一次也可以接受在移动端因为单项耗时拉长尖峰就显得非常扎眼。优化思路就是把大块的加载和生成打散到多帧执行或者用预加载和对象池把峰值抹平。4.3 第三步真机基准测试必不可少PC上的Profiler数据只能作为参考真正的决策必须以真机为准。选测试机也是有学问的不要只用顶配旗舰机测试不要只用开发者的高性能手机测试。移动端项目的目标设备应该覆盖中端主流机型因为旗舰机的性能余量太大很多问题根本暴露不出来。测试时要注意的细节同样多手机要关掉后台应用、关掉自动亮度、开启飞行模式或者连上稳定的Wi-Fi尽可能排除不确定因素。每个场景要跑至少两三轮取稳定后的帧率而不是只看开局几秒的峰值。有条件的话用厂商的开放工具获取频率和温度曲线观察长时间运行后的降频情况这是PC上永远接触不到的一类问题。4.4 第四步用统计眼光看问题而不是玄学优化做成表格对比不同场景的帧时间是定位卡顿问题最直观的方式。我一般习惯把帧时间拆成几个大块渲染耗时、脚本耗时、物理耗时、UI耗时、GC耗时等然后逐块比较。哪个块占比最大就先处理哪个。如果每个块看起来都不算大但帧时间仍然很高那么多半是隐藏的整帧同步问题比如垂直同步、命令缓冲提交太慢、或者是推流相关的等待。移动端性能优化的本质就是做预算管理。把目标帧率对应的帧时间预算摆出来然后再看每个子系统的预算占用超标就砍。这个方法在PC上也许只是“更好”但在移动端是“能不能跑得动”的分界线。5. 高收益优化动作盘点先把能拿的分数拿到手定位完瓶颈之后接下来就是动手优化。这里整理一批在移动端性价比极高的优化动作按收益从高到低排一下大家可以直接在项目里尝试。5.1 渲染设置先做减法先看项目里的Quality Settings和Graphic Settings。移动端建议使用独立的Quality Level关闭不必要的阴影和实时全局光照阴影距离缩短到一个合理的范围。同一个场景PC开高强度阴影和手机开中低强度阴影帧率能差出30%以上这算是成本最低的优化方式。抗锯齿建议优先用质量档位的MSAA而不是后处理式的TAA或者其他后期方案。如果游戏风格可以接受降低内部分辨率再配合屏幕缩放也是立竿见影的做法。这个操作在PC上几乎没有必要但在移动端可以显著缓解GPU压力尤其对一些Shader较重的场景来说效果立竿见影。5.2 材质和Shader全面瘦身把Shader中不需要的特性全部删除是移动端优化的基本功。举个例子Unity内置的Standard Shader有大量宏分支很多功能你用不到但编译出来的分支变体依然存在在某些情况下仍然会增加运行时开销。最好的方式是不用默认Standard而是基于移动端专用Shader改动或者直接用URP针对需要的能力走精简管线。Shader变体也是一个容易被忽视的点。项目里如果同时编译了多个平台的Shader变体打包体积和加载时间都会增加。用ShaderVariantCollection在移动端也能减少运行时编译卡顿。很多时候游戏进入新场景卡一下其实无非就是Shader的运行时编译和加载。5.3 资源规范要落地成工具而不是靠自觉移动端项目的资源管理必须有规范和工具链。纹理尺寸限制、网格面数上限、音频压缩格式、字体图集大小这些都应该通过资源导入设置和后处理脚本强制约束而不是靠美术手动执行约定。我做过一个项目PC时代美术很自由地拖入资源到了移动端每一次进场景都卡到崩溃最终排查后发现有大量高精度模型和未压缩纹理在场景里。后来把导入规范做成了工具打包时自动检查并转换格式帧率立刻稳定了一截。对于移动端开发来说自动化是保障优化不倒退的关键。5.4 对象池、预加载与异步加载的组合拳移动端内存紧张已经是常识所以对象的创建和销毁尽量走池化。对角色、敌人、子弹、特效这类频繁生成销毁的对象一律优先用对象池。对于场景切换优先用异步加载配合预加载策略避免在切换到新场景的瞬间做大量同步加载。还有一个容易被忽略的点资源释放。移动端不仅要关心加载还要关心不用的资源是否被及时卸载否则内存占用会不断爬升最终因为内存压力触发系统杀进程或者大GC表现就是玩着玩着突然卡死甚至闪退。AssetBundle模式的项目尤其要设置好依赖管理避免重复加载同一份资源。5.5 场景构建与管理的移动端思维同场景在PC上比较随意但到了移动端要考虑一次驻留内存里到底存在多少东西。如果场景非常大考虑分块加载如果游戏是开放世界考虑流式加载不要一整张地图全量加载。Unity的SceneManager本身不区分平台但使用时要主动体谅移动端的内存上限。另外场景里的灯光和阴影尤其要谨慎。PC上你可以放几十盏实时灯光移动端最好控制在几盏以内。实时光源数量一多移动端GPU执行forward渲染时的像素灯光开销就会成倍增长。从灯光的数量、烘焙方式、阴影距离这几个维度入手往往能让画面几乎不变的同时帧率大涨。6. 常见问题与避坑速查最后把一些大家在实际操作中经常踩的坑整理成速查表遇到类似问题时可以直接对照。现象可能原因排查/解决办法真机帧率一直上不去但不卡顿GPU或填充率瓶颈降低内部分辨率或画质设置看帧率是否提升帧率周期性尖峰每隔几秒卡一下GC频繁触发检查Profiler中GC Allocation定位高频分配代码进入新场景卡住一瞬间同步加载耗时过长改为异步加载场景切提前做预加载两个物体一靠近就掉帧碰撞体数量多、物理检测密集调整物理层减少不必要的Collider移动物体时帧率降很多动态合批失效/重建用对象池减少碎片或者改成GPU Instancing手机运行一段时间后发热降频长时间高负载适当降低画质目标加入温度控制策略使用后处理时帧率剧降移动端全屏Pass开销大减少后处理Pass数量改用轻量方案注意上面这张表适合用来快速启动排查但不代表所有问题都能一个表找到根因。你还是需要回到Profiler里做细致的拆解尤其是事件流程复杂的项目最后定位到根因的那一步往往需要来回验证多次。排查帧率问题的时候另一个容易犯的错误是一次只改一样东西。真正麻烦的是很多性能问题是由多个因素叠加导致的比如既存在过多Draw Call又有频繁的GC还有阴影开销过大单独优化任何一项帧率看起来都有好转但始终达不到目标。这种情况下最好的做法是先砍掉最明显的一项再重复测量循环迭代。还有一个建议是做移动端优化一定要有一台固定的“基准测试机”不要今天用旗舰机测明天用低端机测这样前后数据没有可比性。测试时记录帧时间、CPU占用、内存占用、温度变化这几项关键数据用数据说话优化才会更有章法。提示如果项目面向中低端机型强烈建议在开发早期就把移动端性能预算写进项目规范里。比如草地同屏不超过多少个、粒子发射器不超过多少个、单个模型三角形面数上限是多少。这些预算提前定好后续就不容易失控。说实话移动端性能优化的本质就是在硬件受限的环境里做出最合理的选择和取舍。PC端很多时候是“硬件帮你兜底”到了移动端任何一点浪费都会被放大得无比清晰。这其实也是移动端项目锻炼技术水平最好的地方因为每一个改动都能立刻看到帧率反馈逼着你把知识学到根上。
在齿轮箱故障诊断中的原理与Matlab实现)
