FPS进对局前为何不立刻清缓存？延迟清理才是更稳的内存优化方案

你有没有想过一个问题：为什么很多大厂FPS在进对局的时候不把大厅那些花里胡哨的缓存全清掉，非要等到一局打完、人已经在结算页面或者回到大厅了，才开始慢慢腾腾地做延迟清理？

玩家视角里这就是个很简单的需求——“我要打枪了，那些商城里的时装、大厅里的3D模型、好友列表头像，留在内存里有什么用？赶紧帮我清掉，给对局腾地方不行吗？”还真不行。真要在进对局的瞬间做全量清缓存，大概率不是你期待中的“内存一下舒坦了”，而是加载变慢、回大厅卡顿、甚至闪退翻车。这篇文章我就用大白话把背后的逻辑整个拆开，说说为什么“打完再清”才是工程上更稳的做法，顺便把缓存清理时最容易踩的坑也一起列出来。

1. 先分清“局外缓存”到底是什么

1.1 进对局前，客户端手里到底握着什么

我把“局外缓存”先框个范围：玩家在大厅、商城、仓库、活动页、结算界面等非战斗界面时，客户端加载并留在内存里的一堆资源，都算局外资源。它们并不是一团只有删除价值的文件垃圾，而是被不同界面引用着的数据副本。

举个比较直观的例子。你在大厅里看到自己的角色穿着皮肤站在那里，这个角色模型、贴图、骨骼动画需要常驻内存；你去商城划了一圈，每张武器图、每个角色立绘甚至视频预览都是缓存在本地；邮箱列表、好友头像、排行榜数据，也是一样。再往下还有一套容易被忽略的东西：引擎级缓存，比如Shader编译缓存、图集、字体、UI图集，这些既服务大厅也服务对局，清掉它们不叫优化，叫自找麻烦。

把这些东西按生命周期简单分下类：

看这个表你就能发现，玩家常说的“局外缓存”其实是大厅/界面资源这部分。它确实不是本局战斗必需品，但也绝不是废品。因为只要你打完一局回到大厅，它们马上又要用。关键在于：到底在什么时候让它们离开内存最划算。

1.2 它不是垃圾，只是“另一个场景要用的东西”

缓存最朴素的定义是“为后续请求准备的数据副本”。大厅缓存是为了让你逛商城、看好友、进仓库时不卡；战斗缓存是为了让你开枪、丢雷、开车时不卡。它们是不同场景的数据，不是“有用的”和“没用的”的关系。

拿生活里搬家来类比：客厅里的沙发、电视柜、餐桌，在你搬进新房子之前确实挡路，但它们不是垃圾。你不可能为了给行李车腾出一条路，就把客厅家具全扔了。更稳妥的做法是，先把行李搬进卧室，等客厅真正要布置时再把家具安排回客厅。游戏里的缓存也一样，大厅资源在大厅场景有用，战斗资源在战斗场景有用，要管理的是“什么时候该卸载”，而不是“哪些缓存直接杀掉”。

理解了这一点，后面再聊“为什么进对局前清缓存反而离谱”就顺了。

2. 为什么进对局时立刻清缓存反而会变卡

2.1 清理本身是有成本的，不止是“删一下”

我在项目里见过不少非技术同学的直觉：清缓存就是把内存里的数据删掉，顺手的事，能有多慢？实际上，清理一次全量缓存，至少涉及遍历对象、解引用、卸载资源、释放GPU显存、回收托管堆内存这几个阶段。如果走的是引擎的卸载接口，还得等引擎去处理依赖关系、触发回调、重算引用计数，一套组合拳下来，主线程被占用的时间非常可观。

更要命的是，进对局本身在等什么？等地图加载、等资源Loading、等网络同步。也就是说，进对局时主线程和IO线程本来就处于高负载状态。这时候再插进来一轮“全量清大厅缓存”，相当于你赶着上地铁，人已经在安检口排队了，还要停下来把行李箱里的东西一样一样扔掉。表面看是给背包腾了地方，实际是把自己堵死在队伍里。

所以大厂客户端在进对局阶段宁可在内存吃紧时先走“LRU淘汰最不常用的资源”，也不会去把所有大厅资源列一个清空循环。后者做的无用功太多：不少大厅资源在当前帧仍被引用，强行卸载会触发重新加载，一来一回反而双重开销。

2.2 清早了，二次加载比不清理更难受

再算一笔账：玩家从进对局到真正开打，中间要经历匹配成功、加载地图、读条、飞机跳伞这些流程。假设在“匹配成功”的那个瞬间，客户端就把大厅相关缓存全清了，那么请考虑一种很常见的场景——玩家因网络波动、被踢出房间、或者对局还没开始就崩溃退出，直接回到大厅。此时大厅里原本几秒就能展示完的角色、UI背景、商城贴图全都没了，客户端只能重新读磁盘、重新解压、重新解码贴图。表现就是转圈转半天，甚至卡到编辑器里常说的“白屏期”。

这还没说完。很多FPS是支持“再来一局”的，玩家打完一局快速返回大厅再立刻匹配下一局，中间间隔可能只有几秒。如果上一局打完时已经把大厅UI的资源清干净了，下一次回大厅又得全部重新加载，内存占用会在短时间内冲高再回落的波动。对于中低端机，这种波动很容易变成肉眼可见的掉帧。

我后来做性能优化时给自己定了一条原则：清理缓存不能制造“未来的加载峰值”。如果一个资源在5分钟内很可能被再次使用，那它就属于“不应该主动清”的范畴。进对局前把目标场景要用的大厅资源清掉，恰好违反了这条原则。

2.3 低端机和内存告警下的另一种选择

有人会问：那手机内存不够、提示内存紧张，也不清吗？这里要说清楚，Android和iOS系统在内存吃紧时会主动发低内存告警，游戏项目往往也会接到系统的“请你释放点内存”的请求。这个时机下确实要做清理，但清理的重点是“当前最不常用的、占用最大、重建成本最低”的资源，而不是“所有局外缓存”。

比如你在大厅里，最近看过的商城3D模型已经滑出屏幕好一阵了，那它的资源引用可能早就该释放；又比如在加载战斗场景时，上一场高画质回放数据、临时录制的视频缓冲等已经没用的会话数据，适合在这个低内存循环里清掉。这种策略本质上是“逐级瘦身”：先清最便宜的，再清比较贵的，尽量不碰那些还在生命周期中、随时会被再次拉起的界面资源。

那为什么大厂不选择在进对局时主动把大厅资源判断为“低优先级”然后清一波，给战斗资源让路？因为“让路”不是必须的。战斗资源和大厅资源有重叠期，很多引擎在切换场景时会用场景预加载方案：先异步加载战斗资源，等战斗场景完全接管后再卸载大厅场景。这个交接过程中，确实会有一段时间新旧资源同时存在，内存会出现双峰，但换来的是一旦战斗加载失败或玩家取消匹配，大厅还能无缝切回来。为了省那几百MB内存去牺牲响应速度，在高 DAU 的竞技游戏里是得不偿失的，因为对局失败回大厅的频率远比想象中高。

3. 打完再清，赢在哪个时间窗口

3.1 结算转场是最佳清理窗口

那打完之后再清，又有什么好处？最直接的一点：时间窗口选得很聪明。

一局FPS打完，玩家会经历“战斗结束动画/战绩统计/返回大厅”的转场。这个阶段玩家能操作的内容很有限，注意力基本在结算数据上，不会频繁点进商城、仓库里查看资源。也就是说，这十几秒是天然的“低交互等待期”，用来做高开销的缓存清理，用户感知最弱。

另外，这个时刻恰好是“战斗资源生命周期结束”的节点。本局的地图、场景、武器、特效资源已经完成了使命，之后大概率不会再被使用（除非玩家立刻开启下一局同一张地图，但那是另一套可复用逻辑）。把战斗会话资源在这个节点释放，既不会影响对局流畅度，也不会占用下一局加载的内存空间，属于“刚好该扔就扔”。

站在玩家视角的体感也完全不一样。进对局时你看读条读到 90% 突然卡一下，会焦虑、会骂；但你在结算页看数据时，哪怕后台正在做资源回收导致界面轻微掉帧，你的感知也弱得多。这就是延迟清理的价值——不是省资源管理的工作量，而是把“用户不可感知”的窗口利用了起来。

3.2 延迟清理的工程实现思路

说点落地的东西，“打完再清”在实际工程里通常不是一条命令清到底，而是拆成好几个小步骤，每帧只做一点点，避免把单帧卡爆。这里我写个简化版的伪代码示意一下思路：

csharp复制void OnMatchEnd()
{
    // 进入结算状态，暂停大厅UI的活跃引用计数更新
    CacheManager.SetAllowRelease(true);

    // 设置每帧最大清理预算，比如8MB
    CacheManager.SetPerFrameBudget(8 * 1024 * 1024);

    // 把上一局战斗用的场景资源标记为“可卸载”
    BattleSceneUnloader.MarkUnload(_currentBattleContext);
}

void Update()
{
    if (CacheManager.HasPendingCleanTasks())
    {
        var stopwatch = StartNewStopwatch();
        while (stopwatch.ElapsedMs < 2f)  // 限制单帧清理不超过2毫秒
        {
            bool done = CacheManager.ReleaseNextBatch();
            if (done) break;
        }
    }
}

限制单帧清理时间是关键。很多项目做“打完再清”的时候，清理本身没问题，问题出在让清理工作一口气跑完，导致那一帧直接掉到 20 帧以下。用分帧批量处理以后，每帧只释放固定大小的资源，主线程开销就被摊平了。另一个重要的点是清理过程要“可打断”：如果玩家在结算页点了“返回大厅”甚至直接点了“再来一局”，高优先级的场景加载任务应该立刻把清理任务挤到后面去。否则就会出现：玩家想快速继续下一局，结果客户端还在磨磨唧唧地清理上一局资源，白白增加等待。

3.3 “打完再清”不等于把缓存全丢掉

延迟清理虽然定在“打完再清”，但清的对象要严格圈定。战斗场景里生成的Mesh、贴图、音频，以及本局专用的临时数据，确实是清理目标。但已经下载到磁盘的通用资源包、引擎编译好的Shader缓存、账号信息等，就不该在这个阶段动。

如果真把“所有缓存”都理解为可以清的东西，那打完一局之后，下次进入大厅时加载速度会下降，因为本地磁盘缓存丢了，又要重新走网络下载/解压资源；如果连 Shader 缓存都被清了，下次进入新的场景时，画面可能出现明显的顿挫，因为引擎要重新编译着色器。

所以准确地说，打完再清的是“场景会话级别的资源”，不是所有缓存。清完之后，项目通常还会保留那部分重建成本高昂、命中率又高的长驻缓存，让下一局进入得更快。你把缓存当成越用越顺手的“暖数据”，就容易理解为什么不能一锅端了。

4. 从缓存治理的角度看：清哪些、留哪些、什么时候失效

4.1 本地缓存、服务端缓存和缓存一致性

聊到这里，我发现这套逻辑其实和后端经典缓存治理是共通的。很多做服务端的人把 Redis 缓存当“数据库前面的加速层”，进对局清缓存相当于“在请求刚进来时把缓存全删了”，那一定会引发缓存雪崩：所有请求在同一时刻打到底层存储，谁顶得住？

游戏客户端也一样。客户端本地缓存本质上就是把服务端下发的配置、UI资源、材质烘焙数据等“提前存下来”，避免每次打开商城都去服务端重新拉一遍。它对应着后端里的 CPU缓存、Redis 缓存、CDN 缓存这些层级。在不同层级之间，最麻烦的就是缓存一致性：什么时候数据失效？什么时候需要清理旧缓存？清理后如何重新拉新？

游戏客户端在选择“打完再清”，还有点像缓存里常见的“延迟双删/最终一致”思路：不追求全量同步立即干净，而是选一个相对安全的时间点，把已经不太可能再被使用的旧数据淘汰掉。这个安全时间点，往往就是产品流程里天然的“会话结束点”——一局游戏结束，一个会话就结束了，此时旧数据淘汰是最自然的。

4.2 从“进对局清”到“版本切换清”的启发

后来我在做更新模块时想到一个更极端的对比：真正需要“立刻清缓存”的场景是版本升级。比如下载了新的资源版本，旧版本的图集、模型、配置和现在的服务器数据对不上了，这时候如果不清理旧资源，游戏会加载出错、贴图错乱、甚至客户端逻辑异常。但即使是这样，在刚进入对局的瞬间也不是最佳清理时机。客户端通常会在开屏/登录时做版本检测，标记出需要失效的旧缓存，然后利用加载流程里的空闲批次去删除旧资源，而不是抢在用户马上要对枪的时候删除几十个文件。

用 FPS 的场景理解就是：如果你已经下载了新的“地图A优化包”，那么下一次进入地图A之前，旧版地图A的缓存当然要清。但这个清理由“版本号不一致”触发，与“用户刚要进对局”不一定重合。也就是说，清理的决定因素应该是“数据是否还有效、是否会被再使用”，而不是“用户处于什么场景”。

回到开头的问题：大厂 FPS 为什么不进对局立刻清局外缓存？因为大厅缓存并没有“失效”，它还等着你打完回来继续用。进了对局，只有战斗资源需要加载，唯一需要为它腾空间的，是找那些真正不会再用的旧资源来清；而“局外缓存”大概率还会再次出现，属于“还不能丢的缓存”。

4.3 一个反直觉但很关键的现象：越清越卡

由于不少玩家对缓存清理有执念，很多游戏也做了“手动清理缓存”功能。但你有没有发现，点了“清理缓存”以后，再进游戏反而卡顿更明显了？真不是你的错觉。

手动清理缓存通常是全量删除磁盘上的临时资源，包括那些被重复利用的高频资源。下一次进大厅、进商城时，一切都要重新下载或重新解压。相当于你把“预加载/缓存加速”这个机制整个关了。而在对局中，如果本来就依赖本地的资源包减少网络加载，手动清理后再进对局会花更长时间等待资源拉取，体感必然是更卡。

我不是说“不要清理”，而是想说“清理缓存的粒度要细”：最好只清理“重建成本低、命中率低”的缓存，而不是一上来就把所有缓存的命根子割了。很多大厂不在进对局时清缓存，恰恰是因为他们太清楚“无差别清理”会造成多大的体验损伤。

5. 实战中遇到的坑：清理时机没选好导致的翻车现场

5.1 现象一：进对局时掉帧，不是清得不够，而是清得太猛

我之前参与过一个性能优化专项，当时低端机反馈“进对局后前两秒特别卡”，我们把矛头对准了内存，觉得是缓存没清干净，于是加大了对局开始前的资源清理力度。结果一测，反而更卡。后来用 profiler 一看，掉帧的根源是一大堆 Texture 和 Mesh 同时被解引用，析构逻辑集中爆发，把主线程彻底压垮。

这其实是个常见的工程误区：看到内存高就以为要清缓存，但卡顿往往不是内存不够导致的，而是清理动作本身引起的 CPU 峰值。后面我们把清理时机从“加载对局前”移到了“上一局结束后的结算页”，并做了分帧限制，掉帧就消失了。这也是我第一次深刻体会到：延迟清理不是“拖延症”，是在给主线程松绑。

5.2 现象二：打完回大厅反而变慢，罪魁祸首是同步清理

还有一种翻车现场是反向的：项目确实选择了“打完再清”，但用的是同步清理，而且是回到大厅那一瞬间才触发。玩家点“返回大厅”后，客户端一进大厅主界面就开始同步释放战斗资源，大厅UI的加载和旧资源释放挤在同一帧。表现就是，大厅背景黑屏几秒，按钮点了没反应，或者快速切 Tab 时卡顿。

正确做法是：清理动作要从“进入结算页”就开始做，而不是等玩家回到大厅再开始。因为结算页本身是大厅场景的轻量子集，玩家在这个页面停留的时间足够后台进行大批量资源回收。等真正回到大厅，主要加载工作已经做完了，大厅资源只需要按需拉取即可。把这个时序倒过来之后，回大厅的流畅度立刻提升了一截。

5.3 怎么判断清理到底有没有出问题

如果你也想检查自己的客户端缓存清理逻辑是否合理，可以用几个简单指标做判断：

• 看单帧耗时：在你设定的清理时间段内，主线程耗时有没有出现超过 50ms 的尖刺。
• 看资源重载率：清完某个资源以后，统计它在短时间内是否又被重新加载了。如果重载率很高，说明你清掉了“很快又要用”的数据，清理策略有误。
• 看内存曲线：理想情况下，打完一局回大厅后内存应该缓慢下降，而不是瞬间大起大落。
• 看触发场景：清理任务标志位是否会被高优加载任务中断，如果不会中断，那玩家点“再来一局”时必然会被清理拖慢。

这些指标只要你接入了打点系统，都是可以量化的。很多项目说自己“优化了缓存清理”，其实只是把清理时机拖晚了，但清理逻辑还是暴力全量清理，这样反而会造成回大厅后的新一轮卡顿。判断标准从来不是“有没有清缓存”，而是“有没有在需要的时候释放掉不需要的东西”。

6. 最后说几句实际的体会

我自己在一线调过不少资源管理和缓存相关的问题，最大的感受是：清理缓存一定要看场景，而不是看口号。对竞技游戏来说，对局过程中的稳定帧率一定高于大厅里的极致内存占用。为了对战不卡，很多工程上的选择看起来都“不聪明”——比如不在进对局前清大厅资源，宁愿让旧资源多占一会儿内存在切换时叠加；又比如打完再清，让玩家在结算页承受一点几乎不可感知的负载。但正是这些妥协，换来了最关键的对局体验不打折。

如果你也想给自己项目加缓存清理逻辑，我的建议是：把清理目标按“是否可重建、是否常用、是否大块”打分，优先在场景结束后的用户等待窗口去清理，不要在用户即将开始核心体验时做全量清扫。你甚至可以大胆一点，把部分高频资源做成常驻池，只要内存水位没告警，就让它们一直留着。缓存这东西，最大的价值就是“下次还能用上”，为了清而清，反而亏了。