背景

我们公司的产品是用Unity进行开发的，这有其历史原因：我们需要渲染大量的建筑模型构件，而Unity无论是从工具包还是渲染管线来看，都是相对较好的选择。

然而，随着开发进程的推进，单纯的建筑渲染已无法满足业务需求。我们还需要进行大量的UI相关工作，如填写表单、展示数据图表等。在这方面，Unity的能力相对薄弱，尤其是与Web技术相比。

因此，我们展开了两个方向的调研。一是使用Unity内嵌Web的方式，BIM模型渲染仍由Unity负责，而所有UI工作则交由Web来完成。

二是在Unity现有的工具包中选择更高效的UI搭建方式。目前，我们公司使用的是Unity主流的UI搭建方式——UGUI。除此之外，还有NGUI、FGUI以及UI Toolkit等UI工具可供选择。

我在之前的个人项目中有使用UGUI和FGUI的经验。FGUI拥有独立的图形编辑器，对设计师非常友好。设计师可以自行搭建prefab后交由开发使用，这提高了界面质量的掌控和整体效率。但在与技术组leader讨论后，我们认为FGUI作为一个开源项目，维护不够稳定，且作为技术升级并不能带来本质提升，不适合作为主要UI工具。因此，UI Toolkit成为了唯一的可能性。

随后，技术leader负责调研Unity内嵌Web的可能性，而我则负责调研UI Toolkit的情况，以及使用UI Toolkit可能带来的流程变化，如新的交接方式。最终，我们成功实现了Unity内嵌Web的方案。我也对UI Toolkit的调研结果进行了汇报（尽管最终没有派上用场）。

调研过程中，我总结了一些经验和探索记录，这些对设计师或未来进行独立开发时可能会有帮助。总的来说，与UGUI相比，UI Toolkit更像一个现代的前端工具，对于熟悉HTML、CSS等技术的界面设计师来说更加友好。

在接下来的内容中，我将不会深入技术细节，而是从设计师的角度进行探讨。例如：如果未来的项目中要使用UI Toolkit，设计师应该了解什么？现有的设计系统如何与UI Toolkit对接？

Unity UI Toolkit 简介

UI Toolkit 是 Unity 为创建用户界面（UI）而开发的一套工具集。它旨在取代旧的 Unity UI 系统，为开发者提供更灵活、高效的 UI 开发方式。以下是 UI Toolkit 的主要特点：

• 基于 XML 和 USS： 使用类似 HTML 的 UXML 定义 UI 结构，以及类似 CSS 的 USS 定义样式，使 UI 开发更直观、易管理。

• 跨平台兼容： 设计时考虑跨平台需求，可在编辑器、运行时和各种目标平台上一致运行。

• 性能优化： 相比旧 UI 系统，在渲染和内存使用方面有显著性能提升。

• 可视化编辑器： 提供 UI Builder 工具，允许开发者以可视化方式设计和编辑 UI。

• 灵活的布局系统： 支持弹性盒子（Flexbox）等现代布局技术，简化响应式 UI 创建。

• 样式继承： 通过 USS 轻松实现样式继承和重用，提高开发效率。

• 运行时动态创建： 支持运行时动态创建和修改 UI 元素，增加 UI 系统灵活性。

UI Toolkit 不仅适用于项目内 UI，还可用于编辑器扩展开发（它本来就是为创建编辑器扩展而生的），为 Unity 开发者提供了统一的 UI 解决方案。

UI Toolkit 与网页前端工具的比较

初次接触 UI Toolkit 时，需要了解许多工具，但仔细观察后，会发现它与浏览器前端渲染的结构非常相似。它使用 UXML 作为标记语言，USS 作为样式表，还可以使用 UQuery 查找元素可视化树。Unity 还提供了 UI Builder 和 UI Debugger 两个工具，前者类似于开发安卓时使用的 UI 编辑器，后者则是一个调试工具。

总的来说，UI Toolkit 为 Unity 开发者提供了一个类似于网页前端开发的工作流程，但更专注于游戏和应用程序开发的需求。对于熟悉网页开发的人来说，学习曲线可能相对平缓，但使用 UI Toolkit 仍然需要对 Unity 环境有一定的了解。

1. 高效的渲染：UI Toolkit采用优化的渲染流程，减少了DrawCall数量，提高UI渲染效率。它通过合并Mesh和优化数据传输给GPU，降低渲染开销。相比之下，UGUI在处理可循环滑动列表、图文混排、UI划分和资源按需加载等方面存在局限。这些问题在游戏UI中可能影响较小，但在工具类UI中累积的工作量却令人头疼。特别是滑动列表，一旦Item数量超过50个就会出现卡顿，导致每个项目都需要重新优化。

2. 渲染效果更丰富：根据试用体验，UI Toolkit对圆角、阴影和背景模糊的支持，使非游戏UI的搭建和渲染效果更加细腻。这从根本上解决了一些渲染和适配问题。

3. 基于XML和CSS：UI Toolkit借鉴了Web开发中的XML和CSS技术，使UI布局和样式定义更加灵活强大。这与Figma等设计工具更加契合。虽然这些技术已有20年历史，但仍是主流技术。设计师易于上手调试，能够更准确地实现设计意图。

与设计工具的对接

根据我的经验，Unity 前端工程师制作的界面质量通常不如同等条件下的 Web 前端工程师，这主要是由于工具的限制。Unity 需要大量切图，而现代设计中，UI 交付往往使用矢量格式或由前端自行绘制，从而避免了锯齿问题。虽然 CSS 存在一些历史遗留问题，但它对排版的控制仍然足够强大，Web 上的排版也因此变化多样。相比之下，Unity 在这方面的工具相当匮乏。更糟糕的是，Unity 甚至不支持阴影、描边和圆角的直接渲染，这些效果都需要通过逐个切图实现，而非代码生成。这无形中降低了最终产品的质量，拉低了界面设计的下限。

设计师向网页前端工程师交付设计和产出已有成熟的方法论和工具。无论是样式库、组件库还是最终页面，都有实用的规范和优秀的工具支持。在我与前端工程师的交接中，我会提供包含设计标注的页面、字号和颜色系统的CSS文件。我还会给他们设计组件库的查看权限，并与他们共同维护从设计到开发的组件库。这种方式大大减少了重复工作。我们的交接界面统一清晰，很少需要返工或重复调整。

如果我们决定使用UI Toolkit，我们该如何完成上述步骤呢？这里我提供两种方案：

方案一：由开发人员完成UXML、USS和少量贴图的界面搭建工作。这有助于他们更好地划分Prefab和页面结构。然而，对于不熟悉这套系统的开发工程师来说，可能难以保证界面质量，因此可能需要设计师的协助。最终成果可能类似于Web开发中的共同维护组件库。不过，与Web不同的是，UI Toolkit难以避免与其他UI系统甚至3D世界的混合使用，这为形成成熟的UI组件库带来了更多挑战。退而求其次，我们可以继续使用原有的交付结构，这仍能显著提升UI开发质量和效率。

方案二：由设计师完成可随时使用的UXML和USS公共样式，并搭配少量贴图构建独立页面。这相当于设计师为开发创造一个工具来优化开发效率。

当然，这两个方案的前提都是基于目前市面上缺乏一款优秀的插件。这种插件本可以帮助前端工程师快速从Figma界面获取USS样式，或者迅速生成相关代码，甚至提供一些成熟的UI Toolkit库。

虽然在我看来，UI Toolkit比UGUI更加简洁直观，而且它是Unity未来的UI布局方案，但我们不得不质疑：在Unity中开发非游戏UI界面的市场究竟有多大？正因如此，我认为短期内不太可能出现大量开源库或相应的工具支持。同样，一些复杂灵活的UI问题和高端UI效果也难以迅速实现。

那么，为什么不直接考虑使用Web技术呢？这正是我们在全面调研后，最终没有在工作中实施UI Toolkit的原因。不过，对于小型项目，我倒是不介意尝试使用它。