1. UIToolkit 运行时――下一代 UI 零碎
UIToolkit 的前身是 UIElement，公布于 Unity 2018。起初它用于开发 Editor 编辑面板中的 UI，自 Unity 2019、Unity 2020 起正式反对运行时 UI 并且更名为 UIToolkit，它以 Package 包的模式存在。自 Unity 2021.2 起，UIToolkit 被官网内置在 Unity 中和 UGUI 的位置统一，UIToolkit 作为下一代 UI 零碎，设计之初指标就很明确，就是替换掉现有的 UGUI 零碎。
现有的 UGUI 零碎从 2014 年自 Unity 4.6 开始至今服务于太多我的项目，从我的角度来看 UGUI 应用上并没有太大问题，最大的问题就是效率低。我用 UGUI 也开发了好几款我的项目了，每个我的项目开发阶段都被吐槽 UI 关上慢、卡顿等等，导致咱们不得不花很多工夫去优化 UI 零碎。
可循环滑动列表、图文混排、正当的 UI 划分还有资源按需加载基本上每个我的项目都要做一遍，尤其是滑动列表只有 Item 数量超过 50 个必卡无疑，导致每个我的项目每家公司都要本人做一遍，然而 UIToolkit 官网就内置了循环列表的性能。UGUI 为什么效率低呢？就拿滑动列表来说吧，超出显示区域以外的面也须要合并 Mesh，VBO 数据也须要给 GPU 传，这样元素多提交 GPU 的数据量就大，还有就是它基于 GameObject 的形式，导致必然须要加载大量没用的数据，参加序列化的脚本数据有用没用都须要加载，导致简直没有任何缓存命中率可言。
GameObject 的形式以致 UI 效率低，Unity 开发的 DOTS 就是为了解决 GameObject 的问题，对 DOTS 感兴趣的敌人欢送看我之前的课程《DOTS 深度钻研之原理剖析篇》和《DOTS 深度钻研之利用实际篇》。UGUI 还有那几个 LayoutGroup、ContentSizefitter 组件元素只有多一点就容易卡顿。UIToolkit 继承了 UGUI 做得好的中央，比方 Mesh 合并就被保留下来，而且内置的 ListView 和 ScrollView 自带了有限循环列表的性能，并不会将所有看不见的元素都进行合并与提交 GPU。它并没有采纳 GameObject 的形式，参考了 Web 技术的 XML 和 CSS 计划，只保留变动的数据。
期初在 UGUI 诞生前甚至在 NGUI 诞生前 Unity 本人是有一套 UI 零碎的，称之为 IMGUI。它的运行原理更恐怖，每帧无论 UI 是否变动都须要将 VB/IB 传入 GPU 中，每个 UI 元素都要每帧设置渲染状态，DrawCall 无疑就会十分恐怖。它在编辑模式下和运行时都同时反对，因为编辑模式下对性能并没有要求，而且编辑面板也不会制作特地简单的性能，所以 IMGUI 被广泛应用于拓展编辑器的开发。而运行时的 OnGUI 简直没有我的项目应用，因为应用不便当（没有编辑器），效率低（DrawCall 高）的起因，所以起初在 AssetStore 中诞生了 NGUI 这样的第三方 UI 零碎。随后在 Unity 4.6 中 Unity 官网也开发出 UGUI。UIToolkit 的诞生是有时代意义的，同时兼顾了编辑模式与运行模式的布局便利性与性能，保障同一套代码资源能够疾速移植。UIToolkit 目前处于高速倒退中，论坛中开发者探讨的十分强烈，版本迭代的速度也十分快，通过 UIToolkit 被内置在引擎中足以见得官网对 UIToolkit 的应用信心。
很多敌人看到 XML 和 CSS 就联想到 UIToolkit 应用了上世纪 90 年代的老技术，还和 WPF 和 WinForm 作比拟。就我看来 XML 和 CSS 只是界面的形容信息，就算是 UGUI 用的也是 YAML 来保留的界面形容信息，真正外围的技术应该是如何渲染与优化才对，如下图所示，UIToolkit 中不同图集、不同文字、图文混排和不同深度只须要 1 次 DrawCall 就能够画完。
UIToolkit 在 GPU 保留了一份以后 UI 渲染的 VB/IB，当渲染的 UI 发生变化时它会以最小的代价来更新这份 VB/IB，它不会更新全副的 VB/IB，只更新变动的局部保障 CPU 和 GPU 每帧都能高度运行。为了一次 DrawCall 能画完，它还实现了一套大而全的 Ubershader，同时反对 8 个图集和 1 个字体，只有界面满足以上条件就能够一次 DrawCall 画完，如果对 UI 原理感兴趣的敌人在文章的前面有具体的介绍。
而且 UIToolkit 应用的 UXML 只记录了变动的数据，比方大部分图片在 UI 中可能永远都不会设置色彩、旋转或缩放。UIToolkit 提供了默认参数，只有不批改它，UXML 中就不会蕴含额定数据。反观 UGUI 它无论如何都须要把色彩、旋转和缩放一类的数据序列化在脚本中，一个简单的界面可能有 500 多个元素，然而大量的内存都被白白浪费了，毫无缓存命中率可言，从这一点来看 UIToolkit 也要比 UGUI 先进。
1.1 致敬
首先来致敬一下 UIToolkit 的两位次要开发者 Benoit Dupuis（贝努瓦·杜普伊）和 Damian Campeanu（达米安·坎皮努）。感激在我学习的过程中在 unite 和官方论坛中屡次看到他们精彩的分享与急躁的解答。
贝努瓦·杜普伊（左）达米安·坎皮努（右）（图片来自领英）
贝努瓦·杜普伊在论坛中屡次公布 UIToolkit 的最新技术栈，以及 UIToolkit 将来的打算 Roadmap 解答开发者的疑难。达米安·坎皮努是 UIToolkit 的次要开发者，而且他还是 DOTS 编辑器团队的老大。
UIToolkit 官方论坛：https://forum.unity.com/threads/ui-update-q3-2021.1138603/
1.2 下一代 UI 零碎
Unity 在 2018 年公布 UIElement 时我就简略看过，因为过后它只反对 Editor 面板的 UI，所以我就没有持续深刻学习。Unity 在 2019 年 UIElement 改名 UIToolkit 并且反对运行时 UI 时我又简略学了一遍，发现它就是基于 XML 和 CSS 的 20 年前的老技术，期初心田是有点抵制的，直到 Unity 2021.2 正式内置 UIToolkit 到引擎中，又一次勾起了我学习它的激情。时至今日它仍然有很多问题是无奈解决的，如：UI 和粒子特效叠层、UI 和 3D 模型叠层、UI 裁剪粒子特效、3D 界面、多 UI 相机叠层、UI 非凡着色器和 K 帧动画等等。
毕竟 UGUI 曾经好几年都没更新了，一个好引擎必然要跟上时代，替用户解决通用的痛点问题。在我看了 UIToolkit 最新的 Roadmap 当前我更加深信 UIToolkit 会代替 UGUI。目前无奈满足需要的中央官网正在踊跃的开发，UIToolkit 曾经反对 UGUI 混合应用、反对 Text mesh pro 图文混排和有限滑动列表。将来会反对 Shader Graph、3D 粒子与 UI 的叠层和深度问题。大家如果有需要也能够在这个链接中公布本人的想法，这里也能看到官网正在反对以及将来反对的性能。
https://unity.com/roadmap/unity-platform/gameplay-ui-design
1.3 装置 UIToolkit
最好应用 Unity 2021.2 以及以前的版本，此版本中 UIToolkit 曾经内置在引擎中不须要增加额定的 Package 包。毛病就是不利于查看 C# 源码，它将 DLL 内置在引擎中。如果对源码有趣味的敌人也能够应用 Unity 2020.3 以及以上版本，但须要手动装置 Package 包。目前有个别性能只有在 Unity 2021.2 中才有，所以本教程我采纳最新 Unity 2021.2.9f1 版本，在源码学习局部我会切到 Unity 2020.3 版本。
如果是 Unity 2020 版本，如下图所示，须要在 PackageManager 中增加，com.unity.ui 和 com.unity.ui.builder 两个包，目前两个包的最新版本都是 1.0.0-preview.18 版本。
“com.unity.ui”: “1.0.0-preview.18”,
“com.unity.ui.builder”: “1.0.0-preview.18”,
com.unity.ui 包就是 UIToolkit，com.unity.ui.builder 包则是 UIBuilder，UIBuilder 是 UXML 和 USS 的可视化编辑器，让使用者不须要手写布局代码，在编辑器中能够不便做出各式各样的界面。
戳此《UIToolkit 下一代 UI 零碎》查看全文。