引言

VRTK (Virtual Reality Toolkit) 发布于2016年，初期受到了广大开发者的欢迎并被广泛采用。但是随着 VR 开发生态的发展，这款工具逐渐失去了最初的光芒。本文试图通过几个维度的分析，解释为什么目前不推荐使用 VRTK 进行开发的理由，希望能够为正在选择 VR 开发工具的开发者们提供一些参考和启示。

VRTK 的初期成功与高光时刻

VRTK 最初作为一款名为 SteamVR Unity Toolkit 的开发工具发布，在 Valve 的 SteamVR SDK（1.x） 基础上集成了一些便利的交互功能，以弥补当时 SteamVR SDK 功能相对匮乏的不足。在 3.0 版本发布后，VRTK 迎来了高光时刻，一直持续到 SteamVR 2.0 发布。VRTK 3.x 让 VR 开发变得更加高效和便利，开发者只需对相关组件进行简单配置，即可实现丰富的交互功能，这使其在 VR 行业起步阶段受到广大开发者的欢迎。也正是由于其便利性给开发者留下了深刻的印象，所以大家才会对随后的 VRTK 4 充满了期待。

然而随着 VR 开发生态的不断发展，以及 VRTK 开发团队自身的一些原因，VRTK 目前已不再是开发者的首选开发工具。

外部环境的变化

VRTK 发布之初，VR 行业还处于起步阶段，彼时主流 VR 平台主要是运行在 SteamVR 之上的 HTC VIVE 和 Oculus Rift，移动 VR 平台尚未兴起，更谈不上开发工具。很多目前开发者熟知的 VR 开发工具尚未发布，比如 MRTK、Interaction Toolkit、UltimateXR 以及收费的 Auto Hand、VR Interaction Framework 等。在这种环境下，多数开发者（至少是国内开发者）倾向于选择 VRTK 来开发 VR 项目。可以说，VRTK 的流行也是吃到了一波时代的红利。

但是随着时间的推移，VR 开发生态逐渐发展完善，越来越多的软件厂商先后发布了功能更加丰富的 VR 交互开发工具，后浪们各个生猛，工具个个好用，这其中也不乏巨头们的身影，比如 Unity、微软、Meta 等。

在这个过程中，VRTK 逐渐失去了竞争力。当然，以上只是外部因素，但是更多的还是其内部因素，以下。

架构的局限

上文提到 VRTK 在发布之初名称为 SteamVR Unity Toolkit，在 SteamVR SDK 之上为开发者集成了交互功能，虽然后续为了表明其通用性，改名为现在的 VRTK（Virtual Reality Toolkit），但是其核心的架构策略一直保留了下来，即 VRTK + VR SDK，也就是与 VR SDK 进行集成，开发者面向 VRTK 进行交互开发。这种架构在 VR 行业发展初期没有什么问题，毕竟市面上的 VR SDK 屈指可数，主要还是结合 SteamVR SDK，但随着生态的发展，问题逐渐显现。

首先，被集成的 VR SDK 也在变化发展。一旦其在架构上有了根本性的改变，在大版本更新以后，VRTK 就很难及时跟进集成了。这个问题在 SteamVR 2.0 发布以后显得尤为突出，因为 SteamVR SDK 在这个版本中进行了完全的重构，引入了新的输入系统，而彼时 VRTK 尚处于 3.x 阶段，两者并不兼容，甚至 SteamVR SDK 自身也不能实现面向其 1.x 版本的向下兼容。

所以在这段时间内便处于一个比较尴尬的局面——由于开发者尤其是初学者一般从 Unity 资源商店获取这两款工具，而资源商店仅提供它们的最新版本，此时开发者就要面临选择——要么只使用 SteamVR 2.x 开发项目，要么使用 VRTK 3 搭配 SteamVR 旧版本 1.x，实际上后者也是到目前为止使用 VRTK 的最佳组合。虽然随着 VRTK 4 的发布逐步解决了这个问题，但是其易用性大打折扣，此处按下不表，稍后再提。

其次，这种架构限制了跨平台的实现。随着越来越多 VR 硬件设备的涌现，碎片化的现象逐渐明显，分久必合，随着 OpenXR 标准的提出，跨平台的研发思路逐步体现在了各 XR 开发工具中。而 VRTK 并没有一套比较科学合理的跨平台解决方案，虽然一直有，但是这些年一直没有根本性的改变，相较于 Interaction Toolkit 面向 OpenXR 标准的实现策略，VRTK 的实现方案只能算作适配。作为侧面印证，举一例：Interaction Toolkit 所依赖的 Input System 实现跨平台的方案如此科学标准，以至于 MRTK、Snapdragon Spaces、ARFoundation 等工具均基于此系统来实现跨平台。

插一句题外话，虽然 SteamVR 2.x 也有自己的 Input System，实现思路也非常非常相似，但是受限于各方利益和竞争战略，并没有成为行业标准，也是可惜了。

另外，这种架构设计也给开发者带来一定的误导——好的交互功能必须要有两者集成才能实现。其实不然。以 Interaction Toolkit 为例，虽然会依赖一些 Package，但是这些 Package 与 Interaction Toolkit 作为交互开发的角色并不冲突，比如 Input system， 反而 Input System 是帮助 Interaction Toolkit 实现跨平台的核心角色。

开发团队规模

VRTK 到目前为止，依然只是由几名（可能是两名）独立开发者兼职业余维护，未来的不确定性较多，对于项目的技术选型来说，无疑也会面临一些风险。

首先是纪律性。作者思路跳跃较大，由于没有路线的约束，导致方案一改再改。在 VRTK 4 中，仅工具的安装和初始化配置，就已经更换了几回方案。这就像一个渣男常说的那句话：“我这个人，其实变数挺大的……" 几年前，国外出版过两本针对 VRTK 4 开发技术的书籍，现在拿来再看，基本上都不再适用了。这也是导致笔者不敢贸然跟进制作 VRTK 相关教程的直接原因。

其次是精力和时间的限制。VRTK 说大不大，说小其实也不小，特别是考虑到 VR 行业自 VRTK 发布以来的快速发展，开发工具需要更多考虑通用性，同时也要应对日益复杂的交互需求。虽然我们不提倡结构臃肿的工程师团队，但仅靠两个人在业余时间维护这样一个项目，显然有些力不从心。上文提到，VRTK 4 在新版本中尝试使用设计模式实现解耦，这可能也是导致开发周期延长的原因。尽管 Oculus 曾资助过开发团队，但这似乎并未显著提升开发进度。

VRTK 4 在很长一段时间（至少是几年）内一直没有摘掉 Beta 标签，这直接反映了开发进度的缓慢。

抛开项目进度不提，技术文档的完善、社区问题的解答、软件版本的迭代，也都需要大量的人力和精力投入。对于规模有限的团队来说，同时兼顾所有这些方面显然是一个巨大的挑战。

相比之下，其它主流 VR 开发工具往往有专门的团队提供支持。例如，Interaction Toolkit 由 Unity 官方团队开发维护，有明确的开发路线图，每次更新都有新交互功能的加入，带来开发效率的提升。以最近的工作为例，Unity 更新了基于 Interaction Toolkit 3.0 的 VR 模板，并在 Github 上完善了对应的示例项目，这种规模的改进和文档维护，对小团队而言在短时间内难以实现。持续的支持和迭代不仅提高了开发者的信心，也确保了工具能够跟上 XR 技术的快速发展步伐。

易用性与文档支持

还是因为架构问题，虽然在 VRTK 4 中能够明显看到有针对性的改变，但结合 VR SDK 的执念仍未完全放弃，导致易用性也大幅降低，这应该是 VRTK 不再受欢迎的直接原因之一。具体到使用，基本的初始化就需要进行多步配置，解耦的架构导致预制体的层级庞杂，组件和参数的名称晦涩难懂，对初学者非常不友好。

如果工具本身的学习曲线陡峭，还可以通过完善的文档支持来弥补。VRTK 在 3.x 时代，有非常详尽的文档说明，并配有丰富的示例场景，开发者可以轻松参考这些资源来实现所需功能。然而，到了 4.x 阶段，尤其是在发布初期，文档质量急剧下降，许多页面停留在 "to be completed" 的状态，开发者只能自行探索或在油管频道查看作者不定期推出的演示视频。虽然近期文档已有所改善，但其丰富程度和组织结构仍远不如 3.x 版本。此外，演示 demo 的数量减少，且组织逻辑欠缺条理，难以为开发者提供清晰的指导。

不可替代性逐渐降低

VRTK 4 相较于之前的版本，更多地侧重于组织架构的改变，而新功能的增加并不显著。曾经被视为 VRTK 特色的功能，如 SnapDropZone、双手交互、攀爬等，现在在其它 VR 开发工具中也能找到对应实现，例如 Interaction Toolkit 中的 Socket、Grab transformers、Climb 等。

据笔者不完全不专业统计，目前，就交互功能模块的种类和数量而言，VRTK 4 能实现的功能，Interaction Toolkit 基本都能实现；而 VRTK 4 不能实现的功能，视具体情况，Interaction Toolkit 也可能实现；Interaction Toolkit 不能实现的，VRTK4 也不能实现。这段比较绕，说白话便是，其它开发工具提供的功能已经基本覆盖了 VRTK 的优势领域，甚至在某些方面更胜一筹，比如混合现实、手部交互等。

此外，曾经被 VRTK 集成的 VR SDK，随着版本迭代，功能也逐渐丰富。以 SteamVR SDK 为例，其包含的 Interaction System 不仅能实现常见的 VR 交互功能，还加入了 Skeleton Poser 等极具特色的功能。这使得 VRTK 的集成优势变得不那么明显——VR SDK 本身已经能够胜任这些工作。在《VR博物馆项目实战教程》中，我们便是完全使用 SteamVR SDK 实现了项目的交互功能。

回顾开发者最初青睐 VRTK 的原因，一是简单快捷，二是功能丰富。而现在看来，VRTK 4 的功能并未显著增加，易用性反而有所下降，所以其不再是开发者的首选也就不奇怪了。

总结

基于以上的分析，VRTK 在 VR 行业发展初期起运较早，但是后期受限于团队、架构、产品等原因，并没有接住这波富贵。也有一种可能，悲观一些想，VRTK 可能仅仅是作者的踏板，毕竟学而优则仕，唱而优则演，免费的内容有多少人愿意为爱发电呢？

如果——我说的是如果——还有 VRTK 5 的话，建议抛弃与平台 SDK 集成的架构思想，成为一套开箱即用的跨平台 VR 交互开发工具，当然，特色交互功能要多一些，以及，更简洁高效的实现方式。

最后，回到标题，不推荐并不代表抵制，VRTK 依然是在项目开发前，在技术选型中的一个可选项，只是它可能是选项C或D。因为项目千差万别，需求千差万别，某些特定情况下它可能还是首选项，比如强势的项目领导有要求，比如软件版本有硬性要求，比如开发者不愿迈出舒适区等。VRTK 4 依然是可用的，只是现在有了更多的选择，这些选项也足够好。

以上是对 VRTK 做的几点简要分析，个人愚见，仅供参考。