企业官网建设流程全解析

这个课题是我一个周六的下午被一个朋友“骗”进坑的。朋友跟我说，他打某款大型单机游戏时总是被掉帧折磨，后来随手把原神挂到后台（不是云原神，是PC客户端），原本卡成幻灯片的场景居然稳了不少。我第一反应是：你怕不是开了脑内补帧。但他说得信誓旦旦，甚至贴了两张监控截图给我。我本着“与其对线不如跑数据”的原则，把这件事拆成了一个正经的性能测试项目，前前后后折腾了三周，最后把本地原神进程、云原神客户端、Windows电源调度、GPU频率曲线、后台服务清理这几个因素全部过了一遍。这篇文章就是整个研究的完结总结，给同样被后台卡顿困扰的玩家，以及在纠结“怎么优化游戏帧率”的朋友一份可复现的参考。

1. 先说结论：这个“优化”到底是真效果还是玄学

1.1 现象还原与问题定义

先说最直观的实验现象。同一个测试场景，其他条件完全不变，前置条件只有：被测游戏前台运行，原神PC客户端以窗口化无边框方式挂在后台，并且手动把原神的后台帧率上限设置为15FPS。在这种状态下，被测游戏的一个高负载副本场景中，平均帧率提升大概4%到6%，最低1%帧（也就是玩家感知到的卡顿点）提升更明显，能到10%到15%。第一次测出这个数据时我自己也愣了一下，立刻怀疑是不是后台模式偷偷把被测游戏的画质设置改了，或者原神在后台切了一套动态分辨率。检查一圈后排除掉这些因素，我才决定把这个课题做完。

那这到底算不算“原神优化了其他游戏”？我的结论是：不属于主动优化，它没有也没法对其他游戏做任何干预，更不可能是什么跨进程的魔法。它真正做的事情，是把你的GPU和电源调度状态，从一个“容易睡着的状态”拉回到了一个“随时能跑满的状态”。说白了，原神在后台相当于一个低成本的“GPU保活进程”，至于保活之后收益有多大，要看你机器原本的调教有多激进。

1.2 研究思路：不满足于“有用”，要找到“为什么”

我做这类课题的习惯是先列所有能想到的候选机制，再逐个验证，而不是看到结果就下结论。候选机制包括：后台进程抢占了系统调度权，间接压制了其他后台服务；GPU没有被允许降到最低频率，保留了一条较高的频率基线；后台窗口的存在让驱动跳过某些低功耗暂停模式；还有可能是散热系统因为额外负载转了高转速，导致前台游戏温度更健康。这几条假设听着都有道理，但方向完全不同，必须用数据区分。

为了把这些假说分开，我准备了三条路的实验：第一，先用Process Explorer记录后台原神打开前后的线程、CPU、内存和GPU的变化；第二，用HWiNFO64把GPU频率、功耗、温度和总线占用全部记录下来；第三，用MSI Afterburner双通道记录被测游戏的平均帧和1% Low，并且用LatencyMon查一下DPC延迟有没有波动。这样一组下来，数据非常完整，网上的“玄学”也能落回到可验证的工程问题上。

2. 测试平台与观测方法

2.1 测试平台说明

测试机是我常用的游戏主机：CPU是Intel i5-12400F，显卡是RTX 3060 12GB，内存是两根DDR4 3200 8GB组双通道，存储是PCIe 3.0 NVMe固态，系统是Windows 11 23H2，驱动是NVIDIA Game Ready分支，版本号在测试期间保持一致。被测游戏我选了三款负载类型不同的作品：一款是开放世界动作RPG，一款是DX12下的光追场景较重的第三人称射击游戏，还有一款是CPU逻辑相对吃重的战略经营类游戏。三款都跑官方自带的基准测试或固定场景，尽量避免随机刷怪带来的误差。

为什么选这个配置？因为它不算顶配，但也不算太老，恰好是很多玩原神玩家的主流配置区间。顶配机器本身调度余量太大，可能根本看不出变化；太老的机器由于瓶颈太明显，后台多点少点都没用。12GB显存的3060也要说一下：它能覆盖大部分1080p场景，但又不会给后台原神留下太宽裕的显存富余，因此能暴露显存竞争的问题。

2.2 数据监测工具链

工具这块我没有全依赖某一款全家桶，而是每个工具负责一个专门维度。MSI Afterburner负责前台游戏的帧率、帧时间和1% Low，先把OSD叠加调到最小，避免屏幕取词影响性能；HWiNFO64负责硬件传感器，包括GPU核心频率、显存频率、显卡功耗、CPU全核频率和两枚风扇转速；Process Explorer负责看进程线程状态，重点观察原神进程的CPU时间、物理内存、GPU引擎使用率，以及它的线程优先级有没有被Windows自动调低；LatencyMon则用来盯系统DPC延迟和ISR延迟，防止某个驱动在后台抽风。

读取数据的方式也很常规：所有游戏跑固定的十分钟连续场景，前两分钟预热，后八分钟记录。用第二块屏幕或手机抓监控页面，而不是切换到桌面读数，因为一切换桌面，前台游戏会瞬间被Windows降低优先级，数据就废了。等三组A/B测试跑完，再把Afterburner的日志文件用Excel透视一遍，找规律比直接看曲线好用得多。

2.3 变量控制与误差处理

要验证“原神挂后台”这个单一变量，就必须把其他变量锁死。我做了四件事：第一，关闭被测游戏自己的自动更新、云端同步、录屏回放功能；第二，把微信、QQ、浏览器、Steam下载等占用型后台全部退出，但保留杀毒软件的后台进程，模拟正常玩家状态；第三，系统电源计划固定为“平衡”，这样测出来的差异才是真实差异，而不是高性能模式带来的无脑加成；第四，每轮改变前后台状态后都重启一次游戏，而不是在游戏运行中切出去挂原神，因为运行中切窗口会影响资源分配。

统计方法上有个容易被忽略的点：帧率数据不要简单取平均。平均帧率受少数极高帧影响很大，而玩家感知到的卡顿更接近最低百分位。我统一取中位数、1% Low和0.1% Low三个指标，每组数据至少重复三轮，再比较中位数，避免某一次后台自动更新造成的瞬时抖动污染结论。

2.4 平均帧率之外的三个重要指标

不少玩家喜欢用游戏内自带的帧率显示来判断流畅度，但平均帧率是一个非常具有欺骗性的指标。假设一秒钟内你渲染了59帧都很稳定，只有第60帧卡了50毫秒，平均帧率可能只下降1FPS左右，可肉眼感知到的卡顿却非常明显。所以我这次研究把主要判断依据放在1% Low和0.1% Low上：把每帧渲染时间按从小到大的顺序排列，1% Low代表最慢的那1%帧的速率，0.1% Low代表极端卡顿点，数值越低，掉帧感越强。

实际对比中经常出现这种情况：平均帧率只提升3%，但0.1% Low从22FPS涨到31FPS，游戏体验完全是两回事。反过来，如果一组测试平均帧率提升6%，但1% Low反而下降，说明后台优化带来的只是“跑分好看”，实际玩起来可能更神经刀。所以我给结论时的口径是：平均帧提升不超过3%时，我不认为游戏变流畅了；只有当1% Low或0.1% Low稳定改善超过5%，才算有效优化。

3. 后台原神进程的真实行为：它到底动了哪些系统资源

3.1 原神PC客户端挂后台的资源画像

很多人一听到“挂原神”第一反应是显卡要被吃满。实测下来，资源占用全看两个条件：后台是否激活、后台帧率上限设多少。如果把原神切到后台并且没做任何设置，它的GPU占用会跟着窗口刷新节奏走，依然可能吃掉40%到60%的显卡性能；但如果把它限制在15FPS并用静态镜头挂在传送点旁边，GPU占用能降到8%到15%，CPU占用基本在1%到3%，显存占用1.5GB到2.5GB，内存占用3GB上下。

这个资源画像说明一件事：原神在后台并不是那种会把机器拖垮的进程。它更像一个有不规则唤醒周期的小程序，每隔几十毫秒提交一帧渲染任务，让显卡处于“低频但保持活跃”的状态。相比纯静态桌面，这种状态的GPU最低频率会更高，频率爬升的速度也更快。加上原神使用的是Unity引擎的常规渲染管线，提交模式比较规律，所以它不会像视频网站那种突发解码任务一样频繁刺激驱动。

3.2 云原神与本地小进程的差别

按照热搜词里常提到的“云原神适配脚本”，这里也顺便测试了云原神场景。云原神的真实逻辑是：本地只运行一个很轻的客户端，负责视频流解码、输入回传和画面显示，游戏渲染计算全部在远端服务器完成。所以无论你怎么挂云原神，本地GPU都只是在你移动视角和解码画面时产生一点视频解码负载，完全不会持续推高3D引擎频率。实测中，挂云原神后台对被测游戏的帧率影响接近于零：既没有显著改善，也没有显著变卡。

所以如果你听人说“挂云原神也能优化其他游戏”，基本可以判定为个体感受偏差。云原神那点视频解码压力根本不足以让GPU维持高频率，也不可能配合电源调度产生保活效果。真想复现本文的效果，实验对象必须是本地PC端渲染的客户端，而不是云游戏。

3.3 GPU频率曲线和电源策略的连锁反应

后台原神最核心的影响不在“会不会卡”，而在于它改变了GPU的负载状态。现代显卡频率管理有一个共性：低负载时降到最低频，或者干脆进入待机暂停模式；当新一批渲染指令到来时再拉升频率并重新唤醒。这个唤醒和爬升的过程通常有几十到几百毫秒的延迟，在游戏启动瞬间、场景切换瞬间、突然从桌面切回游戏时最明显。玩家感受到的“卡一下”很多时候不是显卡算不动，而是频率还在爬、驱动还在等同步信号。

当原神以15FPS挂在后台时，相当于每66毫秒就有一批渲染任务到达显卡，驱动和显卡都来不及彻底休眠。这时你切回被测游戏，显卡已经在某个中间频率上待命，再用力拉升比从休眠彻底拉起来快得多。我用HWiNFO记过这样一组数据：不挂原神时，GPU从桌面待机切换到游戏高负载场景，核心频率从210MHz爬升到接近满载大概要400到600毫秒；挂原神后，这个爬升时间缩短到150到250毫秒。这个差距在头一两秒的画面里非常致命。

3.4 CPU调度与后台进程的“挤占效应”

第二个被很多人忽略的因素是CPU调度。Windows对前台进程有一套优先级机制：前台窗口所在进程默认会被临时提升优先级，而其他进程则被限制在后台调度类。当你把原神挂在后台，它作为一个持续占用少量CPU和GPU的进程，会占用一些后台调度资源，但这反而可能是件好事——因为系统里那些更爱乱跳的后台服务，比如自动更新、磁盘索引、消息通知、脚本守护进程，在资源紧张时会先被压一压。配合Windows的全屏优化行为，相当于原神做了个“挡箭牌”，替你的游戏前排挡住了部分后台动作。

不过这里要澄清一点：现代Windows 11有一个“效率模式”会把后台游戏进程的优先级自动调低，所以原神在后台并不总是能抢到资源。如果你的后台只有原神一个进程在活动，其他服务全休眠，那这种挤占效应基本看不见。很多玩家实际感受到的流畅，其实来自于他们为了“挂原神”而做的准备动作：关掉了浏览器、退出了聊天软件、关掉了下载工具。这些动作本身的优化效果就非常可观，和原神关系不大。

4. 四种机制假说与实测验证

4.1 假说A：GPU频率保底效应

这是我最先怀疑的一条，也是数据支持最明显的一条。实验方式：相同场景下，分别跑“不挂原神”和“挂原神后台15FPS”两组，记录被测游戏从启动到稳定跑满所需的帧时间曲线。结果：不挂原神时，进入战斗场景后前1到2秒存在明显的帧时间尖刺，1% Low偏低；挂原神后，开局帧时间尖刺明显变小。GPU频率日志进一步显示，第二组的显卡在切换瞬间保持在一个300MHz到500MHz的中间频率，而不是直接掉到最低的210MHz。

这个假说虽然成立，但要提一个边界：仅对被测游戏本身压力尚未跑到100%的情况有效。如果被测游戏已经把GPU长期顶在满载，拉高频率基线不会带来额外收益；真正受益的场景是那些突然切换视角、突然进入战斗，需要GPU从低频快速拉升的场景。

4.2 假说B：系统后台进程被“间接压制”

第二个假说在数据上只能算“部分成立”。我试过在后台保留浏览器、Steam下载任务、微信、以及一个杀毒软件的完整扫描进程，再开原神，看它们会不会被挤到更低优先级。Process Explorer显示，原神本身的线程优先级大多被Windows自动调为普通或者低，确实占了一些调度预算，但Windows并不会因为一个后台游戏就把杀毒软件的扫描线程杀掉。所谓“间接压制”更多发生在CPU满负荷状态，对于CPU没有满负荷的情况，后台服务本来就不影响帧率。

所以这个假说更适合解释“为什么有些配置较差的老机器挂原神反而更爽”。老机器CPU调度余量小，多一个原神进程会把很多不必要的后台更新任务挤出去，前台游戏能拿到的执行时间反而更多。但如果你用一台本来就比较新的高性能机器复测，这个效应会很弱。

4.3 假说C：帧生成节奏耦合

当时网上有一些讨论提到，后台窗口的存在可能让驱动进入不同的渲染同步模式，从而影响前台游戏的帧生成节奏。我在测试里特意观察了被测游戏的帧时间分布，发现挂原神前后，平均帧间距的分布形态没有规律性变化，只是前端的卡顿尖刺减少。也就是说，原神不会改变前台游戏本身的渲染节奏，它只改善了启动瞬间和负载切换瞬间的表现。

结论：这个假说不成立。游戏渲染是各自独立的交换链，不同进程之间并不会因为各自帧率不同造成某种共振效应。后台窗口的刷新率高低，也不参与前台游戏Present同步逻辑。网上的相关说法更多是把“切窗后的流畅减轻”当成了“帧节奏变规整”，实际是频率爬升时间缩短带来的感觉。

4.4 假说D：散热预热与机箱负压

这个假说是我在测到第二轮时偶然发现的。原神后台挂着时，显卡功耗差大约20W到40W，风扇转速会从待机的800转升到1100到1300转。机箱内部的整体温度反而可能更平稳：因为风扇提前转起来了，当被测游戏的大负载到来时，风扇已经有一定余量，温度上升曲线的斜率平缓一些。在散热冗余大的塔式风冷/大机箱系统上，这个效应对1% Low几乎无贡献，但当机箱积热严重时，它确实能在长时间游戏过程中降低几次撞击温度墙的触发概率。

我对这个假说的最终态度是：可以忽略，但不必否定。如果你想复现，注意记录核心温度和风扇转速曲线，别只看帧率就下结论。这也解释了为什么你挂一个视频网站或者挂个音乐播放器，通常遇不到这种效果——视频解码和处理音频的硬件单元很少把主渲染管线维持在活跃状态，而原神虽然只占15%GPU，但它用的就是同一套3D渲染管线，所以它触发的“保活”最直接。

4.5 综合结论：什么情况下“挂后台”值得做

把数据汇总之后，我整理了一张参考表，方便按自己的硬件情况直接对号入座：

一句话总结：原神后台优化的价值，主要是防呆，而不是提升。它的真正作用是让显卡保持清醒、让后台进程更安静，而不是把一台差一个档次的电脑变成高配机。在高端满负载场景下，挂不挂几乎没有区别。

5. 可复现的实操步骤：把“挂原神”变成通用优化策略

5.1 步骤一：给原神设置后台帧率上限

原神PC设置里有一个被很多人忽略的选项：后台帧率上限。默认可能是60FPS，建议在实验场景下直接调到15FPS。如果没有这个选项或版本太老，可以用RivaTuner为原神进程单独设置Global FPS limit，注意不要用全局后台限制，否则会连带限制被测游戏的帧率。

为什么要调低？原因有两个：一是降低原神对CPU/GPU的持续占用，避免和被测游戏抢资源；二是保留“周期性唤醒”能力。15FPS刚好是每66毫秒一次GPU提交，频率不高不低，既能让显卡维持中间频率，又不会因为过度渲染把显卡功耗抬得太高。实践中最忌讳的是把后台帧率设为“无限制”，那样原神后台一样能把功耗拉到几十上百瓦，前面的正收益全都会被抵消掉。

5.2 步骤二：系统级电源与调度准备

在Windows里把电源计划临时切到“高性能”或“卓越性能”，能显著强化前面的频率保底效应。执行方式最简单的是用控制面板点选，也可以用管理员权限运行powercfg命令：

powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

这个GUID对应的是Windows自带的高性能计划。注意不同语言版本系统显示名称不同，但GUID是通用的。如果你用“卓越性能”计划，它的GUID是e9a42b02-d5df-448d-aa00-03f14749eb61，普通版本的Windows 11不一定能看到，需要先用powercfg -duplicatescheme解锁。

这里提一句，高性能电源计划适合台式机和插电的笔记本，对电池供电的笔记本反而是副作用。电池模式下系统为了续航会主动限制显卡功耗，你即使挂原神也用不上频率保底效应。测试时尽量插电运行，并把Windows的电池模式切到最佳性能。

另外两个建议：开启Windows设置里的“游戏模式”和“硬件加速GPU计划”。硬件加速GPU调度能让GPU驱动自行管理显存和任务提交，对多任务并行有好处。设置路径：设置-系统-显示-图形-更改默认图形设置。改完需要重启，所以要在测试开始前一次性设好。

5.3 步骤三：选择合适的挂机状态

原神挂后台不是随便挂哪都行。经验是：要挂在大地图场景，角色停在传送点或人少的地方，镜头固定不动，最好关闭动态模糊和体积雾。不要挂在螺旋深渊、地脉花等持续战斗的副本入口，也不要挂在尘歌壶或角色界面，因为这种界面会触发高频UI渲染和阴影计算，CPU占用和GPU占用都会明显上升。也不要选需要持续联网校验的界面，避免网络线程频繁唤醒。

窗口模式建议用无边框窗口，而不是独占全屏。因为独占全屏的原神切到后台后，可能会进入驱动级的空转模式，反而把GPU直接推到最低频；无边框窗口模式下，Windows仍会对它做后台合成，但GPU能维持一个较低的活跃基线。同时把游戏音量调到最低，避免音频线程产生额外唤醒。挂好之后打开任务管理器确认一下，原神的GPU占用落在10%到20%区间，才算挂对了。

5.4 步骤四：用数据验证收益

复现的验证方式很简单：用MSI Afterburner先跑三组不挂原神的测试场景，记录平均帧率和1% Low；再挂原神后台，重复同样的三组。每组不要挑同一个时间点，而是加载同一个存档/固定场景文件，跑相同的路线。如果1% Low平均提升在5%以上，说明对你的配置有效；如果只有平均帧率涨但1% Low没变，大概率只是后台干扰减少的随机波动。

我踩过一个坑：只在一个场景测了一轮就下结论。后来发现被测游戏本身有动态加载机制，场景加载到后面几秒神经网络AI行为变化很大，第一轮数据里混了一次后台自动更新。分析数据时一定要打开日志看有没有某个瞬间的磁盘占用异常，否则会把假象当成结论。

5.5 长期方案：不依赖“挂游戏”的系统优化

既然核心是“让显卡保持健康的频率基线”，那就不必永远靠挂原神这招。驱动程序层面，NVIDIA用户可以把“电源管理模式”改成“最高性能优先”，AMD用户可以在显卡设置里把“最小GPU频率”拉高到500MHz上下，效果等同于一个轻量后台游戏。驱动不开这个选项时，桌面待机就是掉到最低频，开了以后显卡会在等待时保持更高频率，代价是待机功耗增加几瓦到十几瓦。

此外，关闭不必要的开机自启项、给游戏目录添加Defender排除项、把Windows游戏录制工具栏关掉，都比挂原神更直接。真正追求低延迟的用户，还可以试试在BIOS里开启Resizable BAR和Above 4G Decoding，这是硬件层面的优化，收益稳定，没有后台玄学成分。

6. 常见问题与避坑实录

6.1 为什么我挂原神反而更卡

最普遍的原因是内存爆了。原神PC客户端无论怎么设置，常年至少吃2.5GB到3.5GB物理内存，如果你机器是8GB或16GB，被测游戏又比较吃内存，多出来的3GB压力会导致Windows频繁把页面写入页面文件，磁盘占用一下飙到100%，后台带来的频率收益完全被这种系统级卡顿掩盖。解决思路要么升级内存，要么被测游戏开低一档纹理画质，要么改用云原神这个轻量后台，但那样又失去本地渲染保活的意义。

第二个原因是显存溢出。8GB显存显卡在原生2K或4K下玩游戏，显存本身就已经很紧张，后台原神再占1.5到2GB显存，游戏会开始动态降纹理分辨率，帧率反而下降。显存不足时无论如何都不建议后台挂本地游戏，直接用任务管理器看GPU引擎的“专享内存”数值最直观。

6.2 挂云原神为什么感觉没有用

前面已经解释过，云原神是远端渲染，本地只有视频解码线程，GPU不会收到持续的3D渲染指令。视频解码更多用到固定功能单元和视频引擎，这些单元的工作频率和着色器主频不是同一条曲线，它无法承担“保活”显卡核心的作用。所以云原神后台对本地游戏帧率的提升基本为零。

如果你看到网上有“云原神适配脚本优化游戏”的说法，多半是把云原神客户端本身当作一个资源清理工具在用，而不是靠云渲染优化本地帧率。那些效果的来源往往是脚本同时关闭了很多后台服务，和云原神本身没有直接关系。要复现本文的机制，请用本地客户端，不要用云端流媒体版本。

6.3 后台原神被自动暂停/掉帧

Windows 11最近几个版本对后台游戏比较激进，会把长时间不操作的进程丢进“效率模式”，通过降低线程优先级和限制后台帧率来节省资源。结果就是：原神挂在后台一段时间后，可能自动被压到很低的执行频率，GPU占用掉到个位数，失去保活作用。如果你发现挂后台两三分钟后，原神在任务管理器GPU图表里的波形明显变稀疏，就要检查它的进程是否被标上了树叶图标（效率模式）。

解决办法：进入设置-系统-电源-电池使用情况（笔记本）或后台应用权限（台式机不一定有），把原神的后台运行权限设为“始终允许”。如果版本里没有对应选项，可以用Process Explorer手动把原神进程的线程优先级从Low调回Normal，但这需要写一个小脚本，普通玩家不建议在每次启动游戏时手动操作。

6.4 想写脚本一键优化，有哪些坑

顺着热搜词里的bat脚本话题，如果想把这套实验自动化，可以写一个简单的批处理，做三件事：设置高性能电源计划、把被测游戏进程移到优先级High、把原神的后台帧率限制通过命令行或者配置文件生效。我自己的示例脚本大致长这样：

@echo off :: 切换到高性能电源计划 powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c :: 提高被测游戏进程优先级（需要以管理员身份运行） wmic process where name="YourGame.exe" CALL setpriority "high" :: 等待10秒后启动原神，确保顺序正确 timeout /t 10 start /d "D:\Genshin Impact\" yuanshen.exe echo done

脚本只做无害操作。不要尝试通过永久关闭系统服务、禁用Defender、强制结束svchost.exe这类方式来优化游戏。我见过有人为压后台进程把Windows搜索、系统音量、打印机池全部禁用，结果游戏没流畅多少，系统先出了问题。安全稳定的优化边界，应该停留在电源计划、进程优先级和开机自启管理这个层面。

6.5 安全警示：不要为了优化去乱装工具

这个话题很容易被包装成“某某原神科技小工具”、“原神解帧工具、后台优化脚本”，坦白讲这类东西风险很高。只要不是米哈游官方实现的客户端功能，任何宣称能改变原神运行逻辑的第三方工具，都可能涉及修改客户端内存数据，轻则触发游戏账号安全策略，重则窃取系统权限。我在整个实验过程中没有对原神客户端做任何修改，也没有使用非官方插件，只动系统层的电源和进程调度，这是底线。

如果你只是想要更好的游戏体验，优先在官方设置和Windows系统设置里找答案。所有需要下载一个“绿色版优化器”才能完成的操作，都建议先查一下它的签名、更新时间和用户在社区里的反馈再决定。网络安全性值得多花两分钟，不要在卡顿时随便双击一个来路不明的exe。

7. 项目收尾与个人体会

按惯例复述一下我这次研究最想传递的一句话：原神挂后台优化其他游戏，本质不是原神在帮你，而是那个低占用渲染进程恰好补齐了系统调度的短板。它对一部分配置有效，对另一部分配置无效，甚至可能负优化。真正可以做长期收益的，还是驱动设置、电源管理、硬件调度这几件正事。

我在最后一次数据清洗时感受到，很多人其实分不清“有效”和“感觉到有效”。如果没有日志和帧时间分布，只凭眼睛看，挂不挂原神都会得出“有变化”的结论。这也是为什么我坚持把所有结论都写在1% Low和0.1% Low上，而不是平均帧率上。个人经验是：测试时保留一份原始日志，隔几天再回看，比当场判断靠谱得多。

这个课题我到这就算完结了。如果后续要扩展，我可能会把这套监测流程整理成一份持续采集的小工具，给不同游戏自动切换电源计划，也算是对这次研究的一个落地交代。希望对同样在研究游戏流畅度的朋友有帮助。