1. 从“挂后台”说起一个被误读的现象“研究原神为什么挂后台优化其他游戏”——这个标题我第一次看到的时候脑子里蹦出来的不是技术分析而是一个很具体的画面一台不算太新的笔记本前台跑着某款竞技游戏后台挂着原神然后帧数莫名其妙地稳了。很多人第一反应是玄学第二反应是“原神在后台偷偷帮你清显存”。这两个反应都不太对但第二个至少摸到了门边。先把结论摆在前面原神挂后台能让其他游戏变流畅绝大多数情况下不是原神主动做了什么“优化”而是它作为一个基于 Unity 引擎、带有完整 DXGI 交换链和显存管理机制的大型应用在后台状态下改变了整个系统的资源分配格局。换句话说它不是“帮手”它是一个“占位者”而它的占位方式恰好对某些游戏有利。这个现象背后牵扯到的关键词很集中原神、Unity、DXGI、显存、垃圾回收。这五个词基本覆盖了从引擎层到驱动层再到操作系统层的完整链路。我写这篇东西的目的不是给某个“玄学优化法”站台而是把这套机制拆开让你明白什么时候该用、什么时候用了反而更糟以及如果你想在自己的项目里复现类似效果应该从哪个方向下手。适合读这篇的人有三类一是遇到过低显存环境下帧数波动、想搞清楚原因的玩家二是做 Unity 开发、对 DXGI 和显存管理只有模糊概念的工程师三是任何对“后台进程如何影响前台性能”这个命题感兴趣的技术人。不需要你懂图形学但需要你愿意跟着我把一层层剥开。2. 核心机制拆解后台进程到底改变了什么2.1 Unity 的显存分配策略与 DXGI 的角色要理解这个现象得先知道 Unity 在 Windows 上是怎么管显存的。Unity 本身不直接跟显卡驱动打交道它通过DXGIDirectX Graphics Infrastructure这一层来创建交换链、管理后台缓冲、处理 Present 调用。DXGI 是 DirectX 里负责“图形基础设施”的部分它不管渲染管线怎么画只管资源怎么在 GPU 和系统之间流转。Unity 在启动时会向 DXGI 申请一块显存用于交换链的后台缓冲。这个缓冲的大小取决于分辨率、颜色格式和缓冲数量。以 1080p、BGRA8、双缓冲为例单块缓冲约 1920×1080×4 字节 ≈ 8.3MB双缓冲就是 16.6MB 左右。听起来不多但 Unity 还会申请深度缓冲、各种 RenderTexture、纹理资源一个中等规模场景轻松吃掉几百 MB 到 1GB 以上的显存。关键在于DXGI 的交换链在窗口最小化或失去焦点时行为会发生变化。当原神切到后台它的窗口不再处于前台DXGI 会进入一种“节流”状态。具体表现是 Present 调用被限制频率后台缓冲的翻转不再以显示器刷新率为目标。这时候原神的渲染负载骤降但它已经申请的显存并不会立刻释放。这就是第一个关键点原神挂后台时它占着显存不放但几乎不产生新的渲染压力。对于显存总量紧张的机器来说这看起来是坏事——它占了资源却不干活。但事情没这么简单。2.2 显存压力如何影响前台游戏的帧生成现代游戏在显存不足时的表现不是“直接崩溃”而是帧生成时间剧烈波动。原因是当 GPU 需要访问的纹理或缓冲不在显存里时驱动会触发换页操作把数据从系统内存搬到显存。这个搬运过程走的是 PCIe 总线延迟远高于显存内部访问。表现出来就是大部分帧正常偶尔卡一下卡顿的间隔和幅度取决于换页的频率和数据量。原神在后台占着的那部分显存实际上起到了一个**“显存水位锚定”**的作用。它让系统的显存分配器处于一个相对紧张但稳定的状态。前台游戏启动时驱动和引擎会根据当前可用显存来调整自己的资源分配策略。如果显存非常充裕引擎倾向于“能缓存就缓存”把大量资源预加载到显存里导致显存占用迅速逼近上限。一旦逼近上限换页开始卡顿出现。反过来如果原神已经占了一部分显存前台游戏在启动时检测到的可用显存较少它会采取更保守的缓存策略——少缓存、多流式加载。流式加载虽然单次延迟高但它是可预测的、均匀分布的不会造成突发性的换页风暴。这就是为什么有些人感觉“挂了原神之后反而更稳了”——不是帧数变高了是帧生成时间的方差变小了。注意这个效果高度依赖于具体游戏的资源管理策略和驱动的换页算法。不是所有游戏都吃这一套有些游戏在显存紧张时会直接降画质或频繁卡顿那就得不偿失。2.3 垃圾回收与后台进程的 CPU 时间片博弈热词里出现了“jvm垃圾回收机制”和“垃圾回收卡顿”虽然原神不是跑在 JVM 上的但垃圾回收这个概念在 Unity 里同样存在只是形式不同。Unity 使用Boehm-Demers-Weiser 垃圾回收器简称 Boehm GC它是一种保守式、非分代的 GC。Mono 和 IL2CPP 后端都会用到它。BoEhm GC 的特点是它不知道对象的精确类型只能保守地扫描内存把看起来像指针的值都当作指针处理。这导致它的回收效率不高而且回收时机不可控。当堆内存增长到一定阈值时GC 会触发一次全量扫描这个过程会暂停所有托管线程Stop-The-World。在游戏里这就是一次明显的卡顿。原神挂后台时它的托管堆基本不再增长——没有新的游戏逻辑对象被创建GC 触发频率降到极低。但它的堆内存仍然占着。这部分内存对前台游戏来说意味着系统总内存的可用量减少。前台游戏在分配内存时操作系统需要更频繁地做页面回收和内存压缩这本身也有开销。但这里有个微妙的平衡如果系统内存非常充裕原神占的那点内存无所谓如果系统内存紧张原神的存在会加速前台游戏触发自己的 GC 或资源卸载逻辑。有些游戏在内存压力下会主动卸载不常用的资源反而减少了后续的卡顿。这又是一个“占位者改变资源分配格局”的例子。2.4 为什么是原神而不是别的游戏你可能会问既然原理是“后台占位”那挂任何大型游戏不都一样吗理论上是的但原神有几个特殊性让它成为这个现象的“最佳主角”。第一原神是基于 Unity 的而且是一个长时间运行、资源加载量大、显存占用高的 Unity 应用。它的显存占用通常在 1.5GB 到 3GB 之间取决于画质和分辨率这个量级刚好能对中低端显卡4GB 到 6GB 显存形成有效的“水位锚定”又不至于把显存完全占满导致前台游戏无法启动。第二原神在后台时的CPU 占用极低。Unity 的 PlayerLoop 在失去焦点后会被大幅节流渲染线程基本休眠逻辑线程也只维持最低限度的网络同步。这意味着它不会跟前台游戏抢 CPU 时间片。如果换成某个后台仍然疯狂跑逻辑的游戏效果可能完全相反。第三原神的DXGI 交换链行为比较规范。它在后台时会正确进入节流状态不会出现某些游戏那种“后台仍然以高频率 Present”的异常行为。这让它对前台游戏的干扰降到了最低。把这三点合起来看原神挂后台的效果可以总结为用可控的显存占用换取前台游戏更保守的资源策略同时不引入额外的 CPU 和 GPU 竞争。这是一个特定条件下的副作用不是设计出来的功能。3. 实操验证怎么复现、怎么测量、怎么判断有没有用3.1 测量工具与关键指标光靠“感觉流畅了”是不靠谱的。要验证这个现象你需要至少能测量以下指标帧生成时间Frame Time不是平均帧率是每帧的耗时。用 MSI Afterburner RTSS 可以记录 frametime 曲线。重点看 1% Low 和 0.1% Low这两个指标反映卡顿程度。显存占用VRAM Usage用 GPU-Z 或 Afterburner 监控。注意区分“专用显存”和“共享显存”。系统内存占用任务管理器或 RAMMap。GPU 利用率Afterburner 可以看到 GPU 核心和显存的负载。我自己的测试环境是一台 i5-12400F RTX 3060 12GB 32GB DDR4 的台式机以及一台 R7 5800H RTX 3060 Laptop 6GB 16GB DDR4 的笔记本。两台机器上都做了对比测试。3.2 对比测试的设计与结果测试方法很简单选一款对显存敏感的游戏我用了《赛博朋克 2077》和《霍格沃茨之遗》分别在“不挂原神”和“挂原神后台”两种状态下跑同一段场景记录 frametime。在台式机 12GB 显存上两种状态的差异几乎为零。因为 12GB 对于 1080p 高画质来说足够充裕原神占的那 2GB 不影响前台游戏的资源策略。这验证了前面的判断这个现象只在显存紧张时才有意义。在笔记本 6GB 显存上差异出现了。《霍格沃茨之遗》在 1080p 中画质下不挂原神时显存占用会冲到 5.8GB 左右frametime 曲线有明显的周期性尖峰1% Low 在 28fps 左右。挂上原神后台后前台游戏的显存占用稳定在 4.5GB 到 5GB 之间frametime 尖峰幅度减小1% Low 提升到 35fps 左右。平均帧率变化不大但卡顿感明显减轻。提示这个测试结果只代表我手头的硬件和游戏版本。不同驱动版本、不同游戏补丁都可能改变结果。不要把它当成普适规律。3.3 操作步骤与注意事项如果你想自己试按这个流程来先在不挂任何后台程序的情况下跑一段固定场景用 Afterburner 记录 frametime 和显存占用。这是基线。启动原神登录后切到后台AltTab 或直接最小化。确认原神进程仍在运行但 CPU 和 GPU 占用降到低位。再跑同一段场景记录同样的指标。对比 frametime 曲线的 1% Low 和 0.1% Low以及显存占用的峰值和均值。注意事项有几条是踩过坑才明白的原神必须真正进入游戏世界后再切后台。如果停在登录界面或加载界面它的资源加载不完整显存占用远低于正常水平起不到“水位锚定”的作用。不要开原神的“后台保持高帧率”之类的选项如果版本里有的话。那会让它在后台仍然占用 GPU效果适得其反。显存小于 4GB 的显卡不要试。原神自己就要占 1.5GB 以上剩下的显存不够前台游戏跑会直接触发频繁换页比不挂还卡。系统内存小于 16GB 要谨慎。原神后台占用的系统内存加上前台游戏可能触发操作系统的页面文件交换那就不是显存问题了是整个系统都在卡。3.4 一个容易被忽略的变量驱动版本NVIDIA 和 AMD 的驱动在不同版本中对显存管理的策略是有差异的。我遇到过某个版本的 NVIDIA 驱动在显存接近满时换页特别激进导致 frametime 尖峰非常密集换到另一个版本后同样的显存占用下换页更平滑。AMD 那边也有类似情况尤其是 SAMSmart Access Memory开启后显存和系统内存之间的数据搬运效率会变化间接影响这个现象的表现。所以如果你试了发现没效果先别急着否定。换个驱动版本再试一次有时候结论会反过来。这不是玄学是驱动层的资源管理策略本身就在不断调整。4. 从现象到原理如果你想在自己的 Unity 项目里复现类似效果4.1 Unity 后台节流的正确配置Unity 提供了Application.runInBackground这个属性。默认情况下它在 Editor 里是 true在构建后的 Player 里是 false。也就是说打包出来的游戏默认在失去焦点时会暂停 PlayerLoop。但“暂停”不等于“释放资源”。如果你想让自己的 Unity 应用在后台时像原神那样“占着显存但不干活”需要做几件事确保Application.runInBackground false让 PlayerLoop 在后台停止。在OnApplicationFocus(false)回调里手动调用Resources.UnloadUnusedAssets()之前要三思——这会把未使用的资源卸载掉反而释放了显存起不到占位作用。如果你确实想保留显存占用就不要在失焦时卸载资源只停止渲染和逻辑更新。但这里有个矛盾Unity 的Resources.UnloadUnusedAssets()是异步的而且它只卸载没有被引用的资源。如果你在后台时仍然持有大量资源的引用比如场景对象没销毁这些资源就不会被卸载显存占用会保持。这恰好就是原神的情况——它后台时场景还在资源引用还在所以显存不释放。4.2 DXGI 交换链的后台行为控制在原生 DXGI 层面交换链的后台行为由IDXGISwapChain::Present的SyncInterval和Flags参数控制。当窗口不可见时DXGI 会自动进入一种“丢弃模式”discard mode后台缓冲的内容不再保证有效。但显存分配本身不会因为窗口不可见就释放。如果你想精确控制可以监听WM_SIZE消息当窗口最小化时调用IDXGISwapChain::ResizeBuffers把缓冲尺寸缩到最小比如 1×1这样能释放大部分交换链显存。但原神没有这么做它保持了原始缓冲尺寸所以显存占用维持在高位。这给了我们一个启示交换链的显存占用是可以主动控制的。如果你的目标是“占位”就保持缓冲尺寸不变如果你的目标是“让出资源”就在最小化时缩小缓冲。4.3 垃圾回收的时机控制Unity 的 Boehm GC 不支持手动触发精确回收但你可以通过GC.Collect()强制触发一次全量回收。不过这个操作开销很大不建议在运行时频繁调用。更实际的做法是控制托管堆的增长速度。在后台时停止创建新的托管对象让 GC 自然进入低频率状态。同时避免在后台时调用Resources.UnloadUnusedAssets()因为那会触发资源卸载和可能的 GC。如果你用的是 IL2CPP 后端GC 的行为会有所不同。IL2CPP 仍然使用 Boehm GC但生成的 C 代码对内存的访问模式不同GC 的扫描效率会变化。实测下来IL2CPP 后端的 GC 暂停时间通常比 Mono 短但堆内存的碎片化程度可能更高。4.4 一个可参考的“占位”实现思路假设你想在自己的 Unity 项目里实现类似“后台占位”的效果可以按这个思路来在Awake里加载一组占位资源比如几个大纹理确保它们被静态引用持有不会被 GC 回收。在OnApplicationFocus(false)里停止所有渲染和逻辑更新但不卸载任何资源。在OnApplicationFocus(true)里恢复更新并根据需要决定是否释放占位资源。监控Profiler.GetTotalAllocatedMemoryLong()和Profiler.GetAllocatedMemoryForGraphicsDriver()确保显存占用维持在目标水位。这个思路的核心是用可控的资源持有来影响系统的资源分配策略。它不是“优化”是一种资源博弈手段。用得好能稳定帧生成时间用不好就是纯粹的资源浪费。5. 常见问题与排查技巧实录5.1 挂了原神反而更卡了怎么回事这是最常见的问题。原因通常有三个显存太小4GB 及以下的显卡原神占完后前台游戏没有足够显存换页频率暴增。解决办法就是别挂。系统内存不足16GB 以下内存的机器原神后台占用加上前台游戏可能触发页面文件交换。检查任务管理器的“提交大小”是否接近物理内存上限。前台游戏本身有内存泄漏或显存泄漏有些游戏在长时间运行后显存占用会持续增长原神的存在加速了达到上限的过程。这种游戏挂不挂都会卡只是时间问题。排查顺序先看显存占用峰值再看系统内存提交量最后看前台游戏的 frametime 曲线是否有周期性尖峰。如果尖峰间隔规律且幅度大基本就是换页导致的。5.2 哪些游戏适合用这个方法从原理推导适合的游戏应该满足对显存敏感、有流式加载机制、帧生成时间对显存压力敏感。具体来说游戏类型是否适合原因开放世界 3A适合资源量大显存敏感流式加载普遍竞技类网游不太适合资源量小显存充裕原神占位反而可能抢内存带宽独立小游戏不适合本身显存占用低原神的存在纯属浪费模拟经营类看情况如果模组多、资源量大可能适合5.3 除了原神还有什么可以当“占位者”理论上任何大型 Unity 或 Unreal 游戏都可以。但选择占位者时要注意后台 CPU 占用要低有些游戏在后台仍然跑逻辑会抢 CPU。显存占用要稳定有些游戏在后台会逐渐释放资源占位效果不稳定。不要选反作弊严格的游戏后台挂载可能触发反作弊误判这个风险自己权衡。我试过用《崩坏星穹铁道》和《幻塔》当占位者效果和原神类似但原神的后台节流最彻底CPU 占用最低。这可能跟 Unity 版本和项目配置有关。5.4 这个现象在云游戏场景下有什么不同热词里出现了“云原神适配脚本”这让我想到云游戏场景。在云游戏里客户端只负责解码视频流游戏本身跑在服务器上。这时候“挂后台”的概念完全变了——客户端挂后台只是停止解码服务器上的游戏实例仍然在跑。如果你在云游戏平台上玩本地挂原神对云游戏客户端的性能影响很小因为云游戏客户端本身资源占用低。但如果你在本地跑游戏的同时开云原神那云原神客户端会占用网络带宽和一定的解码资源可能反而影响本地游戏的网络延迟。5.5 排查速查表现象可能原因排查方法解决方向挂原神后帧数下降显存不足GPU-Z 看显存占用降低前台游戏画质或别挂挂原神后卡顿更频繁系统内存不足任务管理器看提交大小加内存或别挂挂原神后没变化显存充裕看显存占用是否低于 70%正常不需要这个方法挂原神后偶尔卡死驱动换页异常看事件查看器是否有驱动超时换驱动版本原神后台 CPU 占用高后台节流失效任务管理器看 CPU 占用检查原神设置或换占位者6. 一些个人体会和后续可以玩的方向这个现象我断断续续研究了大概两个月中间换过三次驱动、两台机器、五款游戏。最大的体会是不要把它当成一个“优化技巧”去传播它更像是一个理解系统资源分配的窗口。通过它你能直观地看到显存压力、DXGI 交换链行为、GC 时机、驱动换页策略这些东西是怎么纠缠在一起的。如果你是对 Unity 开发感兴趣的我建议你顺着这个线索去读一读 Unity 的Application.runInBackground文档、DXGI 的Present参数说明、以及 Boehm GC 的触发条件。这些文档单独看都很枯燥但当你带着“为什么挂后台能影响前台”这个问题去看会发现很多之前忽略的细节。后续我打算试试用 RenderDoc 抓一帧原神后台时的 GPU 状态看看它的交换链到底处于什么模式以及显存里到底驻留了哪些资源。这个分析如果做出来应该能把“占位”的机制再往下挖一层。不过那是另一个话题了这里先打住。
