Unity项目性能优化全攻略：从CPU、GPU到内存管理的实战解析

1. 项目概述：为什么Unity项目优化是开发者的必修课？

做Unity开发这些年，我最大的感触就是：一个项目从“能跑”到“跑得流畅”，中间隔着一道巨大的鸿沟，这道鸿沟的名字就叫“优化”。很多开发者，尤其是刚入行的朋友，常常把精力都花在实现酷炫的功能和精美的画面上，直到项目打包出来，在真机上一跑，帧率掉得跟过山车一样，发热严重，甚至直接闪退，这才慌了神，回头去补优化的课。这就像盖房子，只顾着把外观设计得富丽堂皇，却忽略了地基和承重结构，等房子盖到一半才发现问题，整改起来就非常痛苦了。

“Unity项目优化”这个标题，听起来像是一个宽泛的建议合集，但实际上，它指向的是游戏和应用从原型走向产品、从个人作品走向商业产品的必经之路。优化的本质，是在有限的硬件资源（CPU、GPU、内存、带宽）下，通过一系列技术手段和设计策略，最大化地提升程序的运行效率、稳定性和用户体验。它不是一个可选的“加分项”，而是一个贯穿项目始终的“生存技能”。

为什么这么说？因为用户和市场是残酷的。玩家不会关心你的特效用了多少行Shader代码，他们只关心游戏卡不卡、手机烫不烫、电量掉得快不快。应用商店的差评区里，充斥着大量因为性能问题而被打低分的应用。一次糟糕的性能体验，足以让用户毫不犹豫地点击卸载。因此，优化直接关系到产品的留存率、口碑和商业成功。

那么，Unity项目优化具体要优化什么？简单来说，就是四个核心方向：CPU性能、GPU性能、内存管理和资源加载。CPU负责逻辑计算、物理、动画、UI更新等；GPU负责将三维场景渲染到二维屏幕上；内存管理决定了你的应用能同时承载多少内容而不崩溃；资源加载则影响了用户进入游戏或切换场景的等待时间。这四个方面相互关联，一个地方的瓶颈往往会引发连锁反应。接下来，我将结合我踩过的无数个坑，为你系统性地拆解Unity项目优化的核心思路、实操要点和那些官方文档里不会写的“血泪经验”。

2. 核心优化思路：从宏观设计到微观实现

在动手写任何一行优化代码之前，我们必须先建立起正确的优化思维。盲目地、零散地应用优化技巧，往往事倍功半，甚至可能引入新的问题。一个高效的优化流程，应该像医生看病一样，先诊断，再开方。

2.1 性能瓶颈定位：Profiler是你的第一双眼睛

优化最大的忌讳就是“凭感觉猜”。你觉得是Draw Call太高，结果折腾半天发现是某个脚本里有个死循环。Unity内置的Profiler窗口，就是我们最强大、最权威的性能诊断工具。很多新手害怕看Profiler，觉得里面曲线和数字太复杂，但其实你只需要关注几个核心区域。

打开Window > Analysis > Profiler。在真机（尤其是目标低端机）上运行游戏，并通过Build Settings中的Development Build和Autoconnect Profiler选项连接，这样才能获得最真实的性能数据。

• CPU Usage 区域：这是重中之重。它告诉你每一帧CPU时间都花在了哪里。把鼠标悬停在时间轴上，你可以看到该帧的详细耗时分解。重点关注耗时最长的几个部分：

  • Rendering：GPU渲染相关指令的CPU开销。如果这里很高，可能是Draw Call太多、动态批处理/静态批处理没做好，或者GPU真的忙不过来了（此时GPU区域会显示为红色）。
  • Scripts：你的游戏逻辑代码耗时。如果某个自定义的脚本函数（如Update,FixedUpdate）长期占据榜首，它就是你需要重点优化的对象。
  • Physics：物理引擎计算耗时。物体太多、碰撞体太复杂、刚体迭代次数过高都会导致这里暴涨。
  • UI：Canvas重建和布局计算。这是UI卡顿的罪魁祸首。

• GPU Usage 区域：如果这里出现红色，说明GPU是瓶颈。通常与填充率（像素着色器过于复杂、全屏后处理特效过多）、顶点处理（模型面数太高、蒙皮顶点数太多）或带宽（纹理尺寸过大、未压缩）有关。

• Memory 区域：查看Simple或Detailed视图。关注Total Used Memory和Texture Memory、Mesh Memory。内存泄漏通常表现为这个数值只增不减，即使切换场景后，之前场景的资源也没有被正确释放。

实操心得：不要只看一帧的数据。性能问题往往是间歇性出现的。使用Profiler录制一段包含典型游戏操作（如战斗爆发、场景切换、打开大型UI）的30秒到1分钟片段，然后分析其中的性能峰值（Spike）。这些峰值才是导致卡顿的真凶。另外，Deep Profile选项能深入到每个函数调用，对定位脚本瓶颈极其有用，但开销巨大，只适合在需要精确定位问题时短时间开启。

2.2 确立性能预算与目标

在项目初期，团队就应该确立清晰的性能目标，也就是“性能预算”。这就像项目的财务预算，规定了各项资源的上限。

• 帧率目标：主流移动游戏通常目标是30FPS或60FPS。对于VR项目，必须稳定90FPS以上以避免眩晕。你的所有优化都应服务于稳定达到这个帧率。
• 内存预算：根据目标设备的内存水平设定。例如，针对中低端安卓机，整个应用的内存占用（尤其是纹理和网格）最好能控制在300MB以内。iOS由于内存管理机制不同，也需要单独设定。
• Draw Call 预算：对于移动平台，每帧的Draw Call数最好控制在100-200以内。对于PC或主机，可以适当放宽，但也要避免无意义的增长。
• 安装包大小：特别是对于移动端，包体大小直接影响下载转化率。需要对纹理、音频等资源进行严格的压缩和格式选择。

有了这些预算，在制作每一个功能、导入每一个资源时，你心里都要有一杆秤：这个新加的东西，会吃掉我多少预算？是否在可接受范围内？这种“预算意识”能从源头上避免很多后期的性能灾难。

3. CPU端性能优化实战解析

CPU是游戏逻辑的“大脑”，它的性能瓶颈通常表现为游戏逻辑卡顿、UI响应迟缓。

3.1 脚本代码优化：告别“万恶之源”Update

脚本性能低下是新手项目中最常见的问题。很多开发者喜欢把大量计算不分青红皂白地塞进Update函数里。

• 减少Update/FixedUpdate调用：这是最立竿见影的优化。为每个需要每帧更新的脚本都挂一个Update是极其奢侈的行为。你应该：

  1. 自建更新管理器：创建一个全局的UpdateManager，它自己有一个Update。其他需要更新的对象向这个管理器注册，并在管理器的Update中被统一调用。这样可以将成百上千个Update调用合并成一个，并方便地控制更新频率（例如，非核心的AI可以每2帧更新一次）。
  2. 使用协程（Coroutine）进行非即时更新：对于不需要每帧执行，只需要间隔一段时间执行的任务（如怪物巡逻路径点计算、环境音效随机播放），使用WaitForSeconds的协程远比在Update里累加Time.deltaTime要高效。
  3. 善用InvokeRepeating和Invoke：对于简单的定时任务，这两个API比协程开销更小。

• 避免在Update中执行昂贵操作：

  • Find / GameObject.Find：这是性能杀手。它需要遍历场景中所有GameObject。绝对不要在Update中使用。替代方案是在Awake或Start中缓存引用。
  • GetComponent：同样有开销。尽量在初始化时缓存组件引用。
  • 字符串操作：在Update中频繁进行字符串拼接（尤其是使用+号）会产生大量GC Alloc（垃圾回收分配）。使用StringBuilder进行优化。
  • Instantiate / Destroy：动态创建和销毁物体开销巨大。这就是对象池（Object Pooling）技术存在的意义。对于频繁生成和消失的物体（如子弹、特效、敌人），预先创建一批并放入池中，使用时激活，不用时禁用并放回池中。

// 一个极简的对象池示例 public class SimpleBulletPool : MonoBehaviour { public GameObject bulletPrefab; public int poolSize = 20; private Queue<GameObject> bulletPool = new Queue<GameObject>(); void Start() { for (int i = 0; i < poolSize; i++) { GameObject bullet = Instantiate(bulletPrefab); bullet.SetActive(false); bulletPool.Enqueue(bullet); } } public GameObject GetBullet() { if (bulletPool.Count > 0) { GameObject bullet = bulletPool.Dequeue(); bullet.SetActive(true); return bullet; } // 池空了，可以动态扩容，但最好避免 GameObject newBullet = Instantiate(bulletPrefab); return newBullet; } public void ReturnBullet(GameObject bullet) { bullet.SetActive(false); bulletPool.Enqueue(bullet); } }

• 物理引擎优化：物理计算（PhysX）非常消耗CPU。
  1. 合理使用刚体类型：对于不会移动的物体（如地面、墙壁），使用Static或Kinematic刚体，而不是Dynamic。
  2. 简化碰撞体：能用BoxCollider或SphereCollider就不用MeshCollider。MeshCollider是最精确但也是最耗性能的。
  3. 调整Fixed Timestep：在Project Settings > Time中，Fixed Timestep默认是0.02s（50Hz）。降低这个值（如到0.04s）可以减少物理更新的频率，从而降低CPU开销，但会降低物理模拟的精度。需要根据项目类型权衡。
  4. 使用图层（Layer）进行碰撞过滤：在Edit > Project Settings > Physics中，通过设置Layer Collision Matrix，避免不必要的物体之间进行碰撞检测，能大幅减少计算量。

3.2 UI性能优化：Canvas重建是元凶

Unity的UGUI系统功能强大，但若使用不当，极易成为性能黑洞。其核心性能开销来自于Canvas的重建（Rebuild）。

• 拆分Canvas（画布）：这是UGUI优化第一铁律。Canvas是UI元素的渲染单元。当Canvas上的任何一个UI元素发生变化（位置、颜色、文本等），整个Canvas都需要重新计算网格（Mesh）并重新批处理（Batch），这个过程就是重建。如果你把整个游戏的UI都放在一个Canvas下，那么改动任何一个按钮的文本，都会触发这个巨型Canvas的完全重建，造成CPU尖峰。

  • 解决方案：根据UI的更新频率进行拆分。
    • 静态Canvas：放置几乎从不变化的UI，如背景图、装饰性边框。
    • 动态Canvas：放置频繁更新的UI，如血条、分数、计时器。
    • 弹出层Canvas：放置临时出现的UI，如对话框、菜单。可以进一步为每个独立的弹出窗口使用子Canvas。
  • 子Canvas（Sub-Canvas）：UGUI支持Canvas嵌套。子Canvas的Rebuild不会触发父Canvas的Rebuild，这为UI模块化提供了便利。将功能独立的UI模块放在子Canvas里是个好习惯。

• 禁用不必要的Raycast Target：UGUI中，Image、Text等Graphic组件默认勾选了Raycast Target。这意味着它们会参与UI事件系统的射线检测。如果你的UI元素只是用于显示，不需要点击交互（比如一个背景图片、一段描述性文字），务必取消勾选。这能显著减少EventSystem每帧需要处理的射线检测对象数量。

• 谨慎使用布局组件（Layout Group）：Horizontal Layout Group、Vertical Layout Group、Grid Layout Group等非常方便，但代价高昂。当布局组下的任何一个子UI元素尺寸发生变化时，布局组会触发一次“脏”标记，并递归向上查找父布局组，引发一系列GetComponent调用和重新布局计算。嵌套的布局组性能开销呈指数级增长。

  • 替代方案：对于静态UI，直接手动摆放。对于动态列表（如背包、排行榜），不要为每个列表项都套用布局组。推荐使用循环利用的列表组件，自己计算并设置每个项的位置。Unity官方提供的UI Toolkit在新的UI系统中对动态列表有更好的性能支持，但对于UGUI，许多开发者会选择使用Asset Store上成熟的插件（如EnhancedScroller、SuperScrollView）或自己实现。

• 优化UI动画：避免在UI元素上使用完整的Animator组件来做简单的位移、缩放、渐变动画。Animator每一帧都会去检查状态和参数，即使动画没有播放，也有开销。对于简单的UI动画，有两种更好的选择：

  1. 使用Dotween、LeanTween等补间动画插件：它们轻量、高效，API友好。
  2. 使用Unity自带的UI Animation和Animator（仅用于UI）：在Animation窗口中为UI录制动画，然后使用Animator控制器播放，但确保Animator的Culling Mode设置为Based On Renderers或Always Animate，并且不要挂在频繁更新的UI上。

4. GPU端与渲染性能优化实战

当你的游戏画面复杂时，GPU就会成为瓶颈。优化GPU的目标是减少其每帧的工作量。

4.1 降低Draw Call：合批（Batching）的艺术

Draw Call是CPU命令GPU绘制一个东西的调用。每一次Draw Call都有CPU准备数据和GPU执行的开销。减少Draw Call是渲染优化的核心。

• 静态合批（Static Batching）：对于在运行时不会移动、旋转、缩放的物体（如场景建筑、静态植被），可以勾选其MeshRenderer上的Static复选框。Unity在构建（Build）时或运行时（如果允许）会将这些静态物体的网格合并成一个或几个大网格，从而用极少的Draw Call绘制它们。代价是会增加内存占用（存储合并后的网格）和构建时间。

  • 注意：只有使用相同材质的静态物体才会被合批。如果两个静态物体材质球引用的是同一个材质实例，它们可以被合批。但如果材质球虽然看起来一样，却是两个不同的实例（即使参数相同），也无法合批。

• 动态合批（Dynamic Batching）：Unity会在运行时，自动将一些满足条件的小型动态物体（顶点数少于300，使用相同材质等）合并Draw Call。但这个功能限制很多，且CPU开销不小。对于现代项目，尤其是移动端，通常建议在Player Settings中关闭动态合批，转而使用更高效的GPU Instancing。

• GPU Instancing：这是绘制大量相同物体（如草地、树木、子弹）的最高效方式。它允许GPU用一次Draw Call绘制多个使用相同网格和材质的物体，每个物体的位置、颜色等差异通过一个常量缓冲区传递。启用方法很简单：在材质的Inspector面板上勾选Enable GPU Instancing。你的着色器也需要支持Instancing。Unity的标准着色器（Standard、URP/Lit）都支持。

  • 与SRP Batcher的配合：在使用URP或HDRP时，SRP Batcher是一个更强大的合批系统。它不合并网格，而是合并渲染状态（Shader、材质属性）的提交，大幅减少CPU渲染开销。要享受SRP Batcher的好处，需要编写符合其规则的Shader（通常是使用CBUFFER_START(UnityPerMaterial)宏来声明材质属性）。

4.2 材质与着色器优化

• 减少材质种类：这是减少Draw Call最直接的方法。尽量让场景中的不同物体共享材质。如果它们只是颜色或纹理不同，可以考虑使用材质属性块（MaterialPropertyBlock）来动态修改渲染参数，而无需创建新的材质实例。
• 简化Shader复杂度：片元（像素）着色器中的计算是逐像素执行的，在高分辨率屏幕上开销巨大。
  • 减少复杂的光照计算（移动端尽量使用Baked GI或轻量级光照模型）。
  • 减少纹理采样次数。能合并的纹理（如将金属度、光滑度、环境光遮蔽打包到一张纹理的RGB通道）尽量合并。
  • 避免在Shader中使用discard操作（如透明裁剪），这会严重影响GPU的早期深度测试优化。
• 使用正确的纹理格式和压缩：
  • ASTC（Android）和PVRTC（iOS）是移动端高效的纹理压缩格式。在Texture Import Settings中根据平台选择。
  • 绝不使用“Truecolor”（无压缩）格式，内存占用巨大。
  • 根据纹理用途选择最大尺寸。一个1024x1024的UI贴图，在1080p屏幕上可能512x512就足够了。使用Texture2D.maxTextureSize进行限制。
  • 启用Mipmaps可以减少远处物体的纹理锯齿和提升缓存效率，但会增加约33%的纹理内存。对于UI纹理和永远离摄像机很近的物体，可以关闭Mipmaps。

4.3 光照与阴影优化

实时光照和阴影是性能杀手。

• 尽可能使用烘焙光照（Baked GI）：将静态物体的光照信息提前计算并“烘焙”到光照贴图（Lightmap）中。运行时无需再进行实时光照计算，性能开销极低，效果还好。这是提升场景视觉质量和性能的最重要手段。
• 减少实时光源数量：每个逐像素光照的实时光源都会增加Draw Call。尽量将光源设置为“Baked Only”或“Mixed”（仅影响动态物体的部分使用实时）。
• 优化实时阴影：
  • 减少阴影距离（Shadow Distance）：在URP/HDRP的渲染管线资产或Quality Settings中设置。超出此距离的物体将不投射也不接收实时阴影。
  • 使用更低的阴影分辨率。
  • 使用级联阴影映射（Cascaded Shadow Maps, CSM）时，减少级联数量。
  • 对于移动端，考虑使用更简单的阴影技术，如Projector阴影或屏幕空间阴影（Screen Space Shadows），甚至在某些情况下用“假阴影”（一个简单的渐变平面纹理）替代。

4.4 后处理效果慎用

屏幕空间环境光遮蔽（SSAO）、景深（Depth of Field）、运动模糊（Motion Blur）、全屏泛光（Bloom）等后处理效果非常消耗性能，尤其是需要采样深度/法线纹理和进行全屏模糊的操作。

• 移动端能不用就不用，或者使用极度简化的版本。
• 如果必须使用，降低采样次数和分辨率（如使用Half/Quarter Res）。
• 考虑只在特定时刻（如释放大招时）启用某些效果，而不是全程开启。

5. 内存与资源管理优化

内存问题通常不会直接导致卡顿，但会导致应用崩溃、闪退，体验更差。尤其是在内存有限的移动设备上。

5.1 资源加载与卸载：告别Resources文件夹

Resources.Load和Resources文件夹是万恶之源。它会导致所有资源被打包进一个巨大的序列化文件中，启动时加载慢，且无法精确控制卸载，极易造成内存冗余。

• 使用AssetBundle：这是传统的、功能强大的资源动态加载方案。你可以将资源按逻辑分组打包，在需要时加载，不需要时卸载。但它管理复杂，依赖关系处理麻烦，容易造成内存泄漏（AssetBundle本身未卸载）。
• 使用Addressable Asset System（可寻址资源系统）：这是Unity官方主推的现代资源管理方案。它抽象了资源的加载方式（可以是Resources、AssetBundle、网络等），通过一个唯一的“地址”来加载资源，并自动管理依赖和生命周期。强烈建议新项目直接使用Addressables。
  • 优势：简化了代码，依赖自动管理，支持热更新，有可视化的分析工具。
  • 注意：需要学习其概念（Catalog、Group、Label）和API（Addressables.LoadAssetAsync,Addressables.Release）。务必遵循“谁加载，谁释放”的原则，使用AsyncOperationHandle和Release来管理引用计数，避免内存泄漏。

5.2 纹理与网格内存优化

• 纹理：是内存占用大头。除了压缩格式，还要注意：
  • 关闭Read/Write Enabled：除非你需要运行时修改纹理像素（如截图、动态生成纹理），否则一定要关闭这个选项。开启它会使得纹理在内存中多保存一份CPU可访问的副本。
  • 合理设置Max Size：在纹理导入设置中，根据其最终在屏幕上的显示尺寸来设定最大尺寸，而不是盲目使用原始尺寸。
• 网格：
  • 启用网格压缩（Mesh Compression），可以减小网格文件大小和运行时内存。
  • 对于不需要变形的静态物体，在导入设置中关闭Rig和Animations选项。
  • 使用LOD（Level of Detail）系统。为模型创建多个细节级别的网格，根据物体与摄像机的距离自动切换，远处使用面数少的模型。

5.3 警惕托管堆内存与GC（垃圾回收）

Unity使用C#，而C#有自动垃圾回收机制。频繁的GC（Garbage Collection）会导致CPU尖峰，引发卡顿。GC触发的主要原因是托管堆内存的分配。

• 避免在每帧中分配新的托管堆内存。以下操作都会导致分配：
  • 使用new关键字创建新的引用类型对象（如new List(),new Vector3()）。对于需要频繁创建和销毁的小型对象，考虑使用结构体（struct）代替类（class），因为结构体是值类型，分配在栈上。
  • 字符串拼接（使用+）。如前所述，用StringBuilder。
  • 装箱操作（将值类型赋值给object类型）。
  • 某些Unity API，如GetComponent（每次调用都会返回一个新的组件引用，虽然很小）。缓存它！
  • 协程中的yield return new WaitForSeconds()也会产生少量分配。可以考虑复用WaitForSeconds对象。
• 使用对象池：这不仅是优化Instantiate/Destroy，也是减少GC压力的关键。池中的对象是复用的，避免了频繁的堆内存分配与回收。
• 使用Unity Profiler的GC Alloc列：在CPU Profiler的Hierarchy视图中，可以按GC Alloc排序，快速找到分配内存的“元凶”函数。

6. 特定平台与模块的优化要点

6.1 移动平台（iOS/Android）专项优化

• 发热与耗电：这是移动端用户体验的核心。发热的根源是CPU和GPU持续高负荷运行。
  • 限制帧率：对于非竞技类游戏，30FPS是完全可接受的。在Application.targetFrameRate = 30;。这能直接降低CPU/GPU负载和功耗。
  • 减少屏幕亮度：过亮的屏幕是耗电大户。允许用户在设置中调节游戏亮度。
  • 在后台或菜单界面降低负载：当游戏处于暂停或打开全屏UI时，可以降低Time.timeScale，甚至暂停某些非必要的系统（如粒子系统、非关键AI）。
• 安装包大小（APK/IPA）：
  • 使用AssetBundle变体或Addressables的远程加载，将部分资源（如高清纹理、后续关卡）放在服务器上，运行时下载。
  • 对纹理、音频进行强力压缩。
  • 使用IL2CPP作为脚本后端（比Mono生成的二进制文件更小）。
  • 启用Engine Code Stripping，移除未使用的引擎代码。

6.2 UI系统深度优化补充

• Canvas的“Screen Space - Camera”与“World Space”模式：如果UI需要出现在3D场景中（如血条、名字），使用World Space Canvas。但请注意，这种模式下的UI元素会参与场景的深度排序，可能引发额外的Overdraw。尽量让World Space UI在单独的渲染队列，并处理好与3D物体的遮挡关系。
• TextMeshPro (TMP) 替代旧版UI Text：这是必须的。TMP使用Signed Distance Field (SDF) 技术，字体清晰锐利，且支持丰富的富文本和材质效果。性能上，对于静态文本，它通常更优；但对于频繁更新的文本，其网格重建开销也需要关注。确保为TMP字体图集设置合适的大小，避免因动态添加字符导致图集重建。

6.3 音频优化

音频资源容易被忽略，但大体积的未压缩音频（如.wav）会显著增加包体和内存占用。

• 对于长背景音乐，使用压缩格式（.mp3, .ogg）。
• 对于短音效，使用未压缩或ADPCM格式以保证即时性和低解码开销。
• 使用音频混合器（Audio Mixer）来统一管理音量、效果和路由，并利用其快照（Snapshot）功能实现不同场景（如正常游戏、暂停菜单）的音频切换。
• 避免同时播放过多相同的音效，可以使用对象池来管理AudioSource。

7. 高级架构与未来方向

当基础优化做到位后，可以考虑一些更高级的架构来进一步提升性能和表现力。

• 实体组件系统（ECS）与C# Job System/Burst Compiler：这是Unity面向高性能计算的全新框架。ECS是一种数据导向的设计模式，将数据（组件）与逻辑（系统）分离，并利用C# Job System进行多线程并行计算，再通过Burst Compiler将代码编译成高度优化的本地机器码。对于需要处理成千上万个实体（如大量单位、粒子）的模拟（AI、物理、动画），性能提升是数量级的。但ECS学习曲线陡峭，且与传统的GameObject/Component工作流差异很大，更适合用于性能关键的核心系统，而非整个项目。
• 异步加载与场景流式加载：对于开放世界或大型关卡，不要一次性加载所有内容。使用SceneManager.LoadSceneAsync异步加载场景，并结合Addressables的异步加载，实现无缝的场景切换和动态内容加载。可以设计一个加载界面，在后台预加载下一区域所需的资源。
• 自定义渲染管线与ShaderGraph：对于有特殊渲染需求的项目，URP（通用渲染管线）和HDRP（高清渲染管线）提供了高度可定制化的框架。使用ShaderGraph可以可视化地编写着色器，更方便地实现和优化特定的视觉效果，同时也能更好地与SRP Batcher配合。

优化是一个永无止境的过程，也是一门平衡的艺术。你需要在画面效果、功能复杂度、开发时间和硬件限制之间找到最佳平衡点。没有“最好”的优化方案，只有“最适合”你当前项目的方案。最好的优化，往往是在项目设计之初就考虑进去的，而不是事后补救。养成定期使用Profiler分析性能的习惯，建立团队的性能预算意识，将优化思维融入开发的每一个环节，你的Unity项目才能真正做到既好看又好用。