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零碎》查看全文。