很多人拿到Unity项目第一件事就是开Profiler然后被密密麻麻的耗时柱子吓住再上网搜一堆“推荐设置”挨个试结果帧率没上来包体和内存倒是先炸了。我做Unity3d移动端性能优化也有几年了说实话这东西没那么玄它更像是在电池、发热、帧率、包体、内存这一堆约束里做取舍。这篇东西我会把自己常用的一套流程和判断标准整理出来重点是讲清楚每个决策背后的逻辑而不是丢一份“照着抄就能跑”的参数表。1. 先把话说清楚移动端性能问题到底出在哪1.1 性能差不是一种病是一堆症状先别急着谈Draw Call和GC移动端性能问题的本质是资源受限。手机上CPU、GPU、内存、带宽、电池全部共享一个散热受限的机身跟PC那种随便塞个大双塔散热器的环境完全是两码事。你项目卡顿、掉帧、发烫、闪退背后通常是这些原因在打架CPU瓶颈游戏逻辑太多、物理计算过重、复杂AI、大量代码分配内存导致GC卡顿。GPU瓶颈着色器太复杂、Overdraw严重、半透明物体太多、分辨率/后处理负担过高。内存压力纹理图集超大、资源重复加载、AssetBundle没有合理卸载最终被系统杀掉。带宽受限大量未压缩纹理、高精度Mesh、频繁读取磁盘或网络数据造成加载卡顿。功耗与发热高帧率、高屏幕亮度下长时间满载触发系统降频帧率断崖式下跌。所以当你听到“性能优化”这个词其实是要把上面这些一个个拆开看。最忌讳的就是不看数据直接猜或者照着网上某篇帖子把某个参数一改就交差。不同项目卡的原因完全不同MOBA卡在多英雄技能特效上卡牌游戏卡在界面叠加层级休闲三消卡在网络同步和对象池复用上同一套优化方案不可能通吃。1.2 先定指标再动手帧率、耗时和发热优化的第一个动作不是改代码而是定标准。你需要明确自己项目的目标帧率和允许的波动范围。我的建议是普通休闲游戏30 FPS即可首帧启动时间尽量控制在2秒以内。动作/竞技类60 FPS但要接受团战等复杂场景掉到45左右的波动前提是不要出现长时间低于30的冻帧。中重度ARPG/MMO30或45 FPS优先保证稳定不要一下子冲到60又突然掉到20这种体验比稳定30更差。定完帧率之后要用有代表性的“真机真实场景”来做基线测试。基线测试最好固定机型、固定场景、固定操作路径每轮优化前后都跑同一套流程记录平均帧率、P1/P95帧耗时、内存峰值、掉电速度这些数据。没有基线你优化完都不知道自己到底进步了多少。这里还要提一个很多人忽略的点Unity Profiler里看到的CPU耗时单位为ms你要倒推一下你的帧预算。如果是60 FPS一帧只有16.67ms渲染、逻辑、物理、UI全部要在这个预算里分30 FPS也只有33ms。不要只看一个“总耗时60ms”就觉得无从下手先拆到模块再拆到函数最后才能拆到具体资源。2. 别急着改代码先把Profiler用明白2.1 Unity Profiler怎么用才不算白用打开Unity Profiler第一步就是选对模式。我见过很多人用Editor模式下的Profiler数据在那里分析得出的结论拿到手机上全都不准。Editor下面CPU和GPU的调度、渲染API的实际执行方式跟真机差异很大所以我的习惯是Editor模式只看逻辑正确性真机数据才用来做性能决策。在真机调试时USB线连接Unity Profiler是可行的但要注意如果设备电量低或者发热严重系统会降频你测出来的数据会比你实际用户遇到的还差。比较稳妥的做法是分两轮测一轮插着充电线看具体模块耗时一轮拔掉线跑完整局记录帧间隔和掉电情况。前者用来定位问题后者用来验证体验。具体看数据的时候重点关注这几个字段PlayerLoop这一项里的Time.Update、Rendering.BatchRendererGroup、UI.Canvas.BuildBatch等可以快速判断是逻辑脚本耗时还是UI网格重建耗时。GC Alloc一栏如果看到某帧突然有几百KB的分配基本可以确定有大量临时对象产生连带着后面长时间GC暂停。Scripts这一项里按耗时从高到低排序先看排名前三的脚本。很多时候一个Update里频繁GetComponent就能吃掉你2~3ms这属于无中生有的开销。另外Profiler里的Deep Profile模式要慎用。Deep Profile会把所有函数调用全部埋点性能开销巨大适合在逻辑复杂度极高的小场景里查看调用关系不适合直接用来跑真机完整流程。真机定位到可疑脚本后我一般用Profiler的Sample Function在关键代码段打标记或者直接在代码里用[MethodImpl(MethodImplOptions.NoInlining)]配合Debug.Log输出每一段的耗时虽然笨但很可靠。2.2 Frame Debugger和GPU性能分析渲染瓶颈定位如果Profiler显示CPU侧一切正常但帧率还是上不去那八成是GPU或者渲染管线出问题了。这时候我会打开Frame Debugger按单帧逐步推进看每一步的Draw Call渲染了什么、状态切换是什么、绑定的大块纹理有多大。Frame Debugger能告诉你的一件事特别重要这个Draw Call是不是被意外打断了。比如一个场景里有几十个相同材质的小道具正常情况应该合批成一个Draw Call但因为某个物体的Scale是负数、或者材质实例被脚本改过一次导致实例ID不同、又或者用了不同的Lightmap合批直接失效。在Frame Debugger里你会看到同一个Mesh被多次提交这种情况下优化合批条件的收益比硬调Shader大得多。GPU侧更精确的数据需要厂商工具。高通平台用Snapdragon Profiler或者最新的Adreno GPU Inspector联发科用相关的Middleware API苹果平台用Xcode自带的Metal System Trace。通过它们可以看GPU压了多少负载、顶点吞吐、像素填充率、纹理带宽。很多时候你发现纹理没有压缩成ASTC带宽直接超标GPU大部分时间都卡在读取纹理上这个问题在Unity Profiler里很难直接看出来但厂商工具一眼就明白。2.3 真机Profile的常规操作真机Profiling有个节奏问题需要注意。我一般的流程是先用一台中低端机跑完整局观察FPS曲线有没有明显低谷。记录低谷出现的场景和时间点回Unity里复现相同操作。用Profiler抓那段操作的前后各5秒数据同时抓Memory Profiler快照。定位到模块之后关掉Profiler再跑一遍验证真实开销。这里要特别提醒Profiler本身有开销抓到的帧耗时通常比实际高5%~15%。所以我会把Profiler当成定位工具而不是测量工具。优化完以后判断成功与否要用真机自带FPS统计或外部帧率记录工具在不开Profiler的前提下跑完整流程。另外Unity的Memory Profiler是个好东西但很多人不会看。打开之后要重点关注两个区域Native内存里的Texture、Mesh以及Managed堆里的Mono堆大小。移动端最容易出问题的往往不是C#对象多而是某个图集被重复加载一份贴图在AssetBundle和Resources里各存了一份Memory Profiler按资源维度排序后立刻就能看到这种浪费。3. 渲染优化Draw Call、合批和Shader才是大头3.1 Draw Call从上千降到一两百的路径移动端GPU是Tile-Based架构Draw Call对CPU的影响比PC更明显因为每次提交都要经过驱动层做一堆状态检查。传统意义上一个场景里Draw Call超过三四百中端机器就已经有明显的瓶颈。降Draw Call最常用的三个手段合并材质和纹理能用一张图集就不要分别引用多张贴图能用同一份材质就不要反复new材质实例。静态合批和运行时合批把不动的场景物体标记为Static Batching动态物体尽量保证使用相同材质和Mesh让Unity自动做Dynamic Batching。GPU Instancing大量重复物体比如草、树、粒子、小石头不要循环生成一个个GameObject再去SetProperty用Graphics.DrawMeshInstanced或Graphics.RenderMeshInstanced走GPU Instancing路线一个Draw Call能画几百上千个实例。实操下来静态场景合并最直接但也容易忽略一个问题合批要求使用相同的光照贴图UV区域如果你烘焙了多个lightmap那场景里的墙体、地面被分到了不同lightmapStatic Batching很可能就不再成立。这时候要么把图集重新规划要么用Lightmap参数里的Import System把多个光照贴图合成一张确保合批不被打断。动态合批的坑更多。Unity的Dynamic Batching对顶点数有严格限制一般要求合批后总顶点数小于900而且如果Shader里用了一堆MaterialPropertyBlock设置颜色或者贴图合批立刻失效。所以实际情况是动态物尽量少用能用Instance的用Instance真正交错的少量动态物体宁可多几个Draw Call也别强行合批导致生成大量中间Mesh徒增CPU开销。3.2 Shader与Overdraw移动端GPU的隐形杀手移动端GPU处理复杂Shader的代价是固定的但很多项目把PC上那套PBR流程原样搬到手机结果中低端机一片哀嚎。移动端Shader有几个性能雷区过多的动态分支GPU分支预测失败的代价极大移动端尤其明显。超高精度模式乱用Position、UV这些用half就够了别在关键运算里全部用float。内存型纹理采样过多每多一层采样的带宽开销是叠加的法线贴图、粗糙度贴图、AO贴图堆在一起GPU的带宽很快耗尽。逐像素光照过多移动端一个全屏逐像素方向光加一两个逐像素点光源已经是上限再多就该考虑烘焙Lightmap或用Light Probe做近似。Overdraw的问题我单独说一下。Overdraw是指像素被绘制了多次最典型的场景是半透明特效叠加。一个Screen Space特效铺满屏幕如果它画了4层粒子那么屏幕每个像素至少被填充4次这会直接压低填充率。优化思路很简单淡化叠加层数量半透明物体能合并到一个ParticleSystem就合并全屏特效不要随便上能用UV扭曲就比新叠加一层Mesh好得多。检查Overdraw最直观的方法是把Shader的顶点色改成全黑然后调到半透模式或者直接用Unity的Overdraw视图。看到一片通红的地方基本就是重灾区优先处理。3.3 纹理压缩、LOD和遮挡剔除的组合拳移动端纹理压缩跟PC完全是两个世界PC上DXT已经够用手机上如果不能保证所有支持机型都兼容就统一用ASTCAndroid和PVRTC/ASTCiOS。做纹理压缩时我一般会开一个压缩预览窗口对着看肉眼可感知的细节损失是否严重。UI纹理尤其要注意边缘锯齿压缩格式引起的色带和边缘脏的问题会在高DPI手机上被放大。Android平台ASTC 6x6是平衡画质和包体的常用档位大尺寸背景可以降到8x8或10x10。iOS平台较新机型都支持ASTC老机型用PVRTC时要注意UI图和带有渐变的纹理容易出质感问题必要时单独保留高精度图。常规通用贴图尽量压缩RGBA或RGB不要拿RGBA32硬撑一张2048x2048的RGBA32在内存里占16MB在手机上这是巨大浪费。LOD和遮挡剔除是渲染优化的另一个关键组合。LOD不是让你把模型做糙而是让远处的物体使用低模近处使用高模。对移动端来说LOD的作用不仅在于减少三角形数更在于减少长距离渲染时对顶点缓冲和纹理带宽的占用。Group LOD参数建议按屏幕占比设而不是按距离硬切否则会出现近大远小地切来切去。遮挡剔除则是性能的“隐形收益”。Unity自带的Occlusion Culling烘焙起来比较慢但它能在场景里动态剔除被遮挡的物体这对城市、室内场景帮助极大。值得注意的是一开始就要把Occlusion Culling区域划分好不要整个场景塞进一个巨大的烘焙区域否则烘焙时间和数据量都会失控。烘焙完以后记得在Scene视图里打开遮挡剔除预览看看哪些物体被剔除得是否合理避免墙面和地面因为烘焙精度不够被错误剔除。4. 代码、内存与资源管理CPU侧的另一半战场4.1 GC Alloc是怎么拖垮帧率的C#的GC在Unity里是个老大难。移动端内存紧张GC随时会被触发而GC一旦启动轻则几十毫秒重则几百毫秒玩家体验就是突然卡一下。很多人以为“我内存分配不多应该没事”实际上问题不看你当前占了多少而看你在单位时间里分配了多少。哪怕每一帧只有几KB的零碎分配长期运行也会把Managed堆撑起来堆越大GC越频繁。最典型的GC Alloc来源字符串拼接Update里不断string string每帧都产生新的字符串对象。装箱拆箱把int、float塞进object集合或者使用非泛型ArrayList。LINQ查询Where、OrderBy这些都会产生迭代器和委托对象。频繁创建临时List、Dictionary哪怕你最后清空对象本身也已经分配过了。匿名方法和闭包在使用事件、协程、Task时容易隐藏分配。我自己的检查流程是在Profiler里把GC Alloc排序点开占据大头的地方然后把对应的代码段重构成无分配版本。比如字符串拼接用StringBuilder不要每帧new一个集合尽量复用并且用ListT而不是非泛型避免在Update里做循环内分配。还有一个容易忽略的点SendMessage、BroadcastMessage和FindObjectOfType这类反射调用不仅慢还会产生GC Alloc能不用就不用。4.2 常用组件缓存、对象池和字符串拼接组件缓存这块我已经养成肌肉记忆了凡是在脚本里需要反复获取的组件一律在Awake或OnEnable里缓存好绝对不在Update里GetComponent。这里的开销不是简单的函数调用而是Unity底层遍历组件列表每帧几千个物体那么做性能直接崩给你看。比如一个子弹系统每帧取一下Transform再取一下Rigidbody场景里100发子弹就是200次组件查找很容易吃满1~2ms。对象池是我强烈推荐所有项目都实现的基础设施。小到子弹、飘字、特效粒子大到怪物、NPC都可以用对象池。最简版本大概是这样public class SimplePoolT where T : Component { private StackT pool new StackT(); public T Get(T prefab, Vector3 pos, Quaternion rot, Transform parent) { T item pool.Count 0 ? pool.Pop() : Object.Instantiate(prefab, pos, rot, parent); if (pool.Count 0) { item.transform.SetParent(parent); item.transform.SetPositionAndRotation(pos, rot); } item.gameObject.SetActive(true); return item; } public void Release(T item) { item.gameObject.SetActive(false); pool.Push(item); } }注意一点对象池里的Prefab启用Instantiate时会产生加载开销所以最好在场景加载阶段把池子预热好。另外对象池不是银弹如果一个对象内部持有大量独立资源比如每个子弹都带一个AudioSource池化后依然要关注它会不会在隐藏时继续占有音频资源。字符串拼接这件事在UI系统中尤其明显。如果你每帧更新一个Text组件直接Score: score每帧就是一次字符串分配。建议在初始化时确定格式串用StringBuilder或者Unity的TextMeshPro里内置的SetText和textInfo相关方法或者把需要频繁更新的UI分成小模块值变了再刷新不要每帧都重建整段文本。4.3 纹理、音频和AssetBundle的移动端标准资源管理是移动端性能优选中容易被忽略的“定时炸弹”。纹理部分前面已经提了压缩格式这里补充一点裁入时机也很重要。如果你的场景一开始就加载了所有角色的贴图内存峰值会非常危险。比较好的做法是按模块或按关卡拆分AB进入关卡前预加载出关卡后卸载不用的资源。音频方面移动端要特别注意两个点一是不要所有音效都加载成非压缩格式建议用Vorbis或MP3压缩Loops用ADPCM或者小的长驻音效。二是AudioSource数量不要滥用。一个玩家附近的场景同时播放十几个AudioSource混音器那点开销还好但音频解码和内存占用会迅速变大。建议用AudioMixer做分组控制对距离过远或不可见的音源做暂停和恢复。AssetBundle这块我见过的最大问题是“加载了但没卸载”。很多人只用了AssetBundle.LoadFromFile然后Instantiate从来不调用Unload。时间一长AB文件和资产就常驻内存帧率再高也会被系统杀。建议从第一天就建立引用计数加载一个资源时计数加一销毁时减一计数归零才允许Unload。可以用Addressables它内部自带依赖管理和引用计数比裸AB省心很多但Addressables的初始化配置也需要按项目调整不是默认设置就能无脑好用的。5. 移动端特有的问题和排查实录5.1 我踩过的真机卡顿坑说几个我实际遇到过、网络上又不那么常被提到的坑。第一个是“低端机发热降频导致的帧率雪崩”。有次项目在旗舰机上跑60 FPS稳稳的换到中端机前两分钟还算流畅第三分钟开始掉到30再过一会儿直接卡到个位数。你检查CPU和GPU占用率都会发现不高但其实这时候是系统的thermal engine在压主频。解决办法不是继续优化某一帧的渲染耗时而是要在整体功耗上下功夫降低阴影距离、减少半透明特效叠加、限制最大帧率、在温度较高时自动降低画质和分辨率这条路比硬啃单帧性能更有效。第二个是“UI Canvas重建的积少成多”。界面看起来没多少东西但卡顿点全在UI上。后来用Frame Debugger一查发现UI的顶点面片每次数值变化都会触发Canvas重建。原因是一个通用弹窗把整个界面的Text、Image全部放在同一个Canvas下只要一个Text变了整个Canvas就重新生成一批网格。解决办法是把频繁变化的数字、列表、聊天文本从大型Canvas里拆出来放到单独的Canvas或放到带独立Mesh的组件里并设置合适的Screen Space - Overlay和Sorting Order。第三个是“VideoPlayer和实时网络流的坑”。项目里需要在移动端播放视频如果不是本地打包而是走HTTP流网络波动会直接导致Audio/Video不同步还会因为解码线程和主线程抢CPU出现帧率不稳定。后来我把视频播放放到低优先级线程用VideoPlayer的prepare模式预下载一部分再播放同时控制视频画幅和分辨率情况改善了很多。如果你从标题里带了“把unity3d视频流”的需求这条尤其值得注意。第四个是“异步加载卡顿”。很多项目用异步加载场景但异步加载只能在主线程切帧之间逐步执行当加载的AB数量特别大、每帧解压的纹理特别多时主线程依然会被拖住出现“伪异步”卡顿。一般做法是在Loading界面里用协程控制每次加载的资产数量上限例如每帧只处理20个资源剩下的排队处理这样才能真正把每帧耗时控制在安全范围。5.2 常见问题速查表我把这几年排查过程中最高频出现的问题整理了一张速查表方便你在遇到卡顿时先对照一下症状可能原因快速排查方法常用解决对策某些场景帧率突然掉一半Draw Call激增或Shader复杂度高Frame Debugger查看这场景Draw Call静态合批、GPU Instancing、减素材数量运行一段时间后开始卡顿GC频繁触发或内存泄漏Memory Profiler看Managed堆和Native内存消除GC Alloc、卸载不用的AB、禁用无用音源低端机越来越烫满帧率高导致功耗高测温度曲线、看降频事件锁帧率、动态降画质、远景渲染降级UI打开时卡顿Canvas重建开销大Profiler里搜Canvas.BuildBatch拆分Canvas、减少频繁变动的UI视频播放时全句抖动视频解码与主线程抢CPU在主线程外播放、降低视频分辨率限制码率、提前缓冲、用硬件解码加载界面卡到像死机异步加载里处理大量资源看单帧加载耗时分批加载、限制每帧资源处理数量电量消耗快全特效高帧率、屏幕亮度高对比关闭特效后的耗电差异调节帧率、降低特效层数、音频对象池速查表的作用只是帮你快速定位方向具体到每个项目还是建议先定量分析再动手。5.3 个人建议的优化优先级如果项目时间紧张不能每一项都做我会按这个优先级来先定基线、定机型范围、建真机性能监控。优先解决GC Alloc和资源重复加载问题这通常能带来最稳定的帧率提升。再处理渲染重点看Draw Call和Overdraw。最后才是Shader、纹理压缩、LOD这些细节。细节优化可以慢慢做但前两项不做后面再好的Shader也只是锦上添花。另外建议你从立项开始就保持“每次提交都要可跑测”的习惯。Unity项目到了后期性能优化最痛苦的不是没有手段而是你不知道某次改动到底是提升了还是反而变差了。性能监控不是最终版本的临时任务而是从开发期就要持续跑的常规流程。最后再分享一点性能优化永远没有终点。每次升级Unity版本、换一批iOS/Android系统、增加新功能以前压到低位的CPU和GPU开销可能又翘头所以遇到优化问题要习惯性回到数据不要凭经验拍脑袋。真机上面多花时间跑比在编辑器里反复调参数靠谱得多。做移动端这些年我最大的感受就是“有目标的测量比无休止的猜测重要一万倍”。