Unity UGUI优化：解决EventSystem耗时过长的问题 第二部分

前言：

上一部分说到，优化了一下GraphicRaycaster.get_eventCamera（）等方法的调用，使其有了明显的耗时下降。但实际上还是不够的：Graphic.get_canvasRenderer()、Graphic.get_depth()同样也有很大的耗时。通过观察发现，这部分的耗时都是在对gameObject进行判空导致的。

显然这个对于项目来讲不是很划算。因为其CanvasRender的获取方法也是获取组件身上挂载的CanvasRenderer，我们完全可以在初始化（Awake）的时候对其进行获取，并保证使用时期其不需要进行判空即可。

 

正文：

1、Graphic.canvasRender的获取方式的优化

与GraphicRaycaster.get_eventCamera（）不一样的是，Graphic.canvasRender不是一个可以重载的方法。所以对其的处理比较麻烦。

以可以相应点击事件的图片为例，我们自己写一个图片类继承自原UGUI的Image：

    /// <summary>
    /// 自写的Image；
    /// </summary>
    public class YHImage : Image 
    {

        protected override void Awake()
        {
            base.Awake();

            canvasRenderer = GetComponent<CanvasRenderer>();
        }

        public new CanvasRenderer canvasRenderer;

        public new int depth
        {
            get
            {
                return canvasRenderer.absoluteDepth;
            }
        }
    }

如图那样来获取canvasRenderer和depth。

注意，depth不用缓存起来，因为其在游戏进程中是变化的值。而且获取canvasRenderer.absoluteDepth的开销也很低。

之后再在 上一篇文章 提到的脚本中加上如下方法：

        /// <summary>
        /// 获取层级；
        /// </summary>
        /// <param name="gra"></param>
        /// <returns></returns>
        public static int GetGraphicDepth(Graphic graphic)
        {
            if (graphic is YHImage)
            {
                return  (graphic as YHImage).depth;
            }
            return graphic.depth;
        }

        /// <summary>
        /// 获取CanvasRenderer；
        /// </summary>
        /// <param name="gra"></param>
        /// <returns></returns>
        public static CanvasRenderer GetGraphicCanvasRenderer(Graphic graphic)
        {
            if (graphic is YHImage)
            {
                return (graphic as YHImage).canvasRenderer;
            }
            return graphic.canvasRenderer;
        }

然后将脚本中所有对Graphic获取depth和canvasRenderer的地方都替换成上述两个方法来获取。这样通过减少判空来进行了一部分优化。

 

2、减少depth的获取次数；

还有个很重要的一点就是，我们看到每帧获取depth的次数非常之多，而实际上界面上根本没有这么多UI元素。而且需要进行点击判定的元素也没有这么多，但depth却获取了很多次。在对代码的分析发现，源码中对Graphic的raycastTarget是在depth==-1之后的。而这一部分判定中，最消耗的是get_depth。而那些已经被勾选过为不需要raycastTarget的元素就没必要再进行各种判定了。

所以，我们对YHGraphicRaycaster中第二个RayCast函数进行修改：

        /// <summary>
        /// Perform a raycast into the screen and collect all graphics underneath it.
        /// </summary>
        private static void Raycast2(Canvas canvas, Camera eventCamera, Vector2 pointerPosition, IList<Graphic> foundGraphics, List<Graphic> results)
        {
            int totalCount = foundGraphics.Count;
            Graphic upGraphic = null;
            int upIndex = -1;
            for (int i = 0; i < totalCount; ++i)
            {
                Graphic graphic = foundGraphics[i];
                //不响应点击事件的就不要执行了；
                if (!graphic.raycastTarget) continue;
                //层级；
                int depth = GetGraphicDepth(graphic);
                if (depth == -1 ||  GetGraphicCanvasRenderer(graphic).cull)
                    continue;

                if (!RectTransformUtility.RectangleContainsScreenPoint(graphic.rectTransform, pointerPosition, eventCamera))
                    continue;

                if (eventCamera != null && eventCamera.WorldToScreenPoint(graphic.rectTransform.position).z > eventCamera.farClipPlane)
                    continue;

                if (graphic.Raycast(pointerPosition, eventCamera))
                {
                    if (depth > upIndex)
                    {
                        upIndex = depth;
                        upGraphic = graphic;
                    }
                }
            }
            if (upGraphic != null)
                results.Add(upGraphic);
        }

经过这一系列的修改，EventSystem.Update的优化就基本告一段落了，帖一张优化完成之后的Profile：

对比最初的8ms左右，优化后在2ms左右，效果还是非常明显。

 

3、减少点击响应组件的注册

通过前两步优化，效果好了很多，但是还有一个问题：为什么每帧会判定477次这么多？后来我发现，在传过来的列表中，居然还有未选中RaycastTarget的组件。也就是说，如果UGUI的原生Image，即便是你不勾选RaycastTarget，他其实也会在点击计算的列表中进行计算。虽然计算完成之后会把它剔除掉，但是他本身就不应该存在于这个列表中。剔除他们至少能减少循环次数。

于是我将界面中所有的Image和Text都替换成了自写的Image和Text（分别继承自UGUI原来的Image和Text），然后重写下面几个方法：

        #region 点击事件相应注册部分

        protected override void OnTransformParentChanged()
        {
            base.OnTransformParentChanged();
            if (!raycastTarget)
                GraphicRegistry.UnregisterGraphicForCanvas(canvas, this);
        }


        protected override void OnCanvasHierarchyChanged()
        {
            base.OnCanvasHierarchyChanged();
            if(!raycastTarget)
                GraphicRegistry.UnregisterGraphicForCanvas(canvas, this); 
        }

        protected override void OnEnable()
        {
            base.OnEnable();
            if (!raycastTarget)
                GraphicRegistry.UnregisterGraphicForCanvas(canvas, this);
        }

        #endregion；

这个就是在他注册之后进行二次判定，如果发现没有勾选RaycastTarget就将其取消点击事件判定的注册。虽然在上述三个函数被调用的时候麻烦一点，但是不会每帧进行判定了。

优化后效果如下：

可见最后队列中的元素大量减少， 总循环此时降低到了210次。耗时也能降低到2ms以下了。

 

4、更进一步？

在重写GraphicRaycaster.Raycast函数的时候，其实可以做一个判定：

     public override void Raycast(PointerEventData eventData, List<RaycastResult> resultAppendList)
        {
            if (eventData.dragging) return;
            //……
        }

也就是在进行拖动的过程中不再进行UI点击事件等的判定。从道理上来讲，如果正在拖动过程中，他怎么进行点击操作呢？所以此时是没必要进行判定了。

如果执行了这个判定，EventSystem的效能就会大幅上升，尤其是在拖动的时候。但是要注意的是，由于我们在拖动的时候屏蔽了点击事件的判定，所以在拖动过程中的时候变不会触发OnPointerIn/OnPointerOut这种鼠标移入移出的事件。所以在写代码的时候一定要注意，或者用其他的方法来进行同样功能的判定。

 

后记：

UGUI感觉坑还是很多啊，不过还好能找到公开的源码，改一改效果还是有的。

感觉Unity为了实现对整个框架的兼容，易用，损失了挺多性能方面的优化。当然也不排除就是一开始就没写好……总之这么一堆优化下来，效果还是不错。反正源码也阅读了，之后又什么Bug都比较好修复了。

 

PS：对EventSystem的优化第一部分在这里：https://blog.csdn.net/cyf649669121/article/details/83661023

第三部分在这里：https://blog.csdn.net/cyf649669121/article/details/86484168