[转载]浅谈UGUI优化-DrawCall篇

转载于 2024-10-31 14:16:28 发布 · 196 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：https://dmstory.github.io/post/ugui-optimize-drawcall/

文章标签：

#unity

原作者：董大喵

许可协议：CC BY-NC 4.0

说起UGUI的优化，DrawCall一定是一个绕不开的话题。当然不只是UI优化，Unity中性能优化都会涉及DrawCall的优化。

什么是DrawCall

Unity要渲染一帧画面，需要经过两个阶段，CPU阶段和GPU阶段：CPU阶段Unity把渲染需要的数据准备好，GPU阶段通过渲染管线，利用这些数据渲染出画面。CPU把数据传递给GPU，通知GPU进行渲染的过程，就叫做DrawCall。

为什么要优化DrawCall

DrawCall的过程涉及CPU和GPU的交互，耗时比较高，一个未经优化的场景可能DrawCall动辄几百上千，严重影响CPU效率。可以用一个现实中绘画的例子进行类比：画画的时候可能是这样的，先拿起一种颜色的笔，画一部分，再换另一种颜色，画一部分。换笔的过程就相当于DrawCall的过程，而实际的作画相当于GPU在渲染，假设我画的速度非常快，远超过换笔的时间，那么过多的换笔次数就会成为我绘画的性能瓶颈。

如何优化DrawCall

注意

由于UGUI是以Canvas为单位进行渲染，不同Canvas即使顺序相邻且图集相同也不会合并，本文讨论的内容均是在同一个Canvas且没有子Canvas的情况下。

仍然用绘画作为类比，既然换笔的速度相对实际绘画来说要慢很多，那就减少换笔的次数，用一种颜色的画笔时，把整幅画需要用这个颜色的地方都画出来，然后再换笔，就可以用最少的换笔次数完成绘画。在Unity的渲染过程中也是类似的，如果我们能把使用相同渲染数据（主要是指材质）的网格用同一个DrawCall发送给GPU，就能够最大程度减少DrawCall，这就是所谓的合并（Batch）。

当然，以上只是比较理想的过程，在渲染不透明物体的时候不会有什么问题，但是在渲染半透明物体的时候（UGUI中都是当作半透明物体来处理）由于半透明渲染必须啊严格按照从后往前的顺序，很多时候并不能进行合并。

在下面的示例中，用不同的颜色代表不同的图集1，不同的图集在UGUI中则代表不同的材质。当只有两张图且图集不同时，DrawCall是2，这没什么好说的。当有四张图但是只包含两个图集，但是它们是穿插的关系时，由于不透明渲染只能严格按照从后往前的顺序，并不能将同图集的1、3合并，2、4合并，所以最终是4个DrawCall。当有四张图只包含两个图集，且同图集相邻的情况下，可以合并，此时是2个DrawCall。

示例	DrawCall数2
	2
	4
	2

有一种特殊情况，不同图集的图在Hierarchy中出现穿插，由于Hirearchy中的顺序代表着渲染顺序(同一Canvas下)，我们认为不会合并DrawCall，但是如果他们在位置上并不重叠，UGUI仍然将DrawCall合并，这样算是一种优化吧。

示例	DrawCall数
	4
	2

然而这只能算是一种福利，实际项目中要依赖这种优化比较难且危险，因为很多情况下很难直观地看出重叠关系，示例中使用的是完全不透明的资源，但是实际项目中经常出现元素的半透明区域，这些重叠只有刻意在Scene视图下查看才比较容易看出来，一不留神就会出现无法合并的情况。

建议

拆分Canvas，同一Canvas下用尽量少的图集，图集越多越容易出现穿插的情况，导致Batch失败。
尽量避免图集中出现多张图的情况，否则DrawCall难以预测。
条件允许的情况下可以通过手动调整Hierarchy中元素顺序的方式一定程度降低DrawCall。
一些重复出现的小组件，比如背包中的道具，尽量保证使用的资源都在同一个图集，如果无法保证，尽量避免这些道具出现重叠，利用UGUI优化机制降低DrawCall。
Scale为0或者Alpha为0可以避免DrawCall，但是移除屏幕外不会╮(╯▽╰)╭

Unity的图集在内容超出最大贴图尺寸、不同内容使用不同参数的情况下可能会出现分成不同贴图的情况，这种情况其实对于渲染来说已经是不同的材质了，所以我们这里讨论的同图集指的是底层意义上的同图集，即使用的是相同的贴图，而非概念上的同一个图集。 ↩︎
这里的DrawCall仅表示这部分内容所占用的开销，实际在Unity工程中由于有摄像机的存在(比如Canvas使用的RenderMode使用的Camera模式)显示数量会多一些。

↩︎