综述
这篇报告基于我本人的实际经历。我入VR坑已经较久了，在过去几年间，我一体机，PC VR都使用过，不说一帆风顺，但仍能在探索中解决遭遇的各种问题。而在近一年间，我则主要使用Quest 3，通过Virtual Destop串流游玩。其似乎最先表现正常，但异常现象似乎从5-6月开始爆发。与之前的不同，这次这个问题直接让我陷入了几个月的半退坑状态。仔细一想，这个问题可能在最初就出现了，但其严重程度和诱发原因可能不同，在过去我要么视其为正常现象（例如VRChat中本来帧率问题就很严重），要么用一些玄学方法缓解。但就现在看来，我没有抓住问题的核心，导致了现在的局面。这次就不是那么轻松就能够解决的了。我在几个月时间内，多次通宵达旦的探索，但仍感觉其被一层迷雾笼罩，几乎没有找到任何有效的解决方法。为此我撰写本文，记录我的探索和发现，希望能够提示更多遭遇类似问题的人，并提供一些线索，希望能帮助在未来能够彻底解决这个问题。
配置
虽然这个问题并不一定基于具体的硬件配置，但作为本篇报告的测试平台，我还是将我的主要硬件配置给出，以便参考：
CPU：AMD Ryzen 7 9800X3D
显卡：微星RTX 4080 GAMING X TRIO
主板：技嘉 X870 AORUS ELITE WIFI7
内存：阿斯加特 女武神II DDR5 16 GB × 2 6000C28
电源：金泰克 NE 850
VR：Meta Quest 3
路由器：Redmi AX6000
而对于软件方面，你可以相信我在不同的Windows， NVIDIA驱动程序，Virtual Desktop，Meta Horizon OS版本上都进行尝试，且截止撰写时全部更新至了最新，不同版本之间没有明显的差异。所以这些软件的版本与我们探讨的内容大概率无关紧要。
现象
如同标题所说，我们要调查的是卡顿和掉帧现象，但这些现象在VR中可谓是家常便饭，社区已有广泛的疑难解答。但我们这次针对是是一种相当棘手的情况——其仍可被视为卡顿或掉帧的一种情况，但如果以这样的关键字在社区寻找解决方案，几乎只会石沉大海。为此，我们需要先明确在这种特殊情况下，这两个概念的具体表现。
卡顿（stuttering/skip frame）
在游玩过程中，游戏画面突然冻结，然后跳跃到最新的一帧，造成不连贯。其持续时间通常不长，但在VR这样的场景下，仅0.1秒就能让人体验极差。在实际情况下，其最多持续0.5秒-1秒。如果持续时间很短加之画面较为静态，可能不容易被发现，但音频仍然是一个明显的问题。在卡顿期间，可能会产生明显的爆破音，对沉浸感的打击巨大。这种卡顿如果是偶发，甚至是数分钟出现一次，都勉强能够接受。但其实际上在严重情况下每隔10秒就出现一次，并且可能伴随马上会提到的掉帧现象。由于其需要数秒钟恢复正常帧数，意味着画面几乎没有多少正常表现的时候，完全可以说不可游玩。
掉帧（dropped frames）
如上所述，掉帧可能伴随卡顿立刻出现，也可能只是卡顿没有出现明显掉帧，也有可能只是掉帧，这两者的具体产生原因和关联仍然不明。但总的来说，帧数会在很短的时间内降低至低于50%标准帧率的水平。例如对于120帧的设定，最严重时会掉至50帧左右。其通常需要数秒才能恢复正常，这样的帧率波动会造成人的明显不适感，甚至在高负载情景下稳定在40帧还难以接受。
也就是说，以下情况不在我们的讨论范围之内，而且很可能有明确的原因和解决方案：
由于硬件配置无法满足过高的分辨率或其他性能需求，造成平均帧率无法达到目标水平：其在同一场景内通常不会严重波动，并且能明显观察到硬件吃满，即在任务管理器中出现100%的使用率，以及在fpsVR的性能图表中出现长期的爆红或者爆紫。
由于追踪被干扰或丢失，造成的画面漂移，黑屏等现象：我也曾遭遇过类似的情况，但显然其帧率不会受到影响。
由于游戏自身优化问题，在特定场景造成卡顿或掉帧：其虽然表现很像，但卡顿和掉帧通常有明确的触发时机（例如触发大量粒子特效），而不是与游戏画面或逻辑无关的随机产生。
其他明显不符合描述的情况，例如主机网络丢包（其只会造成游戏逻辑冻结而不是帧率变化）等。
如果上述表现符合你的遭遇，说明你很可能也面临同样的问题。但这并不意味着根本原因很容易被锁定——其可能由完全不同的原因或多种原因的组合造成。我们接下来将详细探索这个异常现象背后的表现，其可能开始与你的表现出现差异，但这至少说明……你的问题并没有像我这样严重。
初步尝试
显然我在最初解决这个问题时犯了错误——没有进行详细的系统分析，而是就表现来猜测，并穷尽社区的解决方案。以下是许多首先被尝试，但都没有明显效果的方案：
WIFI有干扰？我停掉了区域内的所有其他5Ghz WiFi，并更改路由器信道至无干扰的149。这似乎在最初解决了一些轻微的爆音情况，但现在无法复现，说明当时的改善很可能是巧合。
Windows系统，显卡驱动，Virtual Desktop，Quest系统的某个版本出现Bug？如之前所述，无论是我尝试使用最新甚至测试版，或是回退安装社区稳定版，都没有任何改善。
特定游戏与串流软件的兼容性问题？对于Beat Saber来说，其社区确实报告了一些和Virtual Desktop的兼容性的问题，但其都很快被修复，但对于我来说没有改善。此外，其他游戏的测试也出现了相似的问题，表明不太可能是这个原因。
串流比特率设置的太高？我尝试过将其一直下拉，到50Mbps左右才似乎有所缓解，但这时的画面已经不忍直视，这种情况下都不能完全消除卡顿掉帧，不算是一个有用的解决方案。但这可能提醒了我们这个问题可能和网络可能有一定联系，但不一定是核心因素。
游戏分辨率太高？实际上基于我的硬件这个猜测本身就是不合理的，我甚至尝试过使用20%渲染分辨率，仍没有明确的改善。说明其显然和这个问题无关。
Virtual Desktop设置有问题？我通过控制变量法不断尝试了其中的大量项目，包括但不限于编码方式，自适应量化，2-Pass编码，加密本地流量，自动设置码率，锐化，SSW补帧，骁龙超分辨率，视频缓冲……全都没有效果。加之之后说的用其他串流也有类似问题，几乎可以认定并不是这方面的问题。
SteamVR社区所列出的所有已知确认造成卡顿或掉帧原因的解决方案，包括但不限于关闭照明应用程序，拔除可疑的USB设备避免拥塞，关闭监控应用程序，如Afterburner和SteamVR 的 GPU 监控，避免游戏桌面窗口被缩小化或焦点设置错误，拔除额外的显示器，设置正确的VR运行时，禁用第三方 SteamVR 叠加层，关闭录屏或直播软件，关闭如NVIDIA叠加层的第三方叠加层，禁用Windows系统显示卡的窗口化游戏优化和硬件加速GPU计划……其中有一些代价太大或是太过繁琐我没有尝试，例如将 BIOS 更改为使用PCI-e 3.0协议，禁用 fTPM，但我猜想很可能与这些底层原因无关。
总的来说就是能试的都试了，但没有任何明显改善的解决方案，反而可能把系统原有的功能破坏，所以我逐渐停滞了穷举尝试，打算对症下药。
玄学尝试
如上所述，在历经很长时间，各种尝试都无果的情况下，我开始寻找社区中针对类似问题还未尝试过的解决方案，其中有些甚至只是道听途说来的，很难说有什么直接证据：
更改电源设置中的处理器电源管理，将其最小处理器状态设置为100%：正是这个解决方案给了我重新探索的动力，其似乎也有那么一些道理，允许处理器降频很可能导致其在串流中未能即时响应。在设置并简单测试后，我满心欢喜的以为已经解决，但第二天问题再次出现，看来这又是一个巧合。事实上仔细思考也是，只要串流有足够多的CPU需求，CPU应该仍能保持活动，而不是像某些玄学解决方案的“原神挂后台提升显卡性能”这样离谱。况且游戏过程中，游戏本身对CPU的压力应该远高于串流，因为后者更依靠GPU进行编码。所以我只能遗憾的认定这种方式是无效的。
据传言说Ryzen CPU的CCD调度存在问题，于是我使用了Process Lasso来修改了CPU（顺带还有GPU）的设定，发现VR和Virtual Desktop的优先级本身就已经是夸张的实时，并且允许所有核心的使用。我将其更改为仅限特定核心也无济于事，况且这又不像是Intel大小核一样，9800 X3D的不同核是一样的。当然调度是深层机制，仅凭这点我很难说其调度不存在问题，但介于使用类似Ryzen CPU的玩家很多但这个问题相当罕见，所以我猜测可能和这点无关。
据网友反应，可能是电源频率问题，他换了一个插座就解决了。这个措施可以说是真·死马当活马医，我换了一个插座没有任何变化。细想也是，如果是频率问题，那么家里哪里的插座估计都会是一样的。并且电源本身还会进行转换，要在这种情况下还反应在硬件上已经很奇怪了，关键是其还只影响VR应用，再怎么也说不过去。这个解决方案也被遗憾排除。
在这些玄学方案又消耗了我大量时间后，我意识到这样不行：我连问题出在什么地方上都一无所知，例如究竟是串流问题？还是游戏本身的问题？甚至说是系统，硬件上的问题？不先精确确定一个方向，我就只能像无头苍蝇一样四处碰壁。于是我通过深度测试，尝试定位问题的来源。
深入研究
排查这个问题的一个难点是，VR游戏的桌面窗口画面实际上和VR画面不同，例如视角，分辨率等有所差别，所以并不能保证“桌面窗口内的画面不卡，VR也就不卡”。但我们还是先从这个角度入手，看看VR游戏在桌面上的表现如何。
我使用受到卡顿和掉帧影响最大的Beat Saber进行测试。首先，桌面分辨率被设置为了3440×1440，即我显示器的最大分辨率，其只是VR的最高分辨率的54%，但本身我们这样的卡顿也不太可能是单纯由分辨率引起，所以仍可以进行参考。我选择Beat Saber中的某一首歌曲，持续大约3分钟时间，看看这期间PC的表现如何。我们使用BSManager的FPFC模式在非VR环境启动（我们在后面将其称为桌面模式），并使用CapFrameX来录制帧率，使用内置的统计图表来展示：
图表 1：在桌面模式下运行Beat Saber的FPS图表
可以看到帧率如同吃了德芙一样丝滑，稳定在屏幕最大刷新率165Hz，而开头和结尾的掉帧则是因为进入和退出歌曲时的黑屏加载，实际上是无法察觉的，也是一种正常表现。这里我们注意到，我们的分辨率为VR分辨率的54%，但帧率却是VR的1.375倍。我们计算每秒的像素数对比，发现桌面环境为VR的75%，却仍没有任何帧率问题。那么是否是这额外的25%导致的呢？我们直接在同一环境再次测试，看看任务管理器中的性能图表。
图表 2：在桌面模式下运行Beat Saber的GPU性能图表
可以看到显卡可以说处于还没发力的情况，3D利用率仅为28%，仅有一些尖峰会上升到略高于50%，属于后台真的还能挂个原神的级别。至于显存，也只消耗了5.7 GB，没有任何爆显存的可能。而对于视频编码和解码来说，你可以看到我这里的视频解码有15%的占用，这是因为我还在后台挂着直播。此时没有任何视频编码占用，这一点需要注意，因为串流正依赖于视频编码，我们后面再来继续探索。总的来说，即使加上VR环境的25%性能需求提升，也很难想象GPU存在任何瓶颈。
那么CPU呢？实际上根据游戏常识，Beat Saber不可能吃很多CPU，这在我的CPU性能数据中也能体现，其在游戏中，无论是否正在播放歌曲，其利用率根本没有明显的变化，且平均只有20%左右。由于我也不知道Beat Saber如何使用CPU核心，这里的CPU数据显得过于杂乱，就不单独展示了。但显而易见的是，即使我们再考虑VR环境，可以说CPU也不存在任何瓶颈。
当然，其他不重要的我也就一笔带过了，例如显然内存和硬盘读写也是远远没达到被占满的级别，这些都不必纳入考虑。基于这些数据，我可以说我的硬件配置运行Beat Saber，做到完全不掉帧卡顿毫无问题。
不过考虑到还有许多像VRChat这样的游戏会将硬件吃满，我也测试了The Last Of Us Part II的表现。当然，测试结果是符合预期的，因为如果在正常游戏中也有类似的卡顿掉帧表现，我肯定早就注意到了。
图表 3：The Last Of Us Part II的FPS图表
可以看到，3A游戏确实有一定压力，帧率出现了一些波动，但由于整体非常高，可以说仍处于丝滑体验的级别，只有25%的帧率低于144帧，且最低也有140帧，没有出现掉到平均帧率一半左右，例如70-80帧的情况。当然我们这里是用一个平静场景进行测试，激烈场景可能平均帧率会下降，但就我个人体验也没有出现过能明显感知的掉帧情况。并且由于这次没有Beat Saber歌曲进入和退出时的加载卡顿，我们这里的Stuttering卡顿分析中没有检测到任何卡顿，占比为0%。这几乎是实锤，我的硬件性能不太可能是造成卡顿掉帧的元凶。
保险起见我们还是继续看一下硬件占用。如图所示，其基本上是高占用版本的Beat Saber，整体相当平稳，没有出现什么明显的波动。从这里我们得出结论：VR游戏在硬件使用上和PC游戏没有什么不同，不会出现PC游戏不卡，而VR游戏卡的情况。
图表 4：The Last Of Us Part II的GPU性能图表
那么既然纯PC环境不会出现问题，究竟是什么环节引入的卡顿呢？是VR模式的额外渲染，还是串流？这时我们开启VR模式，用Quest 3串流的同时，再同时用CapFrameX监视桌面窗口。
图表 5：在VR模式下运行Beat Saber并串流时其桌面窗口的FPS图表
可以看到卡顿明显出现了！此时光从FPS图表上就能看出许多明显的波动，其和之前The Last Of Us Part II的平滑在纵坐标较小的范围内波动不同，这种波动完全可以说坐过山车。Stuttering分析也明确找到了大量的卡顿占比，高达2.3%。
但这个实验仍不能确定究竟问题是因为启用VR模式造成的，还是串流造成的。于是，我们在VR模式直接使用一台PC VR直连和出现问题的Quest 3串流进行对比测试。注意，这里的PC VR使用的是Pimax 8KX，其原生分辨率高达双4K，也就是说极限情况可能比Quest 3串流高一倍。考虑到固定注视点渲染等技术可能略有优化，但总体硬件性能需求还是多了不少的。最后结果如下：
图表 6：直连（蓝色）与串流（橙色）的FPS对比
这里由于是VR环境，所以我们改用fspVR，使用其Frames data logging功能来记录，并导出数据进行分析。在观察串流的橙色曲线时，我们又一次看到了这个卡顿的离谱情况，其完全符合我们之前的描述，而且能够稳定复现。而直连即使硬件性能需求高了很多，其蓝色曲线却无比平稳，符合我们仅在桌面模式运行时的情况。也就是说我们的初步发现是：桌面模式或使用直连的VR模式下，桌面窗口和VR画面都不会出现问题。而串流时，无论是桌面窗口还是VR画面，都会出现卡顿掉帧。
在这里结论就比较明显了：由于串流时的某些因素，造成了PC上游戏的运行卡顿。这可以说是一个重要突破。
那么“某些因素”究竟是什么呢？橙色曲线的掉帧明显具有一定周期性，但却不在所有时间段都出现，一个合理的怀疑是这是由于多因素的影响，例如需要两个因素叠加才会出现周期性掉帧，或是某个因素造成了周期性掉帧，但另一个因素却在某些时候能阻挡掉帧。
我们之前已经说过，从我们的感知上，这个问题在所有游戏都会出现，但实际情况是不同游戏的掉帧卡顿情况似乎并不完全相同，这说明可能有和游戏有关的因素存在。我们直接针对不同游戏录制3分钟左右，来看看其表现。由于我们已经知道桌面和VR环境的卡顿是同步的，所以这里我们只记录了VR画面的表现。
图表 7：三款游戏的FPS对比
可以看到，三款游戏不说卡顿和掉帧完全一致，也是十分有九分相像了。但其中Steam VR Home的表现可能要稍好一些，其平均帧率较高，总帧数较多，这也是为什么其在横轴延伸出了最长的距离。而Pavlov的表现可能是个例外，因为其以前并没遇到过一段时间掉到20帧左右的情况，我猜测可能是fpsVR记录功能或是我在测试时开的其他测试软件的影响。如果抛开这一段异常，其表现也和另外两款非常接近。显然，这些游戏面临的都是同一个问题，并没有根本上的区别。但可以说游戏的性能需求可能会对其产生细微的影响。
那么接下来我们需要搞懂的显然就是，掉帧时到底发生了什么？既然原因应该是PC上游戏的运行卡顿，那么是某种系统资源被用完了吗？你可能想说从最先开始看fpsVR的那个性能图表不就知道了嘛，我还在这里绕圈，但实际上这并不是这么显著的。在使用Virtual Desktop串流时，在卡顿的一瞬间或是掉帧开始的时候，其GPU图表稳定，而CPU图表变化也相对轻微，只持续一两帧，有时一个红色或橙色尖峰，有时是一个一瞬间的绿色尖峰，且其高度表明其只占了最多一半的利用率。也就是说，我们可以先猜测这个问题是这个小尖峰引起的，但为什么尖峰只持续一两帧，掉帧却要数秒才能恢复仍然是一个问题。
图表 8：使用Virtual Desktop时出现的CPU小尖峰
而我自然也怀疑过串流的问题，试过其他串流，例如Steam Link。但令人头疼的是，无论是换个串流问题解决了，还是换个串流毫无改善，都能获取到有价值的线索，但实际上却是——换了个串流就换了一种问题。在Steam Link中，我能说整体表现更好，其掉帧更加少见，但却仍然保有大量的卡顿。在卡顿时，fpsVR性能图表出现带状紫色尖峰：
图表 9：使用Steam Link时出现的带状紫色尖峰
你说这怎么查嘛，查不下去了都……不过fpsVR的性能图表可能与系统逻辑不同，我们还是来看看任务管理器中的性能图表：
图表 10：使用Virtual Desktop时的GPU性能图表
可以看到，与fpsVR认定其表现平稳不同，在使用Virtual Desktop串流时，GPU的3D和视频编码都出现了相匹配的波谷，而卡顿正好出现在波谷的时候！而至于fpsVR揭示的CPU尖峰，我之前也说了，很难在任务管理器直观体现，所以我暂且认为这个GPU的使用率下降可能是核心问题。
那么Steam Link的情况又如何呢？既然他在fpsVR监视器就爆紫，那么在任务管理器中应该更明显吧？
图表 11 使用Steam Link时的GPU性能图表
结果给我整不会了，其反而更加不明显了！可以看到Virtual Desktop中出现的3D明显波谷，在这里却只有轻微的波谷，甚至总体来说居然能算平滑。而对于视频编码器，其仍然有波谷，但降低的程度不那么明显，持续时间也更短了。考虑到两者可能有不同的编码格式和策略，这种变化也可以理解，但仍然无法解释3D部分的明显不同。
所以你可以看到，虽然总体来说是同一种故障，但在两个串流软件中居然出现了两种不同表现，这实在难以捉摸。那么问题的核心是GPU性能吗？根本原因是3D性能的下降还是视频编码性能的下降，仍然不得而知。关键是其为什么会下降呢？由于之前的Beat Saber桌面模式和The Last Of Us Part II的测试，我们知道显卡在最高性能也表现正常，不可能存在供电不足的情况。
那么可以这样思考，之前的桌面游戏情况几乎说明了显卡的3D性能应该不存在问题，那我们就探索一下视频编码的影响。是否可能是视频编码能力突然下降，由于VR的什么自适应分辨率机制，又把3D自动调低了？听起来仍然很不靠谱。不过我们首先排除GPU编码器硬件故障的情况。借助ffmpeg，我使用
ffmpeg -f lavfi -i testsrc=duration=10:size=1920x1080:rate=60 -c:v h264_nvenc -preset fast output.mp4
来测试硬件编码能力，结果是：
frame= 600 fps=431 q=17.0 Lsize= 7200KiB time=00:00:10.00 bitrate=5898.3kbits/s speed=7.18x elapsed=0:00:01.39
好家伙，其表示我的GPU编码器在这个测试中能以 431 fps 的速度进行编码，说明有非常充足的性能冗余，并且speed=7.18x，表示整段视频只用了不到 1.4 秒就完成了 10 秒的编码任务。从这点来看GPU编码器正常的很。
况且编码器性能是否会对游戏产生影响，我们也可以用另一个方式测试。我直接后台挂一个Kdenlive的渲染任务，然后仍然是以Beat Saber桌面模式进行测试：
图表 12：在渲染同时以桌面模式运行Beat Saber的FPS图表
你可能注意到图表有更大波动，但这实际上是因为我这次没有记录进入和退出歌曲的时候，之前我们已经知道了其会因为加载导致卡顿。而这次没有这个卡顿之后，我们的纵轴范围是……156-167帧，也就是实际总体是极为平滑的。你可以看到前半段确实有相对更大的波动和有一次被记为卡顿的波谷，但在后半段后台渲染完成后，我们的帧数变得极为稳定。
我们再来看看这段期间的GPU表现：
图表 13：在渲染同时以桌面模式运行Beat Saber的GPU性能图表
可以看到GPU利用率确实随着渲染结束，视频编码利用率的下降而下降，但明显合理的解释是，视频渲染还用了GPU的一些通用计算能力，其可能会在类别中被分为3D。并且在编码结束后，后续3D曲线仍然是平滑的。而串流时，即使其显然是随时保持编码，其居然都出现了锯齿状波动，这是完全不合理的。我只能认为，3D利用率的下降和视频编码利用率的下降并没有直接因果关系。其更可能是有一种因素同时导致了他们两者的下降。
到底有什么和串流有关的因素，能同时导致3D和视频编码利用率的下降呢？串流一个最常见的问题就是网络因素，但首先我的路由器理论性能足够，并且也已经在最先的尝试过排除了大量可能。由于我现在没有额外的路由器可以测试，我确实不能保证并不是路由器造成的网络问题。但就目前这种表现来看，网络问题很可能不是罪魁祸首——其只会造成Quest 3的接收画面卡顿，而不会造成桌面窗口，也就是游戏本身卡顿。特别的，卡顿还可以这样解释，掉帧本身就更像是PC端的问题而不是串流问题。
结论
到这里我就没有额外的发现了。只能说其根本原因仍然扑朔迷离，可能需要额外的发现，这个问题才会有新的进展。我目前有只有这两个猜想：
未知软件或硬件与串流发生冲突，造成GPU 3D和视频编码性能下降，从而导致卡顿和掉帧。
网络因素造成串流质量下降，Virtual Desktop或Steam VR的某种机制同步了这种质量下降，例如降低分辨率或刷新率，且可能同时在处理时出现Bug，最终造成整个游戏卡顿掉帧。
第二个猜想听起来也是较为勉强的，不过就之前的调查来看，我确实是想不出更多合理的原因了。
建议
事实上我并没有穷尽所有可能的手段，这是出于资源和精力限制。如果你遭遇了这种情况，并想彻底解决，我认为至少还有几个可以探索的方向：
重装操作系统，只安装最少的组件来运行VR。如果有任何软件因素影响，其应该能在这个步骤中被排除。
更换GPU甚至可能的情况下更换主板或CPU（其实相当于换了一台电脑），使用控制变量法看哪个硬件可能是造成影响的罪魁祸首。
用一个经过验证，也就是目前在其他地方使用，且串流不卡的路由器，替换现有路由器，看看是否有和网络有关的因素。
使用Quest官方串流，看看其是否仍然像我们测试过的两个串流一样发生故障，或是有其他不同表现。我没有进行这个测试的原因是Meta Quest Link的安装的网络问题太多了，一直装不上。
不用串流，而是用Skybox等软件观察在本地网络播放视频是否会出现类似问题，进一步了解这个故障的影响范围。
使用开发者工具甚至是借助技术人员，抓取Quest 3在串流时接收的数据包，检查故障出现时是否有任何不寻常的表现，其可能会成为线索。
我不再探索的原因是因为在尝试了各种修复方案后，我隐约感到这个问题可能涉及到甚至我们根本不会去想的深层因素。例如如果我继续探索，穷尽了上述方向，仍然没有改善，那有什么合理的解释？总不能是我PC所在的地方风水不好，例如受到了附近电子设备的EMI干扰？这样排查下去感觉没有前途，几乎是要把几个领域的工程师叫到我家里来才能搞定的级别。所以不如趁早止损，改为使用现在测试表现正常的PC VR作为代替方案。毕竟如果VR买来没怎么玩，反而是一直在修，那就是本末倒置了。
另一方面是串流的不稳定要素实在是太多了，就算是解决了这个问题，其延迟，画质，稳定性都逊于PC VR的DP直连。PC VR头显几乎就是将显卡画面直接输送到屏幕上，这和电脑显示器的原理完全相同，而你几乎听不到社区里有什么“显示器造成卡顿掉帧”的例子，说明其早已是个成熟的方案。所以我个人在转向PC VR的同时，也推荐预算多，PC性能强的玩家优先考虑PC VR，前期可能投入较大，但最终能少折腾很多。
最后，希望社区能够群策群力，有朝一日能彻底解决这个问题，让未来的VR玩家不用再面临这样的折腾经历，更加轻松快乐的入坑。
