1. 从一次内存泄漏说起为什么游戏对象管理值得单独拎出来讲前阵子帮一个独立团队看他们的项目游戏跑到第三关帧率突然从60掉到22用性能分析工具一抓发现场景里堆了四千多个已经死亡的敌人对象每个还挂着动画组件和碰撞体。代码里明明调了销毁为什么对象还在追下去才发现他们的对象池回收逻辑只把对象标记为未激活但引用计数没清零GC垃圾回收根本不敢动它。这个问题折腾了他们整整一周最后改了三行代码解决。这件事让我意识到游戏对象与资源管理这块看起来是引擎里最基础的部分实际上是最容易埋雷的地方。你写业务逻辑的时候感觉不到它一旦项目规模上来对象数量从几百涨到几万资源从几十个涨到几千个管理机制的设计缺陷就会像水管里的水垢一样慢慢把性能堵死。这篇内容我想聊的是游戏引擎架构里游戏对象与资源管理这一层到底该怎么理解。它解决的核心问题是如何用一套统一的机制去描述游戏世界里所有会动、会变、会消失的东西同时保证这些东西占用的内存和CPU时间是可预测、可回收的。适合谁看如果你正在自己写小引擎、正在用Unity或Unreal做中大型项目、或者单纯好奇游戏里的一个角色在代码层面到底是个什么东西这篇都能给你一些可以直接抄作业的思路。我会从对象模型的设计取舍讲起一路聊到资源生命周期、引用计数、对象池、序列化最后给一套我实际用过的排查清单。全程不堆术语尽量用你打开引擎源码会看到什么的视角来讲。2. 游戏对象到底是什么三种主流对象模型的取舍逻辑2.1 从一个角色到一棵树组合优于继承的必然性新手最容易犯的错是把游戏对象设计成一个大类。比如写一个GameObject基类然后Enemy继承它FlyingEnemy继承EnemyFlyingBossEnemy再继承FlyingEnemy。刚开始很爽代码复用看起来很美。但做到第三个项目你就会发现某个Boss既会飞又会召唤还带护盾你根本不知道该把它挂在继承树的哪个位置。这就是经典的继承爆炸。现代引擎几乎都转向了组合模式。一个游戏对象本身几乎什么都不做它只是一个容器里面挂着一堆组件Component。位置组件管坐标渲染组件管画出来碰撞组件管物理脚本组件管逻辑。你想让一个敌人会飞不是去改继承树而是给它加一个FlightComponent。这个思路的学名叫实体-组件-系统ECS的前身但即使不是纯ECS架构组合的思路也是通用的。我自己的经验是对象本身只保留身份标识ID和组件列表所有能力都通过组件提供。这样做的直接好处是当你需要一个既像A又像B的东西时不需要纠结继承关系直接拼组件就行。代价是组件之间的通信需要额外设计比如一个组件怎么知道另一个组件的数据变了这个后面会讲。2.2 对象标识为什么不能用指针当ID很多自研引擎早期会用对象指针作为唯一标识觉得方便。但这里有个大坑对象被销毁后指针变成野指针如果你在别的地方还存着这个指针访问时要么崩溃要么读到脏数据。更麻烦的是对象池——对象被回收后内存还在指针地址没变但里面的数据已经是别人的了你拿着旧指针访问逻辑上完全错乱。正确的做法是给每个对象分配一个单调递增的整数ID所有跨对象的引用都存ID而不是指针。引擎内部维护一张ID到对象地址的映射表。对象销毁时ID标记为失效映射表里对应项清空。这样即使对象池复用了内存旧ID也不会指向新对象。代价是每次访问都要查一次表但这个开销在现代CPU上完全可以接受换来的是内存安全。提示ID的位宽要提前规划。32位ID能表示约42亿个对象听起来够用但如果你每秒创建销毁几千个对象跑上几个月就可能溢出。我见过一个项目因为ID用16位长时间运行后ID回绕导致新对象和旧对象ID冲突出现幽灵敌人。建议至少用64位或者用32位但配合分代机制。2.3 场景图与扁平列表父子关系该不该有游戏对象之间经常有层级关系比如角色身上挂着一把枪枪跟着角色动。最自然的做法是场景图Scene Graph每个对象有父节点和子节点列表变换矩阵从根节点一路乘下来。这个结构直观做编辑器的时候特别好用拖拽就能建立父子关系。但场景图有个性能问题每次查询一个对象的世界坐标都要沿着父链往上乘矩阵。如果层级很深比如一个对象在第五层每次查询要乘五次矩阵。在需要频繁查询世界坐标的场景比如物理碰撞检测这个开销会累积。所以很多引擎采用混合方案编辑器里保留场景图方便操作运行时把层级关系拍平成扁平列表每个对象缓存自己的世界变换矩阵父节点变换改变时才批量更新子节点。Unity的Transform层级就是这么做的它内部有脏标记机制只有变换真的变了才重算。这个设计的核心思想是用空间换时间用缓存换实时计算。3. 资源管理的核心矛盾谁来决定一个资源什么时候该被释放3.1 手动释放、GC、引用计数三条路各有各的坑资源管理和对象管理最大的区别在于对象是逻辑概念资源是实实在在占内存的东西——纹理、模型、音频、着色器。一个2K纹理可能占16MB显存一个角色模型可能几十MB。这些东西不释放显存很快就爆了。手动释放最直接谁加载谁释放。但项目一大代码路径一多你根本记不住哪个资源在哪个模块被引用。A模块释放了B模块还在用直接崩溃。GC垃圾回收省心但GC的停顿对游戏来说是致命的一帧卡200毫秒玩家直接骂娘。引用计数是折中方案每个资源记录有多少地方在引用它引用数归零就释放。听起来完美但循环引用会让计数永远不归零导致内存泄漏。我实际项目里的做法是引用计数为主配合弱引用打破循环。比如A引用BB又引用A那就让其中一方用弱引用不增加计数。引擎提供两种引用句柄强引用句柄增加计数弱引用句柄不增加但能检测资源是否还活着。这样既避免了GC停顿又能处理循环引用。3.2 资源加载的异步化为什么同步加载是原罪早期引擎加载资源是同步的调用LoadTexture(xxx.png)函数返回时纹理已经在内存里了。这在加载场景时没问题但在游戏运行中动态加载就会卡帧。一个100MB的模型同步加载可能要几百毫秒玩家看到的就是画面冻住。异步加载的核心是把请求资源和使用资源分开。你发起一个加载请求拿到一个占位句柄资源真正加载完成后句柄才变成可用状态。这期间游戏继续跑等资源好了再替换。听起来简单但实际做起来要处理很多边界情况资源加载失败怎么办加载到一半场景切换了怎么办同一个资源被多个地方同时请求要不要合并请求我的经验是加载请求要带优先级和取消机制。玩家当前视野内的资源高优先级远处的低优先级。场景切换时旧场景的加载请求全部取消避免浪费带宽和内存。同一个资源的多个请求合并成一个加载完成后通知所有请求方。这套机制做下来动态加载基本不会造成可感知的卡顿。3.3 资源热重载开发期的效率倍增器这个功能在发布版本里没有但在开发期极其重要。美术改了一张纹理你不想重启游戏就能看到效果。资源热重载就是监听资源文件的变化文件一改就重新加载并替换掉所有引用这个资源的地方。实现的关键是资源句柄的间接性。如果代码里直接持有纹理对象指针热重载后指针就失效了。正确做法是持有资源句柄句柄内部指向真正的资源对象。热重载时只替换句柄指向的对象所有持有句柄的代码无感知。这个设计和前面说的对象ID是同一个思路永远不要直接持有会变的东西持有一个稳定的间接层。注意热重载在移动端要谨慎使用。移动设备的文件监听机制和桌面不同频繁的文件IO可能影响性能。而且热重载会打乱资源的内存布局如果项目对内存碎片敏感建议只在编辑器里开真机上关掉。4. 对象池不是万能药用错地方比不用还糟4.1 对象池真正解决的问题是什么对象池经常被当成性能优化银弹但我见过太多项目无脑上对象池结果代码复杂度飙升性能反而下降。对象池真正解决的问题只有一个频繁创建销毁对象带来的内存分配和GC压力。如果你的游戏每秒创建销毁几十个子弹那对象池有意义。如果你的游戏一关只创建几个敌人用对象池纯属自找麻烦。判断标准很简单用性能分析工具看Instantiate和Destroy的调用频率和耗时。如果这两个函数在帧分析里占比超过5%才考虑对象池。否则优先优化其他部分。4.2 池的预热、扩容与收缩策略决定用对象池之后第一个问题是池子初始多大。太小了运行时要动态扩容扩容本身就有分配开销太大了浪费内存。我的做法是根据历史峰值预热。比如子弹池先跑一遍最激烈的战斗场景记录同时存在的子弹最大数量按这个数量的1.2倍预热。这样正常游戏过程中基本不会触发扩容。扩容策略要设置上限。如果池子满了还在请求要么阻塞等待要么临时创建新对象超出池子管理要么直接拒绝。我倾向于临时创建但标记为池外对象回收时直接销毁而不是放回池子。这样既不会因为池子太小导致逻辑卡住又不会让池子无限膨胀。收缩策略是很多人忽略的。游戏从战斗场景回到主菜单子弹池里几百个对象还占着内存。这时候应该根据当前场景需求把池子收缩到合理大小。收缩的时机可以选在场景切换时或者内存压力大的时候。4.3 池化对象的重置陷阱对象从池子里取出来复用时必须重置到初始状态。但初始状态的定义很容易出错。位置、旋转、缩放要重置这个大家都知道。但组件内部的状态呢比如一个敌人对象它的血量、AI状态机、动画播放进度、粒子特效发射器这些都要重置。漏掉任何一个就会出现复活的敌人还带着上次死亡时的动画这种诡异bug。我的做法是给每个可池化对象定义一个ResetForReuse()方法里面按固定顺序重置所有状态。这个方法的维护成本很高每次给对象加新组件都要记得更新它。所以更好的做法是让组件自己负责重置对象池回收时遍历所有组件调用组件的OnRecycle()取出时调用OnReuse()。这样新增组件时只需要实现这两个接口不会漏。5. 序列化与场景管理对象怎么存下来、怎么读回来5.1 序列化的本质把内存里的对象图变成字节流游戏存档、场景文件、预制体本质上都是序列化。序列化要解决的核心问题是内存里的对象是一张复杂的图对象之间有引用关系怎么把这整张图变成一串字节存到硬盘上之后还能原样恢复。最直接的做法是给每个对象分配一个序列化ID序列化时把对象的所有属性写进去遇到引用就写被引用对象的ID。反序列化时先创建所有对象此时属性为空再根据ID建立引用关系最后填充属性。这个两阶段过程很关键因为对象之间可能互相引用不先创建所有对象就没法建立引用。但这里有个坑不是所有属性都需要序列化。比如运行时的缓存数据、临时计算结果、指向系统内部对象的引用这些序列化了反而会出问题。所以需要给属性加标记明确哪些参与序列化。Unity用[SerializeField]Unreal用UPROPERTY自研引擎也要有类似的机制。5.2 场景切换时的资源生命周期场景切换是资源管理最容易出问题的地方。旧场景的资源要释放新场景的资源要加载这中间有个过渡期。如果处理不好要么旧资源释放太早导致新场景还在用要么释放太晚导致内存峰值过高。我的做法是分阶段释放。场景切换开始时先标记旧场景的所有资源为待释放但不立即释放。新场景开始加载加载完成后检查哪些旧资源还被新场景引用比如共享的纹理这些保留其余的释放。这个检查依赖引用计数所以前面说的引用计数机制在这里就派上用场了。还有一种情况是无缝大世界。玩家从区域A走到区域BA的资源要卸载B的资源要加载但玩家感觉不到切换。这需要更精细的流式加载策略根据玩家位置和移动方向预测接下来可能需要的资源提前加载离开一定距离的资源延迟卸载。这个延迟很重要因为玩家可能走回头路立即卸载会导致回头时又要重新加载。5.3 预制体与实例化模板与实例的关系预制体Prefab是游戏开发里非常实用的概念你做一个敌人模板存成文件然后在场景里实例化多个。每个实例共享模板的资源纹理、模型但有自己的属性位置、血量。这本质上是一种写时复制Copy-on-Write策略。实现的关键是区分共享数据和实例数据。共享数据放在模板里所有实例指向同一份实例数据每个实例独立。当实例修改了某个属性如果这个属性原本是共享的就要把它复制一份变成实例独有。这个机制在Unity里叫预制体覆盖在自研引擎里需要自己实现。提示预制体嵌套是复杂度飙升的源头。A预制体里包含B预制体B预制体里又包含C预制体修改C会影响所有包含C的B进而影响所有包含B的A。这个影响链在项目后期会变得难以追踪。我的建议是预制体嵌套不要超过两层超过两层就考虑用代码动态组装而不是静态嵌套。6. 实战排查清单对象与资源问题的定位思路6.1 内存泄漏的排查链路内存泄漏是对象资源管理最典型的问题。排查思路是先定位泄漏类型再定位泄漏对象最后定位泄漏原因。第一步用内存分析工具看内存增长曲线。如果内存持续增长不回落基本可以确定泄漏。第二步抓两次内存快照对比哪些对象数量在增长。第三步看这些对象的引用链找到是谁在持有它们。常见的泄漏原因有这么几类事件监听没取消对象销毁了但还被事件系统引用、协程没停止协程持有对象引用、静态容器没清理全局列表里还存着已销毁对象、循环引用导致引用计数不归零。我遇到最多的是事件监听没取消因为写代码时很容易忘记在OnDestroy里反注册。6.2 资源重复加载的识别与合并同一个资源被加载了多次是另一个常见问题。比如两个模块各自加载了同一张纹理内存里就有两份。这个问题在项目初期不明显资源少的时候浪费不大但资源多了之后可能浪费几百MB。识别方法是给每个资源算一个唯一键通常是文件路径的哈希加载时先查缓存缓存里有就直接返回没有才真正加载。这个缓存就是资源管理器。关键是所有资源加载都必须走资源管理器不能有绕过它直接读文件的代码。我见过项目里有人为了图方便直接File.ReadAllBytes加载配置结果配置更新后缓存里的旧版本还在用出现数据不一致。6.3 帧率波动的对象池视角帧率周期性波动很多时候和对象池有关。池子扩容的那一帧因为要分配大量内存帧时间会突然升高。如果扩容频繁发生就会看到帧率规律性地掉。解决办法是把扩容分散到多帧。不要一次创建100个对象而是每帧创建10个分10帧完成。这样单帧开销小玩家感知不到。同时调整预热数量让扩容尽量少发生。如果实在无法避免扩容可以在加载界面提前扩容而不是在游戏过程中。另一个帧率波动源是批量销毁。比如一波敌人同时死亡同时触发销毁和回收那一帧的开销会很大。可以把销毁操作排队每帧处理固定数量平滑开销。7. 我踩过的几个坑和对应的解法第一个坑是对象池里的对象被外部引用。子弹从池子里取出来发射逻辑里存了子弹的引用子弹回收后引用还在下次访问就是脏数据。解法是回收时把所有外部引用置空或者用句柄代替直接引用句柄能检测对象是否有效。第二个坑是资源引用计数在异步加载时算错。发起异步加载时增加计数加载完成前如果引用方销毁了计数没减资源永远不释放。解法是异步加载的句柄也要遵循引用计数规则取消加载时减计数。第三个坑是场景切换时旧场景的协程还在跑。协程里访问已销毁的对象直接报错。解法是场景切换时停止所有属于该场景的协程或者协程里访问对象前先检查有效性。第四个坑是预制体实例化时的资源竞争。多个地方同时实例化同一个预制体如果预制体内部的资源是懒加载的可能触发多次加载。解法是预制体实例化时预加载所有依赖资源或者资源加载本身做请求合并。这些坑的共同点是它们都不会在项目初期暴露而是在对象数量、资源数量、并发操作达到一定规模后才出现。所以对象与资源管理的设计不能只看当前需求要预留扩展空间。我个人的原则是ID用64位、引用计数默认开启、对象池按需使用、所有资源加载走统一入口。这四条看起来简单但能避开后面80%的坑。
1. 从一次内存泄漏说起为什么游戏对象管理值得单独拎出来讲前阵子帮一个独立团队看他们的项目游戏跑到第三关帧率突然从60掉到22用性能分析工具一抓发现场景里堆了四千多个已经死亡的敌人对象每个还挂着动画组件和碰撞体。代码里明明调了销毁为什么对象还在追下去才发现他们的对象池回收逻辑只把对象标记为未激活但引用计数没清零GC垃圾回收根本不敢动它。这个问题折腾了他们整整一周最后改了三行代码解决。这件事让我意识到游戏对象与资源管理这块看起来是引擎里最基础的部分实际上是最容易埋雷的地方。你写业务逻辑的时候感觉不到它一旦项目规模上来对象数量从几百涨到几万资源从几十个涨到几千个管理机制的设计缺陷就会像水管里的水垢一样慢慢把性能堵死。这篇内容我想聊的是游戏引擎架构里游戏对象与资源管理这一层到底该怎么理解。它解决的核心问题是如何用一套统一的机制去描述游戏世界里所有会动、会变、会消失的东西同时保证这些东西占用的内存和CPU时间是可预测、可回收的。适合谁看如果你正在自己写小引擎、正在用Unity或Unreal做中大型项目、或者单纯好奇游戏里的一个角色在代码层面到底是个什么东西这篇都能给你一些可以直接抄作业的思路。我会从对象模型的设计取舍讲起一路聊到资源生命周期、引用计数、对象池、序列化最后给一套我实际用过的排查清单。全程不堆术语尽量用你打开引擎源码会看到什么的视角来讲。2. 游戏对象到底是什么三种主流对象模型的取舍逻辑2.1 从一个角色到一棵树组合优于继承的必然性新手最容易犯的错是把游戏对象设计成一个大类。比如写一个GameObject基类然后Enemy继承它FlyingEnemy继承EnemyFlyingBossEnemy再继承FlyingEnemy。刚开始很爽代码复用看起来很美。但做到第三个项目你就会发现某个Boss既会飞又会召唤还带护盾你根本不知道该把它挂在继承树的哪个位置。这就是经典的继承爆炸。现代引擎几乎都转向了组合模式。一个游戏对象本身几乎什么都不做它只是一个容器里面挂着一堆组件Component。位置组件管坐标渲染组件管画出来碰撞组件管物理脚本组件管逻辑。你想让一个敌人会飞不是去改继承树而是给它加一个FlightComponent。这个思路的学名叫实体-组件-系统ECS的前身但即使不是纯ECS架构组合的思路也是通用的。我自己的经验是对象本身只保留身份标识ID和组件列表所有能力都通过组件提供。这样做的直接好处是当你需要一个既像A又像B的东西时不需要纠结继承关系直接拼组件就行。代价是组件之间的通信需要额外设计比如一个组件怎么知道另一个组件的数据变了这个后面会讲。2.2 对象标识为什么不能用指针当ID很多自研引擎早期会用对象指针作为唯一标识觉得方便。但这里有个大坑对象被销毁后指针变成野指针如果你在别的地方还存着这个指针访问时要么崩溃要么读到脏数据。更麻烦的是对象池——对象被回收后内存还在指针地址没变但里面的数据已经是别人的了你拿着旧指针访问逻辑上完全错乱。正确的做法是给每个对象分配一个单调递增的整数ID所有跨对象的引用都存ID而不是指针。引擎内部维护一张ID到对象地址的映射表。对象销毁时ID标记为失效映射表里对应项清空。这样即使对象池复用了内存旧ID也不会指向新对象。代价是每次访问都要查一次表但这个开销在现代CPU上完全可以接受换来的是内存安全。提示ID的位宽要提前规划。32位ID能表示约42亿个对象听起来够用但如果你每秒创建销毁几千个对象跑上几个月就可能溢出。我见过一个项目因为ID用16位长时间运行后ID回绕导致新对象和旧对象ID冲突出现幽灵敌人。建议至少用64位或者用32位但配合分代机制。2.3 场景图与扁平列表父子关系该不该有游戏对象之间经常有层级关系比如角色身上挂着一把枪枪跟着角色动。最自然的做法是场景图Scene Graph每个对象有父节点和子节点列表变换矩阵从根节点一路乘下来。这个结构直观做编辑器的时候特别好用拖拽就能建立父子关系。但场景图有个性能问题每次查询一个对象的世界坐标都要沿着父链往上乘矩阵。如果层级很深比如一个对象在第五层每次查询要乘五次矩阵。在需要频繁查询世界坐标的场景比如物理碰撞检测这个开销会累积。所以很多引擎采用混合方案编辑器里保留场景图方便操作运行时把层级关系拍平成扁平列表每个对象缓存自己的世界变换矩阵父节点变换改变时才批量更新子节点。Unity的Transform层级就是这么做的它内部有脏标记机制只有变换真的变了才重算。这个设计的核心思想是用空间换时间用缓存换实时计算。3. 资源管理的核心矛盾谁来决定一个资源什么时候该被释放3.1 手动释放、GC、引用计数三条路各有各的坑资源管理和对象管理最大的区别在于对象是逻辑概念资源是实实在在占内存的东西——纹理、模型、音频、着色器。一个2K纹理可能占16MB显存一个角色模型可能几十MB。这些东西不释放显存很快就爆了。手动释放最直接谁加载谁释放。但项目一大代码路径一多你根本记不住哪个资源在哪个模块被引用。A模块释放了B模块还在用直接崩溃。GC垃圾回收省心但GC的停顿对游戏来说是致命的一帧卡200毫秒玩家直接骂娘。引用计数是折中方案每个资源记录有多少地方在引用它引用数归零就释放。听起来完美但循环引用会让计数永远不归零导致内存泄漏。我实际项目里的做法是引用计数为主配合弱引用打破循环。比如A引用BB又引用A那就让其中一方用弱引用不增加计数。引擎提供两种引用句柄强引用句柄增加计数弱引用句柄不增加但能检测资源是否还活着。这样既避免了GC停顿又能处理循环引用。3.2 资源加载的异步化为什么同步加载是原罪早期引擎加载资源是同步的调用LoadTexture(xxx.png)函数返回时纹理已经在内存里了。这在加载场景时没问题但在游戏运行中动态加载就会卡帧。一个100MB的模型同步加载可能要几百毫秒玩家看到的就是画面冻住。异步加载的核心是把请求资源和使用资源分开。你发起一个加载请求拿到一个占位句柄资源真正加载完成后句柄才变成可用状态。这期间游戏继续跑等资源好了再替换。听起来简单但实际做起来要处理很多边界情况资源加载失败怎么办加载到一半场景切换了怎么办同一个资源被多个地方同时请求要不要合并请求我的经验是加载请求要带优先级和取消机制。玩家当前视野内的资源高优先级远处的低优先级。场景切换时旧场景的加载请求全部取消避免浪费带宽和内存。同一个资源的多个请求合并成一个加载完成后通知所有请求方。这套机制做下来动态加载基本不会造成可感知的卡顿。3.3 资源热重载开发期的效率倍增器这个功能在发布版本里没有但在开发期极其重要。美术改了一张纹理你不想重启游戏就能看到效果。资源热重载就是监听资源文件的变化文件一改就重新加载并替换掉所有引用这个资源的地方。实现的关键是资源句柄的间接性。如果代码里直接持有纹理对象指针热重载后指针就失效了。正确做法是持有资源句柄句柄内部指向真正的资源对象。热重载时只替换句柄指向的对象所有持有句柄的代码无感知。这个设计和前面说的对象ID是同一个思路永远不要直接持有会变的东西持有一个稳定的间接层。注意热重载在移动端要谨慎使用。移动设备的文件监听机制和桌面不同频繁的文件IO可能影响性能。而且热重载会打乱资源的内存布局如果项目对内存碎片敏感建议只在编辑器里开真机上关掉。4. 对象池不是万能药用错地方比不用还糟4.1 对象池真正解决的问题是什么对象池经常被当成性能优化银弹但我见过太多项目无脑上对象池结果代码复杂度飙升性能反而下降。对象池真正解决的问题只有一个频繁创建销毁对象带来的内存分配和GC压力。如果你的游戏每秒创建销毁几十个子弹那对象池有意义。如果你的游戏一关只创建几个敌人用对象池纯属自找麻烦。判断标准很简单用性能分析工具看Instantiate和Destroy的调用频率和耗时。如果这两个函数在帧分析里占比超过5%才考虑对象池。否则优先优化其他部分。4.2 池的预热、扩容与收缩策略决定用对象池之后第一个问题是池子初始多大。太小了运行时要动态扩容扩容本身就有分配开销太大了浪费内存。我的做法是根据历史峰值预热。比如子弹池先跑一遍最激烈的战斗场景记录同时存在的子弹最大数量按这个数量的1.2倍预热。这样正常游戏过程中基本不会触发扩容。扩容策略要设置上限。如果池子满了还在请求要么阻塞等待要么临时创建新对象超出池子管理要么直接拒绝。我倾向于临时创建但标记为池外对象回收时直接销毁而不是放回池子。这样既不会因为池子太小导致逻辑卡住又不会让池子无限膨胀。收缩策略是很多人忽略的。游戏从战斗场景回到主菜单子弹池里几百个对象还占着内存。这时候应该根据当前场景需求把池子收缩到合理大小。收缩的时机可以选在场景切换时或者内存压力大的时候。4.3 池化对象的重置陷阱对象从池子里取出来复用时必须重置到初始状态。但初始状态的定义很容易出错。位置、旋转、缩放要重置这个大家都知道。但组件内部的状态呢比如一个敌人对象它的血量、AI状态机、动画播放进度、粒子特效发射器这些都要重置。漏掉任何一个就会出现复活的敌人还带着上次死亡时的动画这种诡异bug。我的做法是给每个可池化对象定义一个ResetForReuse()方法里面按固定顺序重置所有状态。这个方法的维护成本很高每次给对象加新组件都要记得更新它。所以更好的做法是让组件自己负责重置对象池回收时遍历所有组件调用组件的OnRecycle()取出时调用OnReuse()。这样新增组件时只需要实现这两个接口不会漏。5. 序列化与场景管理对象怎么存下来、怎么读回来5.1 序列化的本质把内存里的对象图变成字节流游戏存档、场景文件、预制体本质上都是序列化。序列化要解决的核心问题是内存里的对象是一张复杂的图对象之间有引用关系怎么把这整张图变成一串字节存到硬盘上之后还能原样恢复。最直接的做法是给每个对象分配一个序列化ID序列化时把对象的所有属性写进去遇到引用就写被引用对象的ID。反序列化时先创建所有对象此时属性为空再根据ID建立引用关系最后填充属性。这个两阶段过程很关键因为对象之间可能互相引用不先创建所有对象就没法建立引用。但这里有个坑不是所有属性都需要序列化。比如运行时的缓存数据、临时计算结果、指向系统内部对象的引用这些序列化了反而会出问题。所以需要给属性加标记明确哪些参与序列化。Unity用[SerializeField]Unreal用UPROPERTY自研引擎也要有类似的机制。5.2 场景切换时的资源生命周期场景切换是资源管理最容易出问题的地方。旧场景的资源要释放新场景的资源要加载这中间有个过渡期。如果处理不好要么旧资源释放太早导致新场景还在用要么释放太晚导致内存峰值过高。我的做法是分阶段释放。场景切换开始时先标记旧场景的所有资源为待释放但不立即释放。新场景开始加载加载完成后检查哪些旧资源还被新场景引用比如共享的纹理这些保留其余的释放。这个检查依赖引用计数所以前面说的引用计数机制在这里就派上用场了。还有一种情况是无缝大世界。玩家从区域A走到区域BA的资源要卸载B的资源要加载但玩家感觉不到切换。这需要更精细的流式加载策略根据玩家位置和移动方向预测接下来可能需要的资源提前加载离开一定距离的资源延迟卸载。这个延迟很重要因为玩家可能走回头路立即卸载会导致回头时又要重新加载。5.3 预制体与实例化模板与实例的关系预制体Prefab是游戏开发里非常实用的概念你做一个敌人模板存成文件然后在场景里实例化多个。每个实例共享模板的资源纹理、模型但有自己的属性位置、血量。这本质上是一种写时复制Copy-on-Write策略。实现的关键是区分共享数据和实例数据。共享数据放在模板里所有实例指向同一份实例数据每个实例独立。当实例修改了某个属性如果这个属性原本是共享的就要把它复制一份变成实例独有。这个机制在Unity里叫预制体覆盖在自研引擎里需要自己实现。提示预制体嵌套是复杂度飙升的源头。A预制体里包含B预制体B预制体里又包含C预制体修改C会影响所有包含C的B进而影响所有包含B的A。这个影响链在项目后期会变得难以追踪。我的建议是预制体嵌套不要超过两层超过两层就考虑用代码动态组装而不是静态嵌套。6. 实战排查清单对象与资源问题的定位思路6.1 内存泄漏的排查链路内存泄漏是对象资源管理最典型的问题。排查思路是先定位泄漏类型再定位泄漏对象最后定位泄漏原因。第一步用内存分析工具看内存增长曲线。如果内存持续增长不回落基本可以确定泄漏。第二步抓两次内存快照对比哪些对象数量在增长。第三步看这些对象的引用链找到是谁在持有它们。常见的泄漏原因有这么几类事件监听没取消对象销毁了但还被事件系统引用、协程没停止协程持有对象引用、静态容器没清理全局列表里还存着已销毁对象、循环引用导致引用计数不归零。我遇到最多的是事件监听没取消因为写代码时很容易忘记在OnDestroy里反注册。6.2 资源重复加载的识别与合并同一个资源被加载了多次是另一个常见问题。比如两个模块各自加载了同一张纹理内存里就有两份。这个问题在项目初期不明显资源少的时候浪费不大但资源多了之后可能浪费几百MB。识别方法是给每个资源算一个唯一键通常是文件路径的哈希加载时先查缓存缓存里有就直接返回没有才真正加载。这个缓存就是资源管理器。关键是所有资源加载都必须走资源管理器不能有绕过它直接读文件的代码。我见过项目里有人为了图方便直接File.ReadAllBytes加载配置结果配置更新后缓存里的旧版本还在用出现数据不一致。6.3 帧率波动的对象池视角帧率周期性波动很多时候和对象池有关。池子扩容的那一帧因为要分配大量内存帧时间会突然升高。如果扩容频繁发生就会看到帧率规律性地掉。解决办法是把扩容分散到多帧。不要一次创建100个对象而是每帧创建10个分10帧完成。这样单帧开销小玩家感知不到。同时调整预热数量让扩容尽量少发生。如果实在无法避免扩容可以在加载界面提前扩容而不是在游戏过程中。另一个帧率波动源是批量销毁。比如一波敌人同时死亡同时触发销毁和回收那一帧的开销会很大。可以把销毁操作排队每帧处理固定数量平滑开销。7. 我踩过的几个坑和对应的解法第一个坑是对象池里的对象被外部引用。子弹从池子里取出来发射逻辑里存了子弹的引用子弹回收后引用还在下次访问就是脏数据。解法是回收时把所有外部引用置空或者用句柄代替直接引用句柄能检测对象是否有效。第二个坑是资源引用计数在异步加载时算错。发起异步加载时增加计数加载完成前如果引用方销毁了计数没减资源永远不释放。解法是异步加载的句柄也要遵循引用计数规则取消加载时减计数。第三个坑是场景切换时旧场景的协程还在跑。协程里访问已销毁的对象直接报错。解法是场景切换时停止所有属于该场景的协程或者协程里访问对象前先检查有效性。第四个坑是预制体实例化时的资源竞争。多个地方同时实例化同一个预制体如果预制体内部的资源是懒加载的可能触发多次加载。解法是预制体实例化时预加载所有依赖资源或者资源加载本身做请求合并。这些坑的共同点是它们都不会在项目初期暴露而是在对象数量、资源数量、并发操作达到一定规模后才出现。所以对象与资源管理的设计不能只看当前需求要预留扩展空间。我个人的原则是ID用64位、引用计数默认开启、对象池按需使用、所有资源加载走统一入口。这四条看起来简单但能避开后面80%的坑。
![[从入门到入土!!!] Ubuntu20.04 系统开发环境配置（系统配置，显卡驱动，CUDA，ROS，VSCode，Anaconda等）](http://pic.xiahunao.cn/yaotu/[从入门到入土!!!] Ubuntu20.04 系统开发环境配置（系统配置，显卡驱动，CUDA，ROS，VSCode，Anaconda等）)
