1. 项目概述为什么对象池是Unity性能优化的基石如果你在Unity开发中遇到过游戏运行一段时间后越来越卡或者频繁加载/卸载对象时出现明显的卡顿甚至最终导致闪退那么你很可能正在经历内存管理的阵痛。尤其是在移动平台或需要处理大量瞬时对象的游戏如弹幕射击、割草游戏、开放世界动态生成中这个问题尤为突出。今天要聊的“对象池”就是解决这类问题的核心设计模式它不是Unity的某个内置功能而是一种编程思想但掌握它对于写出高性能、稳定的Unity应用至关重要。简单来说对象池Object Pooling的核心思想就是“复用”。想象一下一个公共游泳池与其让每个人游泳时都现场挖一个新池子游完再填平不如大家共用一个池子游完上来下一个人接着用。在Unity中“对象”就是我们的游戏物体GameObject或组件。频繁的Instantiate创建和Destroy销毁操作尤其是对于Prefab会触发垃圾回收Garbage Collection, GC而GC是导致游戏帧率骤降的元凶之一。对象池通过预先创建一批对象并存入一个“池子”中需要时从池中取出激活不需要时放回池中禁用从而避免了反复的创建与销毁极大地减轻了内存分配压力和GC负担。网上关于对象池的教程很多但大多停留在基础概念的讲解。本文将深入实战为你揭秘高效内存管理的五大核心技巧。这些技巧源于我在多个上线项目中踩过的坑和总结的经验旨在帮你构建一个不仅能用而且高效、稳定、易扩展的对象池系统。无论你是正在优化项目性能的资深开发者还是希望从一开始就打好基础的新手这些内容都将为你提供直接的帮助。2. 对象池的整体设计与架构思路在动手写代码之前理清设计思路至关重要。一个糟糕的对象池设计可能比不用对象池带来更多问题。我们的目标不是简单地实现“取”和“还”而是要构建一个健壮、高效、易于管理的系统。2.1 核心需求解析我们需要什么样的对象池首先我们需要明确一个生产级对象池需要满足哪些需求高性能的存取获取和回收对象必须是O(1)或接近O(1)的时间复杂度不能有性能瓶颈。灵活的类型支持不仅要能池化GameObject最好也能支持纯C#类对象如粒子系统、音频源、网络数据包等。动态扩容与收缩当池中对象不够用时能自动按需创建新对象当池中闲置对象过多时能适当销毁一部分以释放内存。清晰的生命周期管理对象从池中取出Spawn和放回Despawn时应有明确的初始化Reset和清理Cleanup机制。易用性与可维护性接口设计要直观便于团队其他成员使用。同时要易于监控和调试比如查看当前池的状态。基于这些需求一个常见的架构是设计一个通用的ObjectPoolT类然后针对GameObject进行一层封装形成GameObjectPool。同时需要一个中心化的PoolManager来管理所有的池子避免散落在代码各处。2.2 方案选型泛型与管理器模式为什么选择泛型泛型允许我们编写一个可以处理任何类型对象的池子逻辑提高了代码的复用性。ObjectPoolBullet、ObjectPoolParticleSystem都可以复用同一套核心算法。为什么需要PoolManager想象一下你的游戏里有子弹池、敌机池、特效池、音效池……如果没有一个统一的管理器你需要在不同的脚本里分别初始化和管理这些池这会导致内存泄漏风险场景切换时容易忘记清理池子。代码冗余每个池子的初始化、查找逻辑重复。调试困难当想查看所有池子的整体状态时无从下手。PoolManager作为一个单例Singleton负责所有池的创建、存储和销毁。它提供了统一的接口如PoolManager.Instance.GetPoolT()来获取或创建指定类型的池使得对象池的使用变得简洁而规范。3. 核心技巧一实现高效且安全的基础对象池让我们从最核心的泛型对象池开始。这里会涉及一些数据结构的选择和线程安全的考量。3.1 数据结构的选择为什么是Stack存储闲置对象我们常用StackT或QueueT。这里我强烈推荐使用StackT。原因在于对于对象池的存取模式我们通常只关心“拿一个可用的对象”而不关心它是先进先出还是后进先出。Stack的Push压栈和Pop出栈操作都是在集合的末端进行其算法复杂度是O(1)且内存开销相对较小。而Queue的Dequeue操作涉及内部数组的重排虽然也是O(1)但在某些实现细节上可能略逊一筹。当然如果你有“对象使用时长”相关的特殊需求比如想让最早回收的对象被优先复用可以使用Queue。using System.Collections.Generic; using UnityEngine; public class ObjectPoolT where T : class, new() { // 存储闲置对象的栈 private StackT pool new StackT(); // 一个可选的委托用于在对象取出时进行初始化 public System.FuncT CreateFunc { get; set; } // 一个可选的委托用于在对象放回时进行清理 public System.ActionT OnGetAction { get; set; } public System.ActionT OnReleaseAction { get; set; } // 从池中获取对象 public T Get() { T obj; if (pool.Count 0) { obj pool.Pop(); } else { // 如果池为空则创建新对象 if (CreateFunc ! null) obj CreateFunc(); else obj new T(); // 默认使用无参构造函数 } // 取出时执行初始化 OnGetAction?.Invoke(obj); return obj; } // 将对象放回池中 public void Release(T obj) { if (obj null) { Debug.LogWarning(尝试放回一个空对象到对象池。); return; } // 放回时执行清理 OnReleaseAction?.Invoke(obj); pool.Push(obj); } // 预创建对象填充池子 public void Prewarm(int count) { for (int i 0; i count; i) { T obj (CreateFunc ! null) ? CreateFunc() : new T(); OnReleaseAction?.Invoke(obj); // 注意预创建的对象应处于“放回”状态 pool.Push(obj); } } // 清空池子谨慎使用通常用于场景切换 public void Clear() { pool.Clear(); } public int CountInactive pool.Count; }注意事项线程安全上述基础实现不是线程安全的。如果你的对象池可能在多线程环境下被访问例如在服务器逻辑或使用了C# Job System你需要使用ConcurrentStackT或在Get/Release方法内部加锁。对于绝大多数Unity游戏客户端逻辑主线程单线程操作是安全的。对象的“状态”OnGetAction和OnReleaseAction这两个委托至关重要。它们定义了对象从“闲置”状态切换到“使用中”状态以及反向切换时需要执行的逻辑。例如对于一个GameObjectOnGet可能是SetActive(true)并重置位置OnRelease则是SetActive(false)。4. 核心技巧二构建面向GameObject的增强型池基础泛型池很好但直接用它来管理GameObject会有些不便。我们需要一个更贴合Unity使用习惯的封装。4.1 GameObjectPool的设计与实现GameObjectPool需要处理Prefab的实例化、父子节点管理等问题。它内部可以持有一个ObjectPoolGameObject但对外提供更友好的接口。public class GameObjectPool { private ObjectPoolGameObject internalPool; private GameObject prefab; private Transform parentTransform; // 所有池化对象的父节点用于保持场景树整洁 public GameObjectPool(GameObject prefab, int initialSize, Transform parent null) { this.prefab prefab; this.parentTransform parent; // 初始化内部泛型池并设置创建、获取、释放的委托 internalPool new ObjectPoolGameObject( createFunc: () { // 创建新实例 GameObject go GameObject.Instantiate(prefab); if (parentTransform ! null) go.transform.SetParent(parentTransform); go.SetActive(false); // 创建后默认处于禁用状态 return go; }, onGet: (go) { // 取出时激活 go.SetActive(true); }, onRelease: (go) { // 放回时禁用并重置位置可选 go.SetActive(false); go.transform.localPosition Vector3.zero; go.transform.localRotation Quaternion.identity; } ); // 预创建对象 internalPool.Prewarm(initialSize); } public GameObject Spawn(Vector3 position, Quaternion rotation) { GameObject go internalPool.Get(); Transform t go.transform; t.position position; t.rotation rotation; // 这里可以添加更多初始化逻辑例如调用对象上的特定脚本的Reset方法 var poolable go.GetComponentIPoolable(); poolable?.OnSpawn(); return go; } public void Despawn(GameObject go) { var poolable go.GetComponentIPoolable(); poolable?.OnDespawn(); internalPool.Release(go); } public void Clear() internalPool.Clear(); public int CountInactive internalPool.CountInactive; } // 一个可选的接口让池化对象自己管理状态 public interface IPoolable { void OnSpawn(); // 被取出时调用 void OnDespawn(); // 被放回时调用 }实操心得父节点管理将所有池化的GameObject放在一个统一的父节点下如“PooledObjects”可以极大地保持Hierarchy窗口的整洁方便调试和管理。特别是在对象数量很多的时候这个习惯非常重要。IPoolable接口这个接口提供了极大的灵活性。不是所有对象都只需要SetActive。一个敌人对象被回收时可能需要重置血量、清除状态机一个粒子特效对象可能需要停止当前的播放。让对象自己通过IPoolable接口处理这些细节符合“单一职责原则”使GameObjectPool的代码保持简洁。4.2 预加载Prewarm策略与容量管理对象池在第一次使用某个对象时如果池是空的仍然会触发Instantiate可能造成瞬时卡顿。因此在场景加载时或游戏开始前对高频使用的对象池进行“预加载”Prewarm是标准做法。如何确定预加载数量这需要结合游戏设计。例如玩家同时最多发射5发子弹 - 子弹池预加载10-15个留一些缓冲。屏幕上最多同时存在20个敌人 - 敌机池预加载25-30个。爆炸特效最多同时出现5个 - 特效池预加载8-10个。你可以通过游戏测试在性能分析器Profiler中观察Instantiate的调用情况来调整预加载数量目标是让游戏运行时尽可能少地动态创建新对象。动态扩容与收缩 一个健壮的池子不应该无限增长。如果因为某个峰值需求如瞬间爆发大量子弹导致池子扩容之后这些对象长期闲置就会浪费内存。我们可以实现一个简单的收缩策略定期检查例如每10秒如果闲置对象数量超过某个阈值例如初始预加载数量的2倍就销毁一部分将数量缩减到阈值附近。// 在GameObjectPool或一个管理器中添加收缩逻辑 public void TryShrink(int maxIdleCount) { int toDestroy internalPool.CountInactive - maxIdleCount; if (toDestroy 0) { for (int i 0; i toDestroy; i) { GameObject go internalPool.Get(); // 取出来是为了销毁 GameObject.Destroy(go); } // 注意这里从internalPool中Get后直接Destroy了没有Release回去。 // 这意味着internalPool内部的计数会减少。我们的泛型池需要支持“取出并丢弃”的操作。 // 更优雅的做法是在ObjectPoolT中增加一个DestroyFromPool方法直接操作内部栈。 } }注意收缩策略需要谨慎设计触发频率和阈值避免在性能敏感时段如战斗高潮进行销毁操作反而引发GC。通常可以在游戏相对平静的时段如菜单界面进行。5. 核心技巧三通过PoolManager实现集中化与自动化管理当项目中有几十上百个对象池时手动管理它们将成为噩梦。一个中心化的PoolManager是必不可少的。5.1 PoolManager的单例实现与池字典PoolManager的核心是一个字典以Prefab或类型作为Key以对应的对象池作为Value。using System.Collections.Generic; using UnityEngine; public class PoolManager : MonoBehaviour { public static PoolManager Instance { get; private set; } [SerializeField] private PoolConfig[] poolConfigs; // 可在Inspector中配置的池信息 private DictionaryGameObject, GameObjectPool gameObjectPools new DictionaryGameObject, GameObjectPool(); private DictionarySystem.Type, object genericPools new DictionarySystem.Type, object(); // 用于存储泛型池 [System.Serializable] public class PoolConfig { public GameObject prefab; public int initialSize 10; public Transform customParent; // 可指定自定义父节点 } private void Awake() { if (Instance ! null Instance ! this) { Destroy(this.gameObject); return; } Instance this; DontDestroyOnLoad(this.gameObject); // 通常希望PoolManager跨场景存在 InitializePools(); } private void InitializePools() { foreach (var config in poolConfigs) { CreatePoolInternal(config.prefab, config.initialSize, config.customParent); } } private GameObjectPool CreatePoolInternal(GameObject prefab, int size, Transform parent) { if (gameObjectPools.ContainsKey(prefab)) { Debug.LogWarning($对象池已存在: {prefab.name}); return gameObjectPools[prefab]; } Transform poolParent parent ! null ? parent : CreatePoolParent(prefab.name); var pool new GameObjectPool(prefab, size, poolParent); gameObjectPools[prefab] pool; return pool; } private Transform CreatePoolParent(string poolName) { GameObject parentGo new GameObject($[Pool]_{poolName}); parentGo.transform.SetParent(this.transform); // 作为PoolManager的子物体 return parentGo.transform; } // 对外提供的Spawn接口 public GameObject Spawn(GameObject prefab, Vector3 position, Quaternion rotation) { if (!gameObjectPools.TryGetValue(prefab, out GameObjectPool pool)) { // 如果池不存在则动态创建一个使用默认初始大小如5 pool CreatePoolInternal(prefab, 5, null); } return pool.Spawn(position, rotation); } // 便捷方法 public GameObject Spawn(GameObject prefab) Spawn(prefab, Vector3.zero, Quaternion.identity); public GameObject Spawn(GameObject prefab, Transform parent) { GameObject go Spawn(prefab); go.transform.SetParent(parent); return go; } // 对外提供的Despawn接口 public void Despawn(GameObject obj) { // 这里需要一个机制来找到obj属于哪个池。 // 常见做法在池化对象上挂一个脚本记录其来源Prefab或PoolID。 PoolMember member obj.GetComponentPoolMember(); if (member ! null member.sourcePool ! null) { member.sourcePool.Despawn(obj); } else { // 如果没有标记尝试通过遍历字典来查找效率低不推荐 // 或者直接Destroy如果确定不是池化对象 Debug.LogWarning($尝试回收一个未标记池来源的对象: {obj.name}将直接Destroy。); GameObject.Destroy(obj); } } // 清理所有池场景切换时调用 public void ClearAllPools() { foreach (var pool in gameObjectPools.Values) { pool.Clear(); } gameObjectPools.Clear(); // 也可以选择不Clear字典只清空池内对象保留池结构以备后用 } } // 挂在每个池化GameObject上的脚本用于标识其来源 public class PoolMember : MonoBehaviour { public GameObjectPool sourcePool; // 或者在Awake时自动查找设置 }使用方式 现在在游戏的任何地方生成和回收对象变得异常简单// 生成一个子弹 GameObject bullet PoolManager.Instance.Spawn(bulletPrefab, firePosition, fireRotation); bullet.GetComponentRigidbody().velocity transform.forward * speed; // ... 子弹击中目标或飞出屏幕后 ... PoolManager.Instance.Despawn(bullet); // 而不是Destroy(bullet)5.2 自动化回收与生命周期挂钩手动调用Despawn容易遗漏导致对象“泄漏”一直处于激活状态但已不被需要。我们可以实现一些自动化回收机制基于时间的回收对于特效这类有明确生命周期的对象可以在OnSpawn时启动一个协程或计时器时间到了自动调用Despawn。public class AutoDespawn : MonoBehaviour, IPoolable { public float lifeTime 2.0f; private Coroutine despawnCoroutine; public void OnSpawn() { if (despawnCoroutine ! null) StopCoroutine(despawnCoroutine); despawnCoroutine StartCoroutine(DespawnAfterTime(lifeTime)); } public void OnDespawn() { if (despawnCoroutine ! null) { StopCoroutine(despawnCoroutine); despawnCoroutine null; } } IEnumerator DespawnAfterTime(float time) { yield return new WaitForSeconds(time); PoolManager.Instance.Despawn(this.gameObject); } }基于事件的回收例如子弹的OnCollisionEnter事件、粒子系统的OnParticleSystemStopped事件都是触发回收的好时机。public class Projectile : MonoBehaviour, IPoolable { private void OnTriggerEnter(Collider other) { // 处理击中逻辑... PoolManager.Instance.Despawn(this.gameObject); } public void OnSpawn() { /* 重置速度、伤害等 */ } public void OnDespawn() { /* 清理 */ } }屏幕外回收对于会移动出屏幕的对象如子弹、敌机可以添加一个脚本定期检查其位置是否在摄像机视野外如果是则回收。将这些自动化策略与IPoolable接口结合可以大大减少手动管理的工作量并降低出错概率。6. 核心技巧四性能监控、调试与高级优化对象池用上了但怎么知道它是否真的在高效工作我们需要监控和调试工具。6.1 实时监控与统计信息我们可以扩展PoolManager使其能够输出每个池的实时状态例如总创建数、当前活跃数、当前闲置数、历史峰值活跃数等。这些信息可以在开发时通过屏幕GUI显示或者输出到日志文件。// 在PoolManager中增加统计结构和方法 [System.Serializable] public class PoolStats { public GameObject prefab; public int totalCreated; // 总共创建过的对象数包括已销毁的 public int activeCount; public int inactiveCount; public int peakActiveCount; } private DictionaryGameObject, PoolStats statsDict new DictionaryGameObject, PoolStats(); // 在Spawn和Despawn时更新统计 public GameObject Spawn(GameObject prefab, Vector3 pos, Quaternion rot) { // ... 获取或创建pool ... GameObject go pool.Spawn(pos, rot); // 更新统计 if (!statsDict.ContainsKey(prefab)) statsDict[prefab] new PoolStats { prefab prefab }; var stats statsDict[prefab]; stats.activeCount; stats.inactiveCount pool.CountInactive; stats.totalCreated; stats.peakActiveCount Mathf.Max(stats.peakActiveCount, stats.activeCount); return go; } public void Despawn(GameObject obj) { // ... 找到pool并回收 ... pool.Despawn(obj); // 更新统计 (需要通过obj反查prefab这需要PoolMember记录prefab引用) PoolMember member obj.GetComponentPoolMember(); if (member ! null member.sourcePrefab ! null) { var stats statsDict[member.sourcePrefab]; stats.activeCount--; stats.inactiveCount pool.CountInactive; } } // 提供一个方法获取所有统计信息用于显示 public DictionaryGameObject, PoolStats GetAllStats() new DictionaryGameObject, PoolStats(statsDict);在编辑器里你甚至可以创建一个自定义的Editor窗口实时显示这些数据并可以一键清理所有池方便调试。6.2 内存与GC优化深度剖析对象池的主要目标是减少GC。我们可以使用Unity Profiler的Deep Profile模式来验证。验证GC触发频率在不用对象池时频繁发射子弹观察Profiler中GC.Collect的调用频率和耗时。使用对象池后再次测试应该看到GC调用大幅减少甚至消失在池子容量足够且无其他内存分配的情况下。监控堆内存分配在Profiler的CPU Usage区域关注GC Alloc列。理想情况下游戏稳定运行后对象池已预热每帧的GC Alloc应该非常低且稳定。任何意外的峰值都意味着有新的内存分配需要排查可能是字符串拼接、LINQ查询、闭包等非对象池相关的分配。高级优化技巧池化一切可池化的不仅仅是GameObject。考虑池化ListT、DictionaryK,V、Mesh、MaterialPropertyBlock等。任何需要频繁创建和销毁的C#对象都可以成为池化候选。Unity 2021 LTS之后甚至提供了CollectionPool等API来帮助池化集合。避免在热路径上分配内存即使在对象池内部也要小心。例如在Get方法中使用的Lambda表达式委托如果捕获了外部变量可能会导致内存分配。如果性能要求极其苛刻可以考虑使用静态方法或预定义的委托实例来避免。使用ArrayPoolT和MemoryPoolT对于字节数组等基础类型数组.NET Core和.NET Standard 2.1提供了System.Buffers.ArrayPoolT这是一个高性能的共享数组池比自定义池更高效。7. 核心技巧五应对复杂场景与陷阱规避对象池并非银弹在复杂场景下使用不当会引入新的问题。7.1 场景切换与DDOLDontDestroyOnLoad对象的处理如果你的PoolManager是DontDestroyOnLoad的那么池中的所有对象在场景切换时依然存在。这通常是我们期望的避免了重复加载Prefab。但是你需要小心场景引用残留如果池化的对象持有对旧场景中对象的引用例如一个子弹脚本保存了发射者的Transform在新场景中这些引用可能无效或指向错误的对象。必须在OnDespawn或IPoolable.OnDespawn中彻底清理所有对外部对象的引用将脚本状态重置到“出厂设置”。全局池与局部池有些对象只属于特定场景如某个关卡独有的机关。对于这类对象最好使用局部池并在场景卸载时在OnDestroy中清理对应的池。可以在PoolManager中通过给池子打标签Tag或分组Group来管理。7.2 对象池的“脏状态”与重置策略这是对象池最容易出错的地方。对象被回收时可能处于任何状态血量不为满、动画播放到一半、协程正在运行、物理力还在作用等等。如果不清除这些状态下次取出时就会带着上一次的“残留”导致诡异的Bug。全面的重置清单 在IPoolable.OnDespawn或GameObjectPool的onRelease委托中必须系统性地重置对象Transform重置位置、旋转、缩放。localPosition、localRotation、localScale。Rigidbody / Rigidbody2D重置速度(velocity)、角速度(angularVelocity)停止所有力(Sleep()或ResetForces()。Animator如果使用Animator调用Rebind()来重置所有动画状态或者播放一个空闲状态。粒子系统调用Clear()和Stop(true)。音频源调用Stop()。所有自定义脚本的变量将血量、状态、计时器、目标引用等重置为默认值。协程如果对象启动了任何协程必须在OnDespawn中停止它们(StopAllCoroutines()。取消调用Invoke如果有通过Invoke或InvokeRepeating安排的方法用CancelInvoke()取消。一个健壮的做法是为所有可池化的Prefab创建一个基类脚本强制实现完整的重置逻辑。7.3 常见问题排查速查表在实际使用中你可能会遇到以下问题这里提供快速的排查思路问题现象可能原因排查与解决思路对象取出后状态不对如血量是残的位置是上次的OnDespawn重置不彻底。检查IPoolable.OnDespawn或池子的onRelease委托确保所有状态被重置。使用调试器查看对象被回收时的状态。对象没有被回收导致越积越多1. 忘记调用Despawn。2. 自动化回收条件未触发如出屏检测失效。3.PoolMember脚本丢失或sourcePool未正确赋值。1. 检查逻辑确保所有分支都调用了Despawn。2. 调试自动化回收脚本。3. 确保PoolMember在对象被池化时正确附加和配置。调用Despawn后对象没有禁用或消失Despawn方法没有正确调用池子的回收逻辑或者对象被其他脚本意外激活。在PoolManager.Despawn和GameObjectPool.Despawn中打断点查看执行路径。检查是否有其他脚本在Update中又激活了该对象。游戏运行一段时间后变卡1. 对象池动态扩容过于频繁产生了大量闲置对象占内存。2. 有非池化对象在频繁创建销毁。3. GC由其他原因引起如字符串、LINQ。1. 检查池子统计看是否有池子闲置对象过多调整预加载大小或实现收缩策略。2. 用Profiler的Deep Profile定位内存分配源头。3. 优化代码避免在每帧分配新内存。场景切换后旧场景的池化对象出现在新场景PoolManager是DDOL且池化对象没有在场景切换时被清理。如果对象是场景专用的应在场景卸载时调用PoolManager.Instance.ClearPoolForScene(scene)来清理特定池。或者在对象的IPoolable.OnDespawn中更严格地清理场景相关引用。8. 实战扩展将对象池思想应用于非GameObject对象池模式的价值远不止于管理GameObject。在Unity中任何昂贵的创建操作都可以从池化中受益。案例粒子系统池虽然粒子系统通常挂在GameObject上但我们可以单独池化ParticleSystem组件尤其是当我们需要播放大量相同特效但又不希望产生大量GameObject开销时。我们可以创建一个ParticleSystemPool管理一组ParticleSystem实例需要时从池中取一个系统将其transform设置到目标位置然后调用Play()。案例网络消息包池在网络游戏中需要频繁创建和解析数据包。我们可以池化表示数据包的C#类对象。这避免了每次收发数据都new一个新的对象减少了GC压力。public class NetworkPacket { public int PacketId; public byte[] Data; // ... 其他字段 ... public void Reset() { PacketId 0; if (Data ! null) Array.Clear(Data, 0, Data.Length); // ... 重置其他字段 ... } } // 使用泛型对象池 ObjectPoolNetworkPacket packetPool new ObjectPoolNetworkPacket( createFunc: () new NetworkPacket(), onGet: p { /* 可能不需要特殊操作 */ }, onRelease: p p.Reset() // 关键回收时重置内容 ); // 发送消息时 var packet packetPool.Get(); // ... 填充packet数据 ... Send(packet); // 发送完成后假设我们知道可以回收了例如确认发送成功 packetPool.Release(packet);将对象池作为一种底层基础设施思维审视你项目中的性能热点往往会发现更多可以优化的地方。它不仅仅是一个工具类更是一种提升代码性能和可维护性的设计哲学。从我个人的经验来看在项目早期就引入一套完善的对象池管理系统能为后续的性能优化打下坚实的基础避免在项目后期陷入内存和GC问题的泥潭。