在项目里泡过几年的人大概率都见过这个画面场景切换完成帧率恢复正常打开内存分析器一看上一关的村庄模型还躺在内存里没走。这几乎是每个游戏项目都会遇到的“成长礼”根本原因就出在游戏引擎的两个底层模块上——场景管理和资源管理。这篇是“游戏科学”系列第一篇聊的就是引擎里的场景与资源管理它们各自管什么、怎么协作、常见的坑又长什么样。适合正在写自研引擎的小团队、天天跟内存抖动搏斗的客户端同学以及那些想弄清楚引擎背后逻辑的独立开发者。1. 场景与资源管理的定位引擎里的“基础设施层”1.1 为什么场景和资源总被放在一起说场景管理管的是“一个关卡如何被加载、组织、运行、卸载”资源管理管的是“一个网格、贴图、音频从磁盘进入内存、再进入显存的完整生命周期”。平时确实可以当成两件事讨论但在引擎内部它们其实是同一个流程的上下半场。一个完整的关卡等于场景结构加上被场景引用的资源。场景结构保存的是实体清单、坐标、父子关系、触发器、灯光配置、导航网格这些“规则与空间”数据资源则是网格、贴图、材质、动画剪辑、音频这些“内容与数据”。场景本身不直接包含贴图像素它只保存一个资源引用等到运行时再通过资源管理器去取。把资源直接复制进场景文件的引擎不是没有但那样做会导致同一份贴图在多个关卡里重复存好几遍后续想做热更新和增量补丁也异常痛苦。从这个角度理解场景和资源是天生的一对场景负责“怎么摆、摆什么、什么时候出现”资源负责“摆出来的东西长什么样、数据从哪里来”。任何一个关卡策划操作本质上都是在对这二者做编排。1.2 场景、实体、组件、资源四者怎么分用一个具体例子说明这四层关系场景一个关卡的顶层容器相当于一本剧本规定了有哪些角色、在什么位置、在什么灯光环境下上演。实体剧本里的一个单位比如一棵树、一盏路灯、一个敌人。组件挂在实体上的能力模块比如“我可以被渲染”“我有碰撞盒”“我能播放动画”。资源组件使用的数据素材比如树的 3D 模型、贴图、音频。运行时加载链路是这样的场景文件先被反序列化得到一串刚创建的实体对象然后给每个实体挂上组件组件构造时通过资源 ID 向资源系统请求资产数据资源加载完成后上传到 GPU或者解码成音频采样。这四层哪一层出了问题最终表现都可能落在大家熟悉的加载慢、内存高、渲染异常这些现象上。所以我一直觉得理解“场景文件里不是资源本体而是资源的引用”是吃透引擎资产管理的第一道门槛。后面讲依赖图、共享资源、流式加载全都建立在这个认知上。1.3 为什么这类问题以前期平静、后期暴雷为主场景与资源管理是典型的横切基础设施渲染、物理、音频、动画、UI几乎每个子系统都在消费它。正因为关联面太广一点点泄漏不会立即被发现功能都正常、帧率也正常只有内存曲线在悄悄抬升。等第十个关卡切换完突然崩了再回去定位就得从好几个模块的配合关系上找原因成本直接翻倍。做引擎的同学常说场景与资源管得好不好基本决定项目的天花板。这句话并不夸张加载速度、内存水位、快速切换场景时的卡顿频率全被这层基础设施卡着。商业引擎把这部分封装得很深很多人用了好几年也没意识到它的存在但一旦开始做自研、大世界或高性能优化迟早要回到这里补课。2. 场景管理的实现骨架空间树、场景流与状态机2.1 场景内的空间组织为什么是树而不是列表运行时的关卡对象不会是一个扁平的数组而是一棵带空间变换关系的场景图。每个节点带本地变换子树节点在父节点基础上做叠加。比如角色节点下面挂左手、武器、盾牌武器要想跟随角色移动只需要挂在角色子级不需要每帧手动同步坐标。一开始这么做很自然但随着关卡变大有几个原则需要心里有数层级不要过深每一层矩阵变换都要逐级计算几十层深度的嵌套树在大量动态物上是纯浪费也不要完全扁平物体之间完全没有空间分组空间剔除、流式加载、物理查询都无从下手常见折中是世界按区域分组区域下再挂动态实体空间剔除和流式加载都基于区域做粗粒度筛选。在我见过的项目里场景树的设计经常在“可用”和“高效”之间走弯路。早期只求功能正确忽略了空间索引后期想优化又发现树的组织方式已经写死在各业务系统里改动牵一发动全身。所以做场景图时一开始就要想清楚这棵树除了承载变换还要为哪些系统服务。2.2 场景必须有状态机从 Unloaded 到 Active 的约束为什么不能只用一个“是否加载完”的布尔值因为实际加载是异步的要经过 IO、反序列化、实例化、GPU 上传等多个阶段阶段之间有大量时间窗口还可能失败或取消。没有状态机加载中途去给场景物体发指令、同一帧请求两次切换、卸载过程中再次加载全都会变成不可复现的玄学问题。场景至少要维护这样几种状态状态含义允许触发的操作Unloaded场景未加载无实体发起加载请求Loading资源解析和实例化中等待回调、显示加载进度Loaded数据就绪、实体创建完成尚未激活执行初始化、激活逻辑Active场景每帧更新中正常游戏逻辑、允许请求卸载Unloading正在卸载、释放资源中等待卸载完成禁止对实体操作状态机真正要防的是非法跳转Loading 状态不允许对场景实体发指令Unloading 状态不允许再次发起加载Active 状态下收到资源变更请求应该排队而不是立即处理。自研引擎刚起步时可以没有这套状态但对项目长期演进来说这几乎是必经的返工项。2.3 多场景叠加与卸载顺序的现实问题现在的引擎基本都支持 Additive 多场景。这种能力的直接好处很多大地图可以拆成多个区块慢慢加载UI 层可以做成独立场景不干扰战斗场景的实体列表室内副本和室外大世界可以共存按玩家位置动态切换逻辑。但这些便利都建立在卸载顺序有保障的前提下。最常见的坑是一个场景里的物体还在渲染另一个场景已经把那块共享材质销毁了渲染器提交的命令队列里出现悬垂引用画面上就出现闪烁或者直接崩溃。要避免这种情况不只是场景系统单方面能保证的还得靠资源系统做全局登记场景卸载时先解除场景与资源的引用关系让资源的引用计数往下走至于资源什么时候真正从 GPU 删除由资源系统根据全局引用情况决定。所以说到底多场景支持做得越顺越说明背后的资源管理足够成熟。3. 资源管理的微观机制引用计数、缓存与异步管线3.1 一份资源的三级旅程一份资源数据在运行期要依次穿过三个物理层磁盘层资源源文件或者打包后的 Bundle/PAK 文件躺在磁盘上这里重点管读取性能和数据更新方式内存层反序列化后的 CPU 侧数据比如顶点数组、贴图像素数据、动画采样曲线占的是 RAM显存层上传给 GPU 的缓冲和纹理占的是 VRAM销毁时要和渲染管线节奏对齐。资源管理器在三个层面各管一摊底层是文件系统和流式 IO中层是资源注册表和缓存上层是渲染器资源接口。很多人以为资源管理就是“加载一个对象进内存”其实每个层面都有独立的问题。比如磁盘层要考虑顺序读和随机读的差异内存层要考虑 CPU 侧数据要不要常驻显存层要考虑上传时机和回收时机。任何一层出问题最终都会表现为加载时间变长或者内存上涨。3.2 引用计数谁加谁减要有明确的约定资源对象内部维护一个引用计数减到零就销毁。这听起来很简单真正难的是“谁应该加、谁应该减”的语义设计。项目里常见的计数场景大概是这样场景操作说明场景实体构造组件引用某个资源对应资源计数 1新增使用方材质资源引用贴图和 Shader贴图、Shader 计数 1资源级依赖组件销毁、场景卸载对应资源计数 -1使用方释放异步加载请求被取消已增加的计数额外 -1错误路径回滚多线程同时请求同一资源计数原子增减防止计数错乱最容易出错的是异步加载被取消。比如玩家快速连点进入战斗加载请求发了十个又取消十个如果每个请求在发起时就增加计数、取消时没回滚这十份资源就永远退不回零。所以加载器一般把“计数递增”放在请求提交之后、数据派发之前并区分“请求计数”和“持有计数”避免请求层污染资源层的引用统计。另一个容易踩的是循环引用。材质引用贴图贴图理论上不该反向引用材质但实际项目中为了解决“贴图改动要通知哪些依赖方”的问题有人会把材质指针塞进贴图对象。一旦出现反向持有引用计数就形成闭环永远不为零只能靠 GC 兜底或者人工断链。我比较倾向在资源系统里直接禁止资源间反向持有需要通知逻辑就单独做事件分发而不是靠指针倒挂。注意资源系统里尽量避免资源间反向引用尤其是“贴图持有材质指针”这类做法它会让引用计数形成闭环最终表现为资源永不释放。3.3 同步加载为什么不可持续同步加载就是把磁盘读取、解析、实例化全部丢到主线程。项目早期场景小、资源少无所谓一旦画面复杂度上来主线程就会出现几十毫秒的卡死玩家体验直接崩。异步管线的常规分法是五段请求提交资源 ID 和回调立即返回IO从磁盘或 Bundle 读字节流解析在子线程做解压、反序列化上传把解析结果提交给 GPU 管线回调通知请求方资源已就绪。这五段里最容易漏的是“请求取消”的处理。一个资源第一次请求后又被取消随后很快又发起第二次请求就需要一个请求 ID 来区分新旧请求否则第二次回调触发时第一次请求的持有者可能已经销毁回调里一碰数据就出错。很多项目在接入异步加载初期的崩溃有一半是没处理这种竞态。3.4 内存预算资源缓存不能无限膨胀资源缓存通常会做 LRU也就是最近最少使用淘汰。但缓存本身也要带内存预算否则会变成一个无底洞。加载一张 2048x2048 的 BC7 纹理显存占用大约 8MB 量级一个中大型关卡动辄几十上百张贴图几个 GB 显存也能轻松吃掉。预算机制的工作方式大致如下资源加载时登记内存占用总量超过阈值时按“最后使用时间”排序把没人引用的资源先淘汰有人引用的资源不允许淘汰只能尝试压缩格式或降低 mipmap 层数。移动端尤其要吃这套机制因为系统对内存上限毫不留情超了可能直接杀进程。我见过最典型的反面案例是“缓存只加不减”。理由是怕玩家再回来时卡一下所以所有场景资源都常驻结果内存一路涨最后被迫做全量重启。正确做法是给热资源和冷资源分层当前场景用的热资源常驻上一关的冷资源尽快释放中段资源交给 LRU 调度。4. 与资源的协同工作依赖图与流式加载4.1 场景对资源的依赖关系怎么建模场景文件里保存的不是资源实体而是引用也就是 GUID、路径、版本号。加载场景时资源系统要顺着引用把依赖图展开。场景对象引用了敌方网格网格又引用贴图和材质材质再引用 Shader这些都属于间接依赖。展开依赖图要防两种问题循环引用A 依赖 BB 依赖 A加载器必须记录“已请求集合”避免无限递归重复展开同一个资源出现在多个依赖分支里只能加载一份、回调一次否则内存和 IO 都会翻倍。依赖图还有一个重要用途就是卸载。场景卸载时顺着依赖图反向遍历可以判断哪些资源是因为这个场景才常驻的哪些是被别的场景共享的。共享资源不能光看数量还要看引用来源否则很容易误删。这里再强调一次前面说过的原则场景卸载不等于资源卸载资源是否释放要看全局引用状态。4.2 流式加载超大世界的资源调度逻辑流式加载的战略目标不是“瞬间把新区域加载完”而是“每个帧周期内资源进出内存的净流量可控”。这跟很多人理解的“预加载越多越好”并不一样。通常的做法是给地图划分区块每个区块绑定包围盒、场景段、资源清单和内存预算。引擎每帧评估玩家位置进入包围盒对区块发起加载请求距离超过卸载阈值对区块发起卸载请求处于中间地带按优先级进入预加载队列。优先级打分一般会考虑距离、玩家朝向、可见性、当前内存压力。移动端大世界项目里我常用的默认值是“每帧最多发起两到三个加载请求单个请求资源总量控制在 20MB 以内”。这个数字看起来保守但实际跑起来内存曲线远比一次性把所有相邻区域全加载要平稳。我曾遇到一个经典反例流式加载为了追求无缝体验贪心地一次性请求八个区块结果内存瞬间被贴图顶爆。后来改成区域预算和分批推送每帧只做少量高优先级加载体感反而更好。这里的核心教训是加载不是越快越好而是越可控越好。4.3 卸载顺序与延迟销毁的具体做法卸载比加载更容易出错。加载时资源没到位最多表现为模型缺失或半透明卸载顺序错了轻则贴图闪烁重则直接崩溃。推荐卸载顺序是先从场景树移除实体停止逻辑更新组件解绑资源引用让引用计数逐级递减GPU 资源回收放到渲染帧结束之后把计数归零的资源转进“待销毁池”延迟几帧再统一清理。这样做的核心原因只有一个避免渲染器提交的绘制命令用到已经销毁的缓冲和贴图。例如一帧里物体已被移除但 GPU 命令队列里还排着该物体的绘制指令如果资源立刻销毁就会产生悬垂引用。待销毁池还能带来一个意外好处玩家快速返回上一关时待销毁池里的资源可以瞬间重新激活省去一次磁盘 IO。延迟销毁和内存预算搭配起来本身就是很多商业引擎“场景切换不卡”的秘密之一。5. 实测中的高频坑与排查思路5.1 重复加载内存翻倍出现的第一嫌疑资源管理里最典型的暗坑就是同一份资源被反复加载成多个实例。举个例子敌人死亡后生成掉落物掉落物加载一份金币模型如果每次加载都直接 new 对象而没走全局缓存那么同一份模型在内存里就会出现几十份占用也会成倍上涨。排查手段并不复杂。在资源管理器里记录每个资源 ID 的加载次数然后打开 Profiler 按资源统计内存。如果发现一份网格在 RAM 里有几十个实例对象而数据完全一样那基本就是重复加载没有走缓存。解决方式也清晰先在资源注册表按 ID 查一次命中就直接返回已有对象。进一步可以在并发请求场景加“去重队列”同一个 ID 在并发请求期间只发起一次磁盘读取后续请求全部挂接到同一份回调上。随着团队变大、加载代码分散到各个业务系统绕过缓存私自加载的情况容易出现所以统一的资源请求入口很重要。5.2 场景切换的内存尖峰怎么削“新场景先加载完再卸载旧场景”会造成一个叠加期两个场景的资产同时驻留内存尖峰特别难控制。“先卸载旧场景再加载新场景”又会拉长加载时间出现玩家反感的长黑屏。在实践里我比较倾向折中方案预加载阶段提前把新场景的关键资源加载到缓存但不实例化切换帧移除旧场景实体同时实例化新场景资源落地区段旧资源按引用关系递减转入待销毁池空闲帧再统一回收待销毁池里的旧资源。这样做的效果是加载和卸载在时间轴上部分重叠但内存尖峰不是两者峰值相加而是一方高时另一方明显更低。要做到这一点资源系统必须清楚“哪些资源是场景独占哪些被多个场景共享”。共享资源在切换期间引用计数不会立刻降到零因此不会被贸然销毁这也是全局依赖图的另一个价值所在。5.3 泄漏定位三件套资源泄漏很难直接肉眼可见常见表现是反复切关卡几十次后内存稳步上升。我在定位泄漏时最常用的三件套第一内存快照对比。在特定关卡加载前后各抓一次内存快照按资源类型对比实例数量变化。如果一个类型只增不减大概率就是泄漏点。第二资源实例统计面板。按资源类型列出当前活跃实例数、总内存、引用持有链。一页纸就能看出是不是所有贴图都被额外持有了一份。第三API 日志审计。打开资源加载与卸载日志按时间线回放。大多数泄漏不会出现在加载日志里而是出现在“卸载了却依旧驻留”的日志里——找到那个该减引用计数而未减的位置问题基本就定位了。三件套配合使用一次资源泄漏通常可以在半天内锁定。如果只凭经验猜往往会在无关系统上浪费不少时间。5.4 新人落地检查清单不管是用商业引擎还是自研引擎以下检查清单可以帮你快速判断项目的资源管理系统健不健康所有资源加载请求是否走统一接口而不是散落在各业务系统里直接 new 对象异步加载回调是否处理了请求取消和场景销毁的情况每次场景卸载时是否对实体组件与资源的引用做了解绑引用计数增加和减少是否成对出现所有权转移有没有被复制语义破坏资源缓存是否带内存预算上限共享资源是否能在多个场景之间安全共享而不是被第一个卸载的场景带走GPU 资源回收是否延迟到渲染帧结束之后。这条清单看着基础但大多数内存爆炸项目的问题都出在其中一两项。就我自己的实操体会自研引擎最容易省掉的恰恰是这一层可省掉的部分后续都会加倍补回来。早期花两周把引用计数、资源缓存和场景状态机画清楚后面省下的填坑时间至少是两个月量级。如果让我给一个优先级排序永远是“引用成对”第一、“缓存查重”第二、“显存回收”第三顺序别搞反。下一篇我会拿一个实际的自研引擎加载流程把引用计数和依赖图逐行对照着拆开讲到时候你会发现在今天这篇里提到的所有概念在代码里都有了具体的形状。