简介在移动游戏开发中引擎版本的选择往往决定项目的技术路线与优化策略。Unity作为主流跨平台引擎其5.x系列凭借成熟的API和良好的低端机兼容性成为许多休闲游戏团队的稳定选择。以无限跑道类跑酷游戏为例核心玩法不仅依赖流畅的操控响应更需通过对象池管理动态场景、控制GC Alloc避免卡顿、合并Draw Call降低渲染压力同时利用UGUI实现高反馈的交互界面。这些技术点共同构成了跑酷游戏从原型到上线的基础框架。本文基于Unity 5.6.2f1的开发实践系统梳理了跑道动态生成、角色碰撞判定、金币收集与摄像机跟随等关键模块的实现思路并针对移动端常见的发热、掉帧、UI渲染顺序等难题给出了可落地的排查手段与优化方案为同类休闲游戏开发或老版本Unity项目维护提供参考。 前段时间整理硬盘翻出一个旧项目一款3D休闲跑酷用的Unity 5.6.2f1。这版本放现在看确实有点年头但当年跑酷类休闲游戏正当红一套成熟的技术方案基本都沉淀在5.x系列里。我当时从原型到上线断断续续做了几个月踩了不少坑也攒了不少经验。这篇文章就把整个项目的设计思路、核心机制实现、优化方案和问题排查过程完整梳理一遍给正在做同类游戏、或者打算用老版本Unity接手跑酷项目的朋友一个参考。这个项目适合谁看呢如果你是Unity初学者想搞懂无尽跑酷的核心玩法怎么做这篇文章能把从场景搭建到上线打包的路线讲清楚如果你接手的是老项目被迫在Unity 5.6.2f1上做维护和优化那后面几节关于GC、Draw Call、打包水印、UGUI渲染顺序的内容应该能帮你少走很多弯路。1. 项目整体设计与思路拆解跑酷类游戏看起来简单实际上玩法循环、手感控制、资源管理三块缺一不可。我在立项的时候先定了几个关键方向这几个方向直接影响后面所有代码和美术资源的设计。1.1 为什么选Unity 5.6.2f1而不是新版先说版本选择。Unity 5.6.2f1是5.x系列的最后一个稳定版本2017年发布API非常成熟网上资料和插件生态都很丰富。当时项目对画面要求不高休闲跑酷的场景大多是低多边形风格不需要高版本才有的渲染管线特性5.6默认的Built-In管线完全够用。另外一个现实原因是插件兼容性。项目里需要用到一些老牌插件比如旧版DOTween、某些广告SDK、统计分析SDK它们在2017年的时候基本都是基于5.x接口开发的。上高版本意味着要么花时间升级插件要么自己改源码对一个小团队来说成本不低。还有个很实际的好处5.6.2f1在低端安卓机上的表现比同期其他版本更稳。跑酷游戏是高频操作帧率波动直接影响手感而5.6的构建优化已经打磨得比较成熟了。1.2 玩法定位轻操作、快节奏、随机变化3D休闲跑酷的典型玩法是三车道无尽奔跑玩家通过左右滑动切换车道上滑跳跃下滑滑铲。这个玩法被市场验证过很多次上手门槛极低用户不需要看教程就能玩。但是玩法简单不代表实现简单。真正让跑酷好玩的是“随机变化”和“节奏控制”。我的设计思路是跑道由多个预制体分段拼接而成每一段内部包含障碍、金币、道具的组合段与段之间既要保证随机性又要保证难度曲线平滑。简单说前期多给金币少放障碍中期开始加入连续跳跃和滑铲组合后期才上“蛇形障碍”这种需要连续变道的设计。操作响应上我要求从手指离开屏幕到角色真正做出动作延迟不能超过100毫秒。这是休闲游戏手感的底线超过这个数值玩家会觉得“角色不跟手”。这个指标我会在后面反复提到。1.3 技术方案选型轻量、可控、易排错技术选型上有几个关键决策角色移动使用Character Controller而不是刚体。跑酷的地形是平的角色不需要真实的物理弹跳用CC的Move函数可以做到精确控制也不会被障碍物意外弹飞。跑道分段用“无限生成对象池回收”模式而不是一次性铺一条超长的路。游戏跑得越远生成过的分段越多不回收的话内存迟早爆掉。UI用UGUI不用NGUI。5.6时代的UGUI已经成熟而且C#原生支持更好写动态列表、飘字、按钮事件都方便。摄像机只用一台主相机不做分层渲染。后期为了性能优化可以考虑用第二个相机处理UI上的3D物体但那属于特殊需求默认方案越简单越好。这套方案的核心思路是“可控”——每个系统都能单独调试出了问题能迅速定位。比如角色动不了先检查CC参数再看输入系统最后看动画状态机不会出现多个系统互相纠缠的排查困境。2. 核心细节解析与实操要点这里说几个跑酷项目里最容易翻车的细节跑道分块参数、障碍物碰撞规则、金币吸附逻辑、UI反馈。每一项都不难但如果没有设计清楚做出来的游戏手感会非常“轴”。2.1 跑道分块的尺寸与拼接逻辑跑道的核心参数是分段长度和宽度。我用的参数是每一段长度12米三条车道总宽度6米每条车道宽2米角色碰撞体宽度约0.8米。为什么是12米因为这个长度配合角色7米/秒的移动速度玩家差不多有1.7秒的反应时间属于“来得及反应但不至于无聊”的中间值。分段设计上我把跑道段分成三类基础段只有路面、边栏和少量金币用于衔接不产生压力。障碍段包含跳跃障碍、滑铲障碍、变道障碍中的一种或组合。奖励段多放金币和磁铁道具让玩家在紧张之后有放松时间。随机生成时按“基础段-障碍段-奖励段”的顺序循环且连续两个障碍段之间必有一个基础段或奖励段保证难度有起伏。这一点靠一个简单的权重表实现普通模式基础段:障碍段:奖励段3:4:3后期难度提升后调到2:5:3。拼接逻辑上我在地图上维护一个分段列表每次生成新段时把它挂在“生成锚点”后面锚点位置等于最后一个分段的终点。执行节点是Update里判断当前玩家Z坐标与最后一个分段终点的距离小于20米就触发生成这样跑道永远会“接住”玩家不会跑到头。2.2 障碍物与角色碰撞的判定准则障碍物碰撞是跑酷游戏里最影响体验的地方。判定太宽松玩家会觉得莫名过关、没成就感判定太严格会频繁死亡、产生挫败感。我给所有障碍物统一设计了碰撞规则障碍物自身带一个Trigger碰撞体角色带一个胶囊体碰撞器用OnTriggerEnter判定是否撞上。为什么用Trigger而不是物理碰撞因为如果让角色真的撞上箱子Character Controller会把角色弹开动作会变得不可控而跑酷角色碰上障碍后的正确表现是原地死亡不是被弹飞。碰撞体的尺寸我调过很多次最后总结经验障碍物的判定盒应该比视觉模型小15%-20%。比如一个看上去占满整条车道的箱子模型宽度2米碰撞盒宽度只做1.6米。这样做是为了照顾手机上的操作延迟和触屏精度玩家擦边过去的时候不会觉得“明明躲开了却被判定撞上”。跳跃和滑铲的判定窗口也很关键。跳跃障碍的高度我设置为1.2米这个高度下角色跳跃时滞空时间大约0.5秒玩家在距离障碍4米左右起跳就能过。滑铲障碍的高度设置为0.9米玩家在距离障碍5米左右开始滑铲能过。这两个参数直接决定教程关的节奏我建议先定数值再调教程不要反过来。2.3 金币收集、道具效果与UI反馈金币和道具是休闲游戏的正反馈核心。我的实现是金币摆放时相邻间距不小于0.8米避免玩家一次穿过时吃掉一大把导致数值膨胀每段金币数量控制在15-30个之间配合磁铁道具让玩家能明显感受到“收入曲线”。金币的碰撞逻辑用Trigger角色碰到金币后触发收集动画金币飞向屏幕上的计数图标。这个“飞行”效果我用DOTween的DOMove加曲线路径实现持续0.3秒。注意这个飞行动画在手机上要控制数量同一帧里不能有太多金币同时飞行否则UGUI的更新压力会变大我一般限制同时飞行数量最多10个。道具方面我做了一个磁铁和护盾。磁铁的作用是吸附周围5米内的金币护盾是挡一次障碍死亡。这两个道具本质是修改角色身上的状态值用bool或float标记道具持续时间用协程控制到期后自动关闭。UI反馈也值得一提。跑酷游戏反馈必须“立即且夸张”我加分时用“10”的飘字吃金币时UI图标放大1.2倍再弹回跳跃时阴影缩放、滑铲时屏幕轻微下移这些效果让玩家直观感受到操作的因果关系。别小看这些细节休闲游戏留存率一半靠手感、一半靠反馈。3. 实操过程与核心环节实现这部分是硬核操作。我按“工程配置-场景搭建-角色控制-摄像机与流程”四条线把整个项目的实现过程走一遍。3.1 工程配置与基础资源规范新建工程时选择3D模式然后在Player Settings里做几个关键设置Product Name和Bundle Identifier要提前想好后面接广告SDK和上架都要用。默认方向设为Portrait竖屏跑酷游戏用竖屏单手操控最顺手。分辨率用默认即可但如果遇到启动时显示异常可以手动设置Screen.SetResolution注意要在首帧之后调用否则不生效。Quality Settings里把Android和iOS的Pixel Light Count设为1关掉Soft ParticlesShadow Quality调到Medium以下。跑酷场景以低多边形为主实时光源越少越好后面我直接把关键场景改成烘焙光照。资源规范上我定了这样一套标准主角模型控制在800-1500面障碍物200-500面单块路面不超过200面贴图优先用图集单张贴图不超过1024x1024粒子特效每个粒子数控制在200以内。这个规范不是为了“极致优化”而是让美术同学在做资源时有明确标准不用反复改。3.2 跑道动态生成与对象池实现跑道生成系统我用一个GameManager来管理。核心代码大致如下public class TrackManager : MonoBehaviour { public GameObject[] segmentPrefabs; // 各种分段预制体 public Transform spawnAnchor; // 当前生成锚点 public float segmentLength 12f; private ObjectPool pool; // 对象池 private float nextSpawnZ; void Start() { pool GetComponentObjectPool(); for (int i 0; i 3; i) SpawnSegment(Vector3.zero Vector3.forward * (i * segmentLength)); } void Update() { if (nextSpawnZ - player.position.z 20f) SpawnSegment(Vector3.forward * nextSpawnZ); } void SpawnSegment(Vector3 pos) { GameObject seg pool.GetRandomSegment(); seg.transform.position pos; nextSpawnZ segmentLength; } }对象池的意义在于避免频繁Instantiate和Destroy。Unity 5.6的Instantiate会在托管堆上产生大量垃圾跑酷游戏每1.5秒就换一个分段如果不做对象池几分钟后GC就会卡顿一次直接在帧率曲线上看到明显尖峰。我的对象池实现很简单每个分段预制体对应一个队列Disable时回收Spawn时从队列取队列空才Instantiate。同时要用一个DistanceCleaner定期清理玩家身后超过50米的分段把它们放回池子。注意清理时要把子物体上的金币、障碍也一并回收这里用统一的“分段容器”管理所有子物体回收时SetActive(false)整段即可。3.3 角色控制变道、跳跃、滑铲的实现角色控制的实现是整个项目最核心的部分。我先说角色参数移动速度7米/秒三车道X坐标分别是-2.2、0、2.2跳跃初速度6.2米/秒重力-9.81米/秒方滑铲持续0.7秒滑铲时胶囊体高度从1.8米降到0.8米。变道用Lerp实现if (swipeLeft || Input.GetKeyDown(KeyCode.A)) targetLane Mathf.Max(0, currentLane - 1); if (swipeRight || Input.GetKeyDown(KeyCode.D)) targetLane Mathf.Min(2, currentLane 1); Vector3 targetPos new Vector3((targetLane - 1) * 2.2f, transform.position.y, transform.position.z); transform.position new Vector3( Mathf.Lerp(transform.position.x, targetPos.x, Time.deltaTime * 12f), transform.position.y, transform.position.z );这里有个细节变道的X轴速度要“先快后慢”也就是Lerp的t用Time.deltaTime乘以12这样角色在变道前半程快速偏移后半程逐渐停稳手感比线性移动舒服很多。直接设置位置的好处是不用处理Rigidbody的速度干扰也不会出现变道过程中撞到相邻车道障碍判定出错的问题。跳跃和滑铲我放在Update里检测if (swipeUp isGrounded) { verticalSpeed jumpVelocity; isGrounded false; animator.SetTrigger(Jump); } if (swipeDown isGrounded) { StartCoroutine(Slide()); }垂直方向用模拟重力verticalSpeed gravity * Time.deltaTime; cc.Move(new Vector3(0, verticalSpeed * Time.deltaTime, forwardSpeed * Time.deltaTime));注意Character Controller的Move函数一次调用接受一个Vector3它内部处理碰撞检测所以速度单位要乘DeltaTime。如果你把速度向量传进去时忘了乘DeltaTime角色会飞出去这是新手最常见的坑。滑铲的实现我是把胶囊体高度调低同时播放蹲伏动画。高度不用立刻变用Lerp花0.1秒过渡避免胶囊体因为高度突变而“顶”到地形。滑铲结束后同样Lerp回原高度。3.4 摄像机跟随与生死流程摄像机跟随要做到“稳”而不是“死板”。直接用transform.position player.position会让镜头变得僵硬玩家快速变道时镜头跟着猛晃时间长了会晕。我用LateUpdate里做Vector3.LerpVector3 targetPos new Vector3( Mathf.Lerp(transform.position.x, player.position.x * 0.3f, Time.deltaTime * 8f), player.position.y 5f, player.position.z - 6f ); transform.position targetPos; transform.LookAt(player.position Vector3.up * 1.5f);X轴只跟随30%的偏移这是为了在变道时镜头只轻微转动画面更稳。Z轴是固定偏移Y轴可以保持不变不需要随跳跃起伏否则镜头会晃。LookAt的朝向点比角色中心高1.5米这个高度让玩家视角略微俯视能看清前方10米内的跑道信息。生死流程我用一个协程控制。角色撞到障碍后先触发死亡动画、停住跑道生成、蹦出结算UI然后等玩家点击“复活”按钮。这里的“复活”不是瞬开而是做一个淡出淡入转场先让游戏画面淡到黑再重置角色位置、清空前方障碍、淡回游戏画面。淡入淡出用UGUI的CanvasGroup配合DOTween的DOFade0.3秒淡出、0.3秒淡入整个转场不超过1秒避免玩家等得不耐烦。3.5 光照烘焙与Shader设置Unity 5.6的光照烘焙已经很好用了跑酷场景的地形、路障、静态装饰全都可以烘焙。做法是把静态物体勾选Static添加Lightmap Static然后配一个方向光和几个补光打开Bake窗口选“Auto Generate”或手动烘焙。烘焙能大幅降低实时光照的计算开销低端机型上尤其明显。配合Shader选择地面和障碍用Mobile/Diffuse或Unlit颜色背景建筑用VertexLit角色用带简单Lambert光照的Shader。避免用Standard高光Shader因为5.6的Standard在低端机上跑起来偏重一个场景里如果几十个物件都带Standard材质Draw Call和GPU开销都会飙升。4. 性能优化老版本Unity也要压榨性能跑酷游戏因为要长时间运行、高频更新性能优化比很多休闲游戏更严格。我把优化分成三块CPU与GC、渲染、内存。每一块都有对应的排查工具和优化手法。4.1 GC Alloc控制跑酷卡顿的头号凶手我在Profiler里观察过Unity 5.6项目卡顿有70%以上的原因来自GC垃圾回收。跑酷游戏每秒生成大量金币碰撞体、飘字、分段对象如果不注意代码写法托管堆会迅速增长触发GC时在真机上能明显感到“卡了一拍”。几个我踩过的坑和解决方案每帧在Update里new字符串拼接比如显示分数时直接写“Score:” score。改成每帧只改Text组件的text但用StringBuilder或预格式化的字符串。5.6没有string.Create可以用IntToString缓存表加速。协程里用yield return new WaitForSeconds(...)这个写法会在每帧创建新对象。改成启动时缓存WaitForSeconds实例。但WaitForSeconds在不同时间间隔时要缓存多个实例用字典存起来。查找组件时反复GetComponent。所有经常访问的组件都在Start或Awake里缓存成私有字段。对象池回收时调用SetActive(false)会触发一次UI重建如果是UI对象尽量用CanvasGroup的alpha和interactable来控制显隐减少SetActive调用。Profiler定位GC Alloc的方法是打开Profiler在CPU Usage里选“Hierarchy”视图看“GC Alloc”列排序后查哪些函数每帧分配内存超过1KB。定位后逐帧修复。修复完再跑一轮目标是把每帧GC Alloc压到500字节以内。4.2 Draw Call与批处理老机子不掉帧的保障Unity 5.6的Draw Call如果不太高靠动态批处理和静态批处理能省很多开销。我优化前后的对比是优化前场景Draw Call约320优化后降到78低端安卓机上帧率从平均35帧提到60帧。具体做法把所有使用同一材质的不同网格合并成一个大网格。比如路面和路障用同一套调色就把它们静态合并。动态物体尽量共用材质球。角色、金币、道具的材质贴图塞进同一张图集材质实例数量越少越好。用Unity内置的Static Batching把场景里固定不动的小物件打到一个batch里。注意静态批处理会额外占用内存如果场景里物件太多内存会涨上去所以要控制单批的面数。粒子系统要限制数量。尤其金币收集时的金币飞行特效如果一个特效用太多Particle SystemDraw Call会直线飙升。Unity 5.6的Frame Debugger是个好工具能直接看到每一帧渲染了哪些物体、每个Draw Call消耗了多少。打开Window Frame Debugger鼠标点击Draw Call列表场景视图会高亮对应的物体很容易找出多余的渲染对象。4.3 分辨率适配与UI缩放老版本默认行为要留意Unity 5.6对多分辨率适配已经做了不少工作但依然有坑。默认CanvasScaler的UI Scale Mode是Constant Pixel Size在小屏手机上UI会显得很大在大屏平板上又显得很小。我的做法是改成Scale With Screen Size参考分辨率设为1080x1920Match设为0.5。游戏画面本身的适配要同时考虑刘海屏和异形屏。我在所有UI外层加了一个SafeArea组件动态读取Screen.safeArea把UI根节点偏移到安全区域以内。注意这个组件在5.6里没有内置需要自己写原理就是读取Screen.safeArea的Rect然后设置根节点的RectTransform。真机上如果不是全面屏safeArea会等于全屏不用担心兼容。另外分辨率变化时Camera的aspect会变。如果背景铺满全屏要保证背景图比例是2:1以上不然横屏或不同比例的竖屏会出现黑边。我的背景用了一张2048x4048的图配合Camera的orthographicSize动态调整让两侧永远有内容。4.4 场景内存与包体积控制Unity 5.6在Android上打包APK时资源和代码会打在一起。为了控制包体大小我把所有场景纹理压缩成ASTC如果设备支持或ETC2。UI贴图用单独的图集避免散图过多。场景内存控制方面跑酷场景虽然是无尽模式但同一时间活跃的对象数量是有限的。我用对象池限制了分段总数为30-40段场景内活动物体总数控制在200个以下。玩家身后50米以外的分段回收前方20米之外的不预生成这样内存占用能稳定在300MB以内。有一点特别提醒Unity 5.6对Shader的变体处理不够聪明如果你在项目中引用大量Shader哪怕没用到的变体也会被打进包。解决方法是使用ShaderVariantCollection精确控制Shader变体或者在Project Settings里手动清理。我见过很多老项目包体大得离谱一半原因是Shader变体没清理。5. 常见问题与排查技巧实录最后这部分我把项目开发过程中遇到的典型问题和排查思路整理成一份速查表。这些坑都是真实踩过的每一条都对应一次深夜调试。5.1 碰撞穿透、跳不过去、滑铲撞头现象角色在快速奔跑时偶尔穿过障碍或者明明起跳了还是在原地被撞。原因1Fixed Timestep过大。Unity默认是0.02秒如果代码里改大了角色高速移动时每帧位移会超过碰撞器厚度直接穿透。解决办法是把Fixed Timestep保持或调低到0.015。原因2Character Controller的Min Move Distance设为0时角色可能不被碰撞检测。这个值不要设成0设成0.001左右。原因3碰撞体Layer没有设置好。我在Physics设置里把Player和Obstacle的碰撞矩阵勾上并且把Player放到Player层Obstacle放到Obstacle层两层的碰撞只保留Player-Obstacle减少不必要的碰撞计算。滑铲撞头滑铲时胶囊体缩小如果缩小的速度太快胶囊体会嵌入地面或头顶障碍内。需要把高度变化过渡时间拉长到0.1-0.15秒同时缩小过程中把CC的center微调保持脚底位置不变。5.2 手机上发热、掉帧、帧率不稳定现象真机跑几分钟后手机发热帧率从60帧掉到30帧甚至更低。排查步骤先用Profiler连真机观察CPU和GPU占用率。如果是CPU占用高看GC Alloc和脚本耗时如果GPU占用高看Draw Call和填充率。我在实际项目里遇到的情况是金币的Mesh Collider计算量太大。金币用的是球体碰撞器但场景里同时存在几十个金币每个都有单独的碰撞器物理引擎每帧要做大量碰撞检测。解决办法是把金币改成Box Collider碰撞体积缩小到球体外观的80%并且给金币碰撞器加上“只在接近玩家时才激活”的开关距离玩家5米内的金币才启用碰撞检测。还有一次帧率不稳排查后发现是背景建筑上挂了很多动态灯光。把灯光全部去掉改用烘焙光照贴图后帧率立刻稳定了。记住移动端尽量少用实时多光源一个场景里点光源不要超过1个。5.3 打包问题License激活失败、试用水印这个话题在开发者社区里见过好多次。如果你用的是正版订阅或破解版可能遇到“No valid Unity Editor license found. Please activate your license.”的弹窗这个通常是许可证校验失败可能是网络问题、证书过期或者使用了不支持的激活方式。另一个常见问题是右下角出现“试用版/水印”字样。从我的经验来讲这类问题分几种License文件没正确登录。在Unity Hub里重新登录账号或者重新激活许可证一般能解决。断网离线激活的机器每隔一段时间需要重新校验。如果公司内网限制了Unity的服务端口建议提前在联网环境激活好编辑器和许可证。打包时用了“Personal版”但没登录账号Unity会在构建时打上水印。只要登录任意有效的Unity账号Personal版打出来的包就不会有水印。如果你的项目本身是合法的这些操作基本够用了。但也要提醒一句如果你用的是来路不明的版本水印和激活问题只是表面现象里面可能还有代码注入风险正规项目千万不要在这个环节上省钱。正版许可证的费用跟自己Debug几个星期的时间成本比根本不算什么。5.4 拖拽物体显示在UGUI之上怎么做Unity 5.6中3D物体和UI的渲染顺序是一个经典问题。你拖着一个3D物体移动它却显示在UI按钮底下看起来像是“穿模”。本质原因是UGUI默认用Screen Space Overlay渲染它的渲染顺序在所有3D物体之后。解决方案有三种方案一把Canvas的Render Mode改成Screen Space Camera然后把Canvas挂在主相机上再将3D物体的Layer设成UI层把Canvas的Plane Distance设为负值让UI在物体后方。这个方案适合需要在UI后显示3D物体的场景。方案二调整渲染队列。把3D物体的材质Shader的RenderQueue改成高于UI的队列比如设成4000以上。但这个方法会破坏透明物体的排序不建议在复杂UI里用。方案三我推荐的用两个相机。主相机渲染场景UI相机只渲染UI层Culling Mask只选UI层。把UI相机的Depth设大于主相机Clear Flags设为Depth Only。这样3D物体永远在UI之上UI也不会遮挡3D物体。需要“某物体显示在UI上”就把该物体放到UI相机渲染的图层里。我在项目里就是用的方案三。跑酷游戏里金币收集后的飞行动画、道具图标放大效果、结算时的粒子特效都是通过UI相机和主相机分层来实现的。这样代码逻辑清晰渲染顺序一目了然。5.5 UGUI的ScrollView偶尔卡顿、列表错乱跑酷游戏的结算界面通常有个历史记录列表或者商店里有道具列表。ScrollView在5.6里如果一次性塞进去几百个Item打开时会卡顿。我的做法是使用虚拟列表只显示可视区域内的Item滚动时动态复用。这个方案在5.6里需要自己实现不能直接依赖高版本的ListView组件。如果列表出现错乱、滑动时闪现空白一般是Item的RectTransform尺寸没有正确初始化或者Content的锚点设置不对。排查时打开RectTransform面板在运行时调整ScrollView大小观察Content的Height是否等于所有Item高度之和。如果Item复用时数据没更新记得在OnEnable里强制刷新一遍。老版本UGUI没有内置的虚拟滚动这块写起来麻烦一点但性能回报很值。5.6 一个小技巧用Frame Debugger优化UI过度绘制UI过度绘制在普通2D游戏编辑器里很难发现但在UGUI里特别常见。我项目里跑酷结算页面的背景用了三张半透明图片叠在一起结果真机上页面切换时卡顿明显。用Frame Debugger逐Draw Call检查后发现那三张图片叠出的区域被覆盖了多次。解决办法是把多层图片合并成一张或者用CanvasGroup控制整体透明度而不是叠多张半透明材质。UI对象如果不开Raycast Target可以省下很多不必要的射线检测开销。这一步在OpenUI时的收益非常明显。我认为这部分内容对做老项目优化的朋友应该挺有用的。Unity 5.6.2f1放在今天不算先进但“项目用什么版本”从来不应该是阻碍你把游戏做好的理由。把对象池、GC控制、Draw Call合并、碰撞判定这些基本功做扎实哪怕版本老一点游戏一样能跑得流畅、玩着舒服。如果你也在折腾跑酷或者类似的移动端休闲游戏希望这套思路能给你省下几个晚上的调试时间。本文还有配套的精品资源点击获取