企业官网建设流程全解析

简介：在移动游戏开发中，引擎版本的选择往往决定项目的技术路线与优化策略。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 Particles，Shadow 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 = GetComponent<ObjectPool>(); 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.Lerp：

Vector3 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的DOFade，0.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 System，Draw 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，参考分辨率设为1080x1920，Match设为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 碰撞穿透、跳不过去、滑铲撞头

• 现象：角色在快速奔跑时偶尔穿过障碍，或者明明起跳了还是在原地被撞。
• 原因1：Fixed Timestep过大。Unity默认是0.02秒，如果代码里改大了，角色高速移动时每帧位移会超过碰撞器厚度，直接穿透。解决办法是把Fixed Timestep保持或调低到0.015。
• 原因2：Character 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合并、碰撞判定这些基本功做扎实，哪怕版本老一点，游戏一样能跑得流畅、玩着舒服。如果你也在折腾跑酷或者类似的移动端休闲游戏，希望这套思路能给你省下几个晚上的调试时间。

本文还有配套的精品资源，点击获取