Recommended
Recommended
More Related Content
What's hot
What's hot (20)
UIToolkit下一代UI系统.pdf
- 2. 致敬 • 致敬一下UIToolkit的两位主要开发者Benoit Dupuis（贝努瓦·杜普伊）和 Damian Campeanu（达米 安·坎皮努） • 感谢在我学习的过程中在unite和官方论坛中多次看到他们精彩的分享与耐心的解答
- 3. 决心 • Unity目前在Editor中已经禁止提交IMGUI的代码，必须使用UIToolkit • UGUI已经2年多没更新了，未来UIToolkit一定会成为运行时和编辑时唯一的UI引擎 • 自Unity2021开始Uitoolkit以内置在引擎中和UGUI一样并非Pakage包的形式 • 我们来看看Unity的决心 首先，我们要重申我们的承诺，让 UI Toolkit 成为 Unity 产品中的唯一的UI 解决方案。这是一 个长期的愿望，但我们仍然坚信这个方向。
- 4. 官方DEMO
- 5. 官方DEMO
- 6. IMGUI • 每个UI元素都要单独设置一次渲染状态，导致DC非常恐怖 • 无论UI元素是否变化每帧都需要将VB/IB传入GPU中 • Unity原本的设计是Editor和Runtime都使用IMGUI • 由于IMGUI实在效率太低，所以AssetsStore中诞生了NGUI一类的插件 • 因为Editor对性能没有太多要求，并且Editor面板的UI比较简单 • 所以Editor下被广泛使用IMGUI 1.设置渲染状态 2.DrawCall 3.设置渲染状态 4.DrawCall 5.设置渲染状态 6.DrawCall UI多了DrawCall恐怖！！ 复杂界面毫无性能可言！ 渲染状态包括 VB/IB Shader 纹理 GPU内部状态 ….
- 7. NGUI • NGUI会提前合并Mesh并且合并图集 • 一次提交GPU，一次设置渲染状态，一次DrawCall • 图集可以离线合并，但Mesh顶点信息需要运行时合并 • 当UI元素发生变化时，就需要重新合并顶点数据 • 合并后的结果传入GPU中，统一进行渲染 • 可见合并的效率直接决定UI的运行效率 1.收集顶点信息 2.收集顶点信息 3.收集顶点信息 4.合并顶点信息 5.设置渲染状态 5.DrawCall
- 8. UGUI • NGUI毕竟是第三方UI库，显然真正瓶颈在合并Mesh顶点这块。 • UGUI是官方的UI库，所以它可以将耗时的这部分计算放在引擎中，提升效率 • 但UI界面真是太复杂了，每个元素变化都需要合并Mesh显然效率无法接受 • 常见的Layout、列表系列组件，需要等到这一帧最后才会统一刷新 • 原因就是避免列表每添加一个Item就整体合并一次Mesh产生的耗时 • 在算坐标的时候有时候都需要强制刷新contenSizeFitter • 强刷在列表中就会很卡，有经验的程序员一定都遇到过这个坑
- 9. UGUI • UGUI基于GameObject的方式几乎没有任何缓存命中率可言 • 大量的垃圾数据被反复序列化 • 比如添加一个UI界面，就显示一个Image
- 10. UGUI • 比如颜色、锚点、坐标等大量数据无论是否使用都需要序列化 • 整个界面就要接近序列化178个数据 • 这些都需要占用堆内存以及需要GC的 • 我们就今天的主角UIToolkit就要呼之欲出了
- 11. 脚本的通用问题 • Unity的脚本方式毫无缓存命中率可言，大量占用无用的堆内存 • 当加载一个GameObject时连带的组件有用无用都会加到内存/缓存中 • 组件中可能只用到了一个属性，但其他属性也会加载到内存中/缓存中
- 12. UITOOLKIT VS UGUI 的性能 • UGUI虽然Mesh合并在一起，但需要分别提交不同的纹理图集给GPU（一般游戏由很多图集组成） • UGUI图片和文字无法合并，最终的界面由于叠层的原因DC依然很多 • UIToolkit在GPU中分配了一块Buffer来保存VB/IB • 当界面变化时仅需将变化的VB/IB传入GPU中 • 界面元素会有增删改查的情况，还需要将内存偏移传入GPU中 • 最终每帧仅需要提交较少的内存偏移就可以还原出完整的界面了
- 13. 填充率 • UIToolkit支持Sprite的Tight模式，用更多顶点来换填充率 • 而且Sprite Atlas图集也支持Tight模式 • 使用更多顶点来优化填充率 • 目前UGUI也支持了Tight模式
- 14. 整个界面1次DC • UIToolkit最终提供了一个ubershader • 最多同时支持8张贴图（静态Sprite Atals图集）和1个 TextMeshpro文字图 • 图文混排一次DC • VB/IB、Shader、纹理、…都可一次提交
- 15. 动静分离 • UGUI中需要将变化频繁的和静太不动的UI设置成不同Canvas来减少额外合并mesh开销 • 如：运行时修改UI的坐标和缩放后需要重新合并Mesh在提交给GPU • 如果Canvas下UI很多，其中某个元素每帧都在修改位置，那么就反复需要合并Mesh了 • 同样的还有修改Image颜色、更换UI父子节点、增删改查等等 • UIToolkit则提供了属性可由使用者来设置，标记是否为动态UI • 标记后如果位置或者顶点色发生变化会直接在GPU内部修改(需硬件支持) • 这可比UGUI的性能高出N个数量级啊
- 19. XML和CSS布局 • 很多朋友看到XML和CSS就联想到UIToolkit使用了上世纪90年代的老技术 • 有些人还会拿UIToolkit还和WPF和WinForm作比较 • 就我看来XML和CSS只是界面的描述信息 • 就算是UGUI用的也是YAML来保存的界面描述信息 • 真正核心的技术应该是如何渲染与优化才对，并非使用了那种布局描述文件
- 21. UIBUILDER • UIToolkit提供了UIBuilder来代替手写XML布局文件 • 所见即所得的界面布局 • 内置了丰富的基础UI组件 • 针对Editor编辑UI也提供了额外的布局
- 22. 界面布局 • 将UI控件拖入Hierarchy中进行界面布局 • 可调整层次结构，父子节点的前后顺序 • VisualElement是基础容器，子对象在它之下进行布局 • 如:水平排列，垂直排列，四角对齐等操作
- 25. 动态图集 • UIToolkit可以将需要用的图运行时打在图集中 • 常见游戏中的icon技能图标，UGUI中打静态图集占大小，不打图集占Drawcall • 可以用动态图集来优化战斗界面，战斗技能图标。整个战斗UI合并成1个Drawcall 可指定动态图集的大小和参与动态图 集的小图的大小以及过滤的层 动态图集的大小是慢慢扩充的并非一 上来就4096
- 26. 循环滑动列表 • 内置循环滑动列表，减少当列表元素过多导致的卡顿 • UGUI没有提供循环列表组件，需要项目单独开发 • 添加ListView组件 • 在添加Item组件 • 代码中动态实例化
- 27. 循环滑动列表 • 添加1000条数据 • 参与GPU渲染的只有一屏以内的 • 现场演示一下Example6.unity 和代码
- 29. UGUI混合使用 • UIToolkit无法和使用Camera渲染的UI进行混合排序 • UIToolkit它的渲染是在最后的，和UGUI的Screen Space – Overlay相同 • Sort Order数值越小越先渲染，两者混合交叉使用
- 30. 目前的不足 • 不支持自定义材质和Shader • 不支持Camera模式，无法实现UI与3D或者粒子之间的叠层 • 不支持Mask模板裁剪，只支持矩形裁剪 • 不支持Timeline和Aniamtion中K帧动画 • 以上内容UIToolkit的roadmap中都有提到未来会陆续支持，大家耐心的等待吧。
- 31. 较UGUI的优势 • 支持运行时动态图集，UGUI只支持静态图集 • 支持UI抗锯齿，UGUI不支持 • 全局样式修改，UGUI如果没有用Prefab嵌套，需要单独修改每个界面中的UI元素 • 支持矢量图，在任何分辨率上都能保证高清晰度 • 支持圆角贴图，设置边框，半径和颜色，从而减少内存 • 类似CSS中的过度动画，UGUI则需要接入DoTween一类的插件 • 全新渲染引擎性能高
- 32. 推荐使用场景 • 大量人物头顶血条+名字 • 大量冒血数字图文混排 • 如：战斗界面优化，配合动态图集让战斗界面1个Drawcall画完 • 如：MMO、SLG游戏全屏的头顶文字图文混排1个Drawcall画完 • 如：打怪频繁跳动的冒血数字，低成本提交VB/IB方案，1个Drawcall画完