Unity跨平台性能优化实战：PC与安卓CPU、GPU、内存全维度解析-平芜编程栈

1. 项目概述与核心挑战

做Unity跨平台开发，尤其是同时兼顾PC和安卓，最头疼的莫过于性能问题。PC上跑得丝滑流畅的场景，一到安卓手机上就可能卡成PPT，发热、掉帧、闪退接踵而至。这背后不是简单的“手机性能差”，而是两个平台在硬件架构、图形API、内存管理乃至散热策略上的根本性差异。PC拥有独立的、性能强大的GPU和几乎不受限的CPU与内存资源，而移动端则是高度集成的SoC，CPU、GPU、内存共享有限的功耗和散热预算。因此，所谓的“跨平台性能优化”，绝不是一套参数放之四海而皆准，而是需要一套精细的、分平台的、从设计到编码的完整策略。

我经历过不少项目，从早期的“先做PC，再移植安卓”的粗暴模式，到后来“双线并行，针对性优化”的成熟流程，踩过的坑不计其数。这篇文章，就是把我这些年积累的关于Unity跨平台（PC与安卓）性能优化的实战经验，从CPU、GPU、内存三个核心维度，结合具体的C#代码案例，系统地梳理出来。目标很明确：让你不仅能看懂Profiler里那些令人眼花缭乱的数据，更能知道从哪里下手，用什么方法，以及为什么这个方法有效。无论是正在规划新项目的架构师，还是正在为线上游戏卡顿救火的开发者，希望这些“干货”能帮你少走弯路。

2. 性能优化核心思路：从“救火”到“防火”

在深入具体优化点之前，我们必须建立一个正确的优化观。很多团队把优化当作项目尾声的“救火”行为，这是大忌。优化应该贯穿于项目始终，是一种“防火”的设计思维。Michael A. Jackson的那句名言：“程序优化的第一条规则：别去做。程序优化的第二条规则（仅限专家！）：暂时还是别去做。”其深意在于，在架构清晰、逻辑正确之前，盲目的微观优化（比如纠结某个循环是否多用了一个临时变量）往往事倍功半，甚至引入难以察觉的Bug。

但对于移动平台，我们必须补充第三条规则：在早期设计时，就必须将目标平台的硬件约束作为核心设计输入。这意味着，从美术资源规范、场景复杂度、逻辑更新频率等顶层设计开始，就要考虑安卓设备的性能天花板。一个在PC上用200万面模型、4K纹理、实时动态光影构建的华丽场景，在移动端是注定无法直接运行的。优化的最高境界，是在不损失（或最小化损失）体验的前提下，让设计适配平台，而非挑战物理极限。

因此，我们的优化流程应该是：目标设定 -> 性能剖析 -> 瓶颈定位 -> 策略实施 -> 回归测试。始终用数据（Profiler）说话，避免凭感觉优化。下面，我们就从CPU、GPU、内存三大战场，展开这场跨平台性能攻坚战。

2.1 CPU优化：让逻辑跑得更“聪明”

CPU是游戏逻辑的驱动力。在移动端，CPU核心数可能更少，主频更低，且与GPU共享散热，持续高负载极易导致降频。CPU优化的核心思想是：减少每帧的工作量，均衡负载，避免峰值。

2.1.1 脚本执行效率优化

脚本是CPU消耗的大户。低效的C#代码在PC上可能无感，但在移动端会被放大。

1. 避免在Update中进行昂贵的查找操作

// 反面教材：每帧都在查找对象和组件 void Update() { GameObject player = GameObject.Find("Player"); // 昂贵！ Health health = player.GetComponent<Health>(); // 昂贵！ // ... 使用health } // 优化方案：在Start或Awake中缓存引用 private GameObject _player; private Health _playerHealth; void Start() { _player = GameObject.Find("Player"); if (_player != null) { _playerHealth = _player.GetComponent<Health>(); } } void Update() { if (_playerHealth != null) { // ... 直接使用缓存的_playerHealth } }

注意：GameObject.Find、GetComponent（尤其是泛型版本）、FindObjectsOfType等都是相对昂贵的操作。它们会遍历场景层级或组件列表。缓存是提升性能最简单有效的方法之一。

2. 使用合适的循环与集合

避免在频繁调用的代码中使用foreach：在Unity的老版本Mono或某些IL2CPP编译环境下，foreach可能产生垃圾（GC Alloc）。对于List<T>，优先使用for循环。

List<Enemy> enemies = new List<Enemy>(); // 可能产生GC Alloc (取决于Unity版本和设置) foreach (var enemy in enemies) { enemy.Update(); } // 更安全的做法 for (int i = 0; i < enemies.Count; i++) { enemies[i].Update(); }

使用Dictionary或HashSet进行快速查找：如果需要频繁通过键（如ID、名称）查找对象，Dictionary的O(1)复杂度远优于List的O(n)线性查找。

3. 减少不必要的MonoBehaviour回调不是每个脚本都需要Update。如果逻辑不需要每帧执行，可以使用协程（Coroutine）按间隔执行，或者由其他管理器统一驱动。

// 使用协程替代每帧检查 IEnumerator CheckDistanceRoutine() { while (true) { if (Vector3.Distance(transform.position, target.position) < range) { EngageTarget(); } yield return new WaitForSeconds(0.2f); // 每0.2秒检查一次，而非每帧 } }

2.1.2 物理引擎优化

Unity的物理引擎（PhysX）是CPU消耗的另一个重灾区，尤其是在移动端。

1. 合理设置物理更新频率默认的物理固定更新频率是0.02秒（50Hz）。对于大多数移动游戏，尤其是非写实物理的游戏，降低到30Hz甚至20Hz可以显著减轻CPU负担。Edit -> Project Settings -> Time -> Fixed Timestep将其设置为0.0333(30Hz) 或0.05(20Hz)。

2. 优化碰撞体（Collider）

使用简单碰撞体：优先使用BoxCollider、SphereCollider、CapsuleCollider。MeshCollider虽然精确，但性能开销最大，应尽量避免在移动端动态物体上使用。
使用碰撞体层级（Layer）和矩阵（Matrix）：通过Edit -> Project Settings -> Physics，精细控制哪些层之间需要检测碰撞。减少不必要的碰撞检测对。
将静态物体标记为Static：对于永远不会移动的环境物体，将其标记为Static（在Inspector右上角）。Unity会为它们进行预处理，大幅提升静态碰撞检测效率。

3. 控制刚体（Rigidbody）数量每个激活的Rigidbody都会增加物理计算负担。对于大量的小型、简单的物理物体（如子弹、碎片），考虑使用更轻量的方案，如基于Transform的简单运动模拟，或使用对象池（Object Pooling）复用刚体。

2.1.3 动画系统优化

1. 使用Animator的Culling Mode对于屏幕外的角色，其动画计算是浪费的。将Animator的Culling Mode设置为Based on Renderers或Cull Update Transform。前者在渲染器不可见时完全停止动画，后者在不可见时停止动画但保留最后一帧的变换，适合仍有逻辑依赖的情况。

2. 简化动画状态机（Animator Controller）过于复杂的状态机（State Machine）和大量的过渡条件（Transitions）会增加每帧的计算量。尽量合并状态，减少过渡条件，并使用Animator.StringToHash来缓存动画状态和参数的Hash，避免使用字符串参数。

private static readonly int s_SpeedHash = Animator.StringToHash("Speed"); private Animator _animator; void Update() { _animator.SetFloat(s_SpeedHash, currentSpeed); // 使用Hash，高效 // 而不是 _animator.SetFloat("Speed", currentSpeed); }

3. 考虑使用Animation Clip替代Animator对于简单的、非交互的循环动画（如旋转的风扇、飘动的旗帜），直接使用Animation组件播放.anim文件，比运行一个完整的Animator状态机开销更小。

2.2 GPU优化：每一帧的像素都是珍贵的

移动端GPU的填充率（Fill Rate，每秒能渲染的像素数）和带宽远低于PC独显。GPU优化的核心是减少每帧需要渲染的像素数量（Overdraw）和复杂度。

2.2.1 渲染管线与图形API选择

1. 选择正确的渲染管线

Built-in Render Pipeline (BRP)：兼容性最好，但高级图形功能有限，优化需要更多手动工作。
Universal Render Pipeline (URP)：强烈推荐用于移动端和跨平台项目。URP是SRP（可编程渲染管线）的预配置版本，为性能而生。它默认包含了许多移动端优化，如更高效的批处理、更少的Draw Call、更好的Shader变体管理。从项目初期就使用URP，能为后续优化打下良好基础。
High Definition Render Pipeline (HDRP)：为PC/主机的高保真图形设计，绝不适用于主流移动设备。

2. 图形API选择

Android：优先使用Vulkan（如果目标设备支持）或OpenGL ES 3.0+。Vulkan能提供更好的多线程渲染支持和更低的CPU开销。在Player Settings -> Other Settings -> Graphics APIs中调整顺序，将Vulkan置顶。
PC (Windows)：通常使用DirectX 11或12。DX12能提供更好的CPU多线程提交能力，但需要更细致的优化。

2.2.2 减少Draw Call与合批（Batching）

Draw Call是CPU命令GPU绘制一个图元列表的调用。Draw Call过多是CPU侧图形开销的主要来源。

1. 静态合批（Static Batching）将不会移动的、使用相同材质的物体标记为Static。Unity会在构建时（Build Time）或运行时将这些物体的网格合并，从而用一个Draw Call绘制多个物体。代价是增加内存占用和构建时间。

实操心得：静态合批对场景性能提升巨大，但要注意材质实例。如果“相同材质”的物体需要不同的颜色或微调参数，应使用材质属性块（MaterialPropertyBlock）来修改，而不是创建新的材质实例，否则会打断合批。

2. 动态合批（Dynamic Batching）Unity运行时自动将满足条件的小型动态物体合批。条件苛刻：顶点数少于300、使用相同材质、缩放一致等。对于移动端，由于其CPU开销，通常建议关闭动态合批（Player Settings -> Other Settings -> Dynamic Batching），除非你的游戏有大量符合条件的小物体。

3. GPU Instancing对于大量相同的网格和材质（如草地、树木、子弹），使用GPU Instancing是最高效的方式。它通过一个Draw Call渲染多个实例，数据由GPU直接处理。只需在材质的Inspector中勾选Enable GPU Instancing，并在脚本中使用MaterialPropertyBlock传递每实例数据（如位置、颜色）。

public class InstancedRenderer : MonoBehaviour { public Mesh mesh; public Material material; private Matrix4x4[] _matrices; private MaterialPropertyBlock _props; void Start() { _matrices = new Matrix4x4[100]; _props = new MaterialPropertyBlock(); Vector4[] colors = new Vector4[100]; // ... 初始化矩阵和颜色 _props.SetVectorArray("_Color", colors); } void Update() { Graphics.DrawMeshInstanced(mesh, 0, material, _matrices, 100, _props); } }

2.2.3 纹理与着色器优化

1. 纹理优化

尺寸与格式：使用2的幂次方尺寸（NPOT）。移动端广泛使用ASTC压缩格式，它在质量和大小间有很好的平衡。在Texture Import Settings中，根据平台选择ASTC 4x4、6x6等块大小。对于UI纹理，可以考虑使用ETC2（支持Alpha）或PVRTC（iOS）。
Mipmaps：对于3D场景中的纹理，务必开启Mipmaps。它能减少远处纹理的像素锯齿和缓存抖动，提升渲染性能和画面质量。但对于始终以固定大小显示的2D/UI纹理，应关闭Mipmaps以节省内存。
图集（Atlas）：将多个小纹理打包成一张大图集。这是减少Draw Call的经典方法，尤其适用于UI和2D精灵。Unity的Sprite Atlas功能可以自动管理。

2. 着色器（Shader）优化

使用移动端友好的Shader：URP自带Universal Render Pipeline/Lit等Shader就是为性能优化的。避免使用PC上复杂的表面着色器（Surface Shader），它们在移动端编译后可能非常臃肿。
简化计算：在片元着色器（Fragment Shader）中减少复杂的数学运算（如sin,pow,discard操作）、条件判断和纹理采样次数。尽可能将计算移到顶点着色器（Vertex Shader）或CPU端。
慎用透明度：半透明物体（Alpha Blend）会导致Overdraw，且无法进行深度测试的Early-Z优化，对性能影响很大。应严格控制半透明物体的数量和面积。对于粒子系统，使用Alpha Test（Cutout）通常比Alpha Blend性能更好。
管理Shader变体（Variants）：Shader中的#pragma multi_compile和shader_feature会产生大量变体，导致构建包体膨胀和运行时内存占用增加。使用Shader Stripping功能和仔细定义关键字来减少不必要的变体。

2.2.4 后处理与特效

华丽的屏幕后处理（如Bloom, SSAO, Motion Blur）是性能杀手。在移动端必须极其克制。

使用URP内置的轻量级后处理：URP的Volume系统提供了针对移动端优化的后处理效果，如Bloom、Color Adjustments。避免从Asset Store导入为PC设计的高开销后处理资源包。
降低分辨率或限制使用范围：可以将后处理渲染到一张半分辨率（Half Res）的Render Texture上，或者只对屏幕局部区域应用。
粒子系统：控制最大粒子数、使用简单的Shader、使用图集动画而非帧动画、对于屏幕外的粒子系统使用Culling。

2.3 内存优化：告别闪退与卡顿

移动设备内存（RAM）有限，且与GPU共享。内存使用不当不仅会导致闪退（OOM），还会因频繁的垃圾回收（GC）引起卡顿。

2.3.1 托管堆内存与GC优化

C#的托管堆内存由垃圾回收器（GC）管理。GC运行时（尤其是Full GC）会“Stop-the-World”，导致游戏卡顿。

1. 避免在每帧中分配新的堆内存这是移动端C#脚本优化的黄金法则。任何new关键字（对于引用类型）都可能触发GC。

// 反面教材：每帧都在分配新的List和Vector3 void Update() { List<Vector3> points = new List<Vector3>(); // GC Alloc! points.Add(new Vector3(1,2,3)); // GC Alloc! (如果Vector3是class，但它是struct) // ... 使用points } // points离开作用域，成为垃圾 // 优化方案：复用集合和数组 private List<Vector3> _reusableList = new List<Vector3>(100); // 预分配容量 void Update() { _reusableList.Clear(); // 清空复用，不分配新内存 _reusableList.Add(new Vector3(1,2,3)); // Vector3是结构体，在栈上分配，无GC // ... 使用_reusableList }

常见的GC分配源：new引用类型、字符串连接（使用StringBuilder）、LINQ查询（会产生迭代器）、某些Unity API（如GetComponent的某些重载返回数组）。使用Unity Profiler的Deep Profile模式可以精确追踪每一处托管堆分配。

2. 使用值类型（Struct）替代引用类型（Class）对于小型、短生命周期的数据，使用struct。它们分配在栈上，不会增加GC压力。例如，自定义的Point、RaycastHit简单数据。

3. 对象池（Object Pooling）对于频繁创建和销毁的游戏对象（如子弹、敌人、特效），使用对象池是必须的。Unity自2021版本起在UnityEngine.Pool命名空间下提供了ObjectPool<T>和ListPool<T>等官方池化工具，非常方便。

using UnityEngine.Pool; public class BulletPool : MonoBehaviour { public Bullet bulletPrefab; private ObjectPool<Bullet> _pool; void Start() { _pool = new ObjectPool<Bullet>( createFunc: () => Instantiate(bulletPrefab), actionOnGet: (bullet) => { bullet.gameObject.SetActive(true); bullet.Reset(); }, actionOnRelease: (bullet) => bullet.gameObject.SetActive(false), actionOnDestroy: (bullet) => Destroy(bullet.gameObject), defaultCapacity: 50 ); } public Bullet GetBullet() => _pool.Get(); public void ReleaseBullet(Bullet bullet) => _pool.Release(bullet); }

2.3.2 资产内存管理

1. 纹理与网格内存

检查纹理的Read/Write Enabled：这个选项会将纹理数据保留一份在内存中供CPU读写，会使内存占用翻倍。对于仅用于渲染的纹理，务必取消勾选。
网格（Mesh）压缩：在模型导入设置中，开启Mesh Compression可以减小网格数据的内存占用，但可能会引入精度误差，需要测试。
卸载未使用的资产：使用Resources.UnloadUnusedAssets()可以释放那些已经没有任何引用的资产（如切换场景后）。但调用此方法会触发一次性的性能开销，建议在加载界面或非关键时机调用。

2. AssetBundle与Addressables资源管理对于大型项目，必须使用动态资源加载。Unity的Addressables系统是当前推荐的最佳实践，它提供了强大的依赖管理、内存管理和远程加载能力。

关键：管理引用和生命周期。确保在不需要资源（如场景、UI面板）时，正确地释放（Release）对Addressable资源的引用。引用计数降为0时，资源才会被卸载。
使用Profiler的Memory模块中的Asset视图，可以清晰看到哪些纹理、网格、音频资产驻留在内存中，以及它们的引用路径，是排查内存泄漏的利器。

2.3.3 平台特定的内存考量

Android内存碎片化：Android系统的Java堆内存管理可能导致碎片化。对于Unity应用，应尽量在游戏启动初期就分配好大部分长期使用的内存，避免运行时频繁的大块内存申请释放。
iOS内存警告：iOS会向应用发送内存警告（DidReceiveMemoryWarning）。Unity会尝试通过垃圾回收和卸载资源来响应。你的代码应该监听此事件（可通过Application.lowMemory事件），并主动释放非关键资源（如缓存的高清纹理、非活动场景的资产）。

3. 跨平台优化实战：差异化策略与工具链

理解了CPU、GPU、内存的通用优化原则后，我们需要面对核心问题：PC和安卓的优化策略有何不同？如何用一套代码优雅地处理这些差异？

3.1 平台相关的代码与质量设置

Unity提供了Application.platform和SystemInfo类来区分平台和硬件能力。

1. 图形质量分级绝不应该在PC和手机上使用同一套图形质量设置。应在游戏启动时或设置菜单中，根据平台和硬件等级动态调整。

using UnityEngine; public class GraphicsQualityManager : MonoBehaviour { void Start() { // 示例：根据平台设置初始质量 if (Application.isMobilePlatform) { SetMobileQualityPreset(); } else { SetPCQualityPreset(); } // 更精细的：根据GPU型号分级 string gpuName = SystemInfo.graphicsDeviceName.ToLower(); if (Application.platform == RuntimePlatform.Android) { if (gpuName.Contains("adreno")) { // 高通骁龙GPU ConfigureForAdreno(); } else if (gpuName.Contains("mali")) { // ARM Mali GPU ConfigureForMali(); } } } void SetMobileQualityPreset() { QualitySettings.SetQualityLevel(1); // 对应Project Settings -> Quality中的“Medium”或自定义档位 // 关闭或降低特定效果 // 例如，在URP中： var urpAsset = GraphicsSettings.currentRenderPipeline as UniversalRenderPipelineAsset; if (urpAsset != null) { urpAsset.shadowDistance = 30f; // 减少阴影距离 urpAsset.msaaSampleCount = 2; // 使用2x MSAA或关闭 } Application.targetFrameRate = 30; // 移动端锁定30帧以节省电量 } void SetPCQualityPreset() { QualitySettings.SetQualityLevel(3); // “High”档位 Application.targetFrameRate = -1; // 不限制帧率 } }

2. 输入与控制PC有键盘鼠标，移动端是触摸屏。输入逻辑必须抽象。

public interface IInputService { Vector2 GetMovement(); bool GetFireButtonDown(); } public class PCInputService : IInputService { public Vector2 GetMovement() => new Vector2(Input.GetAxis("Horizontal"), Input.GetAxis("Vertical")); public bool GetFireButtonDown() => Input.GetMouseButtonDown(0); } public class MobileInputService : IInputService { public Vector2 GetMovement() { // 实现虚拟摇杆逻辑 return VirtualJoystick.Instance.Direction; } public bool GetFireButtonDown() => MobileButton.GetButtonDown("Fire"); } // 在游戏启动时注册正确的服务 void Start() { if (Application.isMobilePlatform) { ServiceLocator.Register<IInputService>(new MobileInputService()); } else { ServiceLocator.Register<IInputService>(new PCInputService()); } }

3.2 性能剖析（Profiling）工具链

优化离不开数据。你必须熟练使用以下工具：

1. Unity Profiler (编辑器 & 开发包)

CPU Usage：查看主线程、渲染线程、各系统模块的时间消耗。寻找耗时最长的函数。
GPU Usage：查看GPU各阶段的耗时（顶点处理、片元处理等）。需要图形API支持。
Rendering：查看Draw Call数量、SetPass Call数量、批处理节省的Draw Call。这是图形优化的核心面板。
Memory：查看托管堆、原生堆、资产、纹理、网格等内存占用。深色部分表示已分配，浅色部分表示空闲但未归还系统，是排查内存泄漏的关键。
Android Profiler：通过ADB连接真机，在Unity编辑器中实时分析运行在手机上的游戏性能。这是移动端优化的唯一真理来源，模拟器或编辑器的数据不可靠。

2. Unity Frame Debugger可以暂停游戏，逐帧、逐个Draw Call地查看渲染过程。它能直观地告诉你每一帧到底画了什么，合批是否成功，Overdraw是否严重。

3. Android GPU Inspector / Snapdragon Profiler / ARM Mobile Studio这些是硬件厂商提供的更底层的GPU性能分析工具。它们可以分析着色器指令耗时、纹理带宽、功耗等极其详细的信息。当Unity Profiler告诉你GPU是瓶颈时，可以用这些工具进行深度诊断。

3.3 构建与发布优化

1. IL2CPP vs Mono对于发布版本，始终选择IL2CPP作为脚本后端。IL2CPP将C#代码转换为C++，然后编译为原生代码，相比Mono有显著的性能提升（尤其是计算密集型代码）和更好的内存安全性。虽然构建时间更长，但这是移动端发布的标配。

2. 代码剥离（Code Stripping）在Player Settings -> Other Settings中，启用Strip Engine Code和设置适当的Managed Stripping Level（如High）。这会移除项目中没有用到的Unity引擎代码，减小包体和运行时内存占用。但需要充分测试，确保没有误删必要的反射或序列化相关代码。

3. 资产打包与压缩

纹理压缩格式：如前所述，针对Android选择ASTC，针对iOS选择ASTC或PVRTC。
网格压缩：启用网格压缩。
音频压缩：对于背景音乐使用Vorbis，对于短音效使用ADPCM，在质量和大小间权衡。

4. 实战案例：一个跨平台项目的优化历程

假设我们有一个简单的3D第三人称射击游戏，需要在PC（目标60fps）和主流安卓设备（目标30fps）上运行。

初始状态（PC端达标，安卓端卡顿）：

Profiler显示安卓端CPU主线程平均帧时间45ms（约22fps），GPU时间35ms。
内存峰值达到1.8GB（目标设备只有4GB RAM），频繁触发GC。

优化步骤：

第一步：CPU瓶颈分析通过Android Profiler连接真机，发现：

Update中大量使用GameObject.Find和GetComponent查找敌人。
物理更新频率为默认50Hz，消耗了大量CPU时间。
一个复杂的AI决策脚本每帧都在遍历所有敌人计算距离。

优化措施：

将所有Find和GetComponent调用移至Start或Awake中缓存。
将Fixed Timestep从0.02调整为0.033（30Hz）。
重构AI系统：将距离计算改为每5帧进行一次，并使用空间划分数据结构（如UnityEngine.Physics.OverlapSphereNonAlloc）来减少遍历范围。
为屏幕外的敌人AI启用Behaviour.enabled = false，停止其Update逻辑。

结果：CPU主线程时间从45ms降至28ms。

第二步：GPU与渲染瓶颈分析使用Frame Debugger和GPU Profiler发现：

Draw Call数高达300+。
场景中有大量独特的材质实例（即使纹理相同）。
后处理Bloom效果全屏应用，开销巨大。
角色皮肤使用了复杂的高光Shader。

优化措施：

静态合批：将场景中所有静态建筑、地形标记为Static，Draw Call从150+合并为12个。
材质合并：检查所有使用相同基础纹理的物体，确保它们共享同一个材质实例。对于需要不同颜色的物体，改用MaterialPropertyBlock。
简化Shader：将角色的复杂PBR Shader替换为URP Lit Shader，并关闭一些移动端不重要的特性（如次表面散射）。
调整后处理：将Bloom效果分辨率降至半分辨率，并降低强度。考虑在低端安卓设备上完全关闭Bloom。
启用GPU Instancing：对于场景中数百个相同的草丛模型，启用材质上的GPU Instancing，并使用脚本批量绘制。

结果：Draw Call降至80左右，GPU时间从35ms降至22ms。

第三步：内存与GC瓶颈分析Memory Profiler显示：

每帧有约40KB的托管堆分配，主要来自字符串操作和临时List创建。
一个特效系统在播放时不断Instantiate和Destroy粒子预制体。
一张1024x1024的UI图集被标记为Read/Write，内存占用翻倍。

优化措施：

消除每帧GC分配：使用StringBuilder重构字符串拼接逻辑；将临时List改为复用池化的List；避免在Update中使用LINQ。
实现对象池：为子弹、命中特效、敌人死亡特效实现对象池。
修复纹理设置：取消UI图集的Read/Write Enabled选项。
资源分级加载：使用Addressables，将首关卡资源标记为Preload，后续关卡资源标记为On Demand。

结果：内存峰值稳定在1.2GB，每帧GC分配降至2KB以下，GC触发频率从每秒数次降至每分钟一次，卡顿感基本消失。

最终状态：经过上述针对性优化，该游戏在目标安卓设备上能够稳定运行在30fps，内存使用平稳，发热情况也在可接受范围内。PC版本则通过更高的质量设置，依然保持60fps的流畅体验。

5. 常见问题排查与避坑指南

即使遵循了所有最佳实践，实际项目中仍会遇到诡异的问题。这里记录一些我踩过的“坑”和排查思路。

问题1：游戏在特定安卓机型上闪退，Profiler连接后一切正常。

可能原因：内存溢出（OOM）。Profiler工具本身会占用额外内存，可能“掩盖”了临界状态下的OOM问题。
排查：
1. 在Player Settings -> Other Settings中勾选Enable Internal Profiler。游戏运行时在Android Logcat中会输出简化的性能数据，包括内存使用情况。
2. 使用Android Studio的Profiler或adb shell dumpsys meminfo <package_name>命令，在不连接Unity Profiler的情况下监控应用的实际内存占用。
3. 重点检查纹理内存、AssetBundle泄漏、静态变量持有的大对象。

问题2：Draw Call已经很低了，但GPU Profiler显示片元着色器（Fragment）耗时依然很高。

可能原因：Overdraw（过度绘制）严重。即同一个像素被绘制了多次。
排查与解决：
1. 在Scene视图中，使用Overdraw渲染模式（通常需要在渲染管线资产中启用或使用自定义Shader）查看红色区域。
2. 检查UI层级：复杂的UI叠加是Overdraw的重灾区。确保UI面板在不需要时被禁用，合并UI元素。
3. 检查半透明物体排序：确保半透明物体按从后到前渲染，避免不必要的重绘。
4. 使用遮挡剔除（Occlusion Culling）：对于大型3D场景，正确设置Occlusion Area并烘焙，可以避免渲染被遮挡的物体。

问题3：游戏运行一段时间后越来越卡，重启后恢复。

可能原因：内存泄漏或资源泄漏。
排查：
1. 使用Unity Memory Profiler的Capture功能，在游戏开始时和运行一段时间后各抓取一个快照，然后进行对比（Compare）。查看哪些资产或对象数量异常增长。
2. 检查所有Subscribe的事件，在对象销毁时是否正确Unsubscribe。
3. 检查Coroutine是否被正确停止，无限循环的Coroutine可能持有对象引用导致无法释放。
4. 对于Addressables，确保每个LoadAssetAsync返回的AsyncOperationHandle在资源使用完毕后都调用了Release。

问题4：在低端安卓设备上，场景加载时间极长。

可能原因：同步加载大量资源阻塞主线程，或Shader变体编译卡顿。
解决：
1. 异步加载：将所有场景和资源加载改为异步操作（SceneManager.LoadSceneAsync,Addressables.LoadAssetAsync），并显示加载进度条。
2. Shader预暖（Warmup）：在加载场景时，首帧可能会因为编译新的Shader变体而卡顿。可以使用Shader.WarmupAllShaders在启动时或加载界面预编译所有可能的Shader变体，但这会增加初始加载时间。更精细的做法是分析并预加载当前关卡所需的Shader变体。
3. 资产分包：不要将所有资源打在一个巨大的AssetBundle里。按场景或功能模块分包，实现流式加载。

性能优化是一场永无止境的战斗，尤其是在硬件差异巨大的跨平台领域。没有银弹，只有对工具链的熟练掌握、对数据的敬畏之心，以及一次次“假设-验证-调整”的迭代过程。记住，最好的优化往往发生在设计阶段。在动手写第一行代码之前，就为你的目标平台（特别是性能最低的那一个）画好性能预算的蓝图，这比后期任何高超的优化技巧都更有效。最后，保持耐心，善用工具，让数据指引你的优化方向，而不是猜测。