无意间发现了一个小技巧。如下图所示，可以发现UGUI的Image组件的RaycastTarget勾选以后会消耗一些效率，为了节省效率就不要勾选它了，不仅Image组件Text组件也有这样的问题。
一般UI里也就是按钮才需要接收响应事件，那么大部分image和text是是不需要开RaycastTarget的。

但是问题就来了，Unity默认在hierarchy窗口Create-UI-Image 、Text的时候就会自动帮我们勾选上RaycastTarget，
一个复杂点的界面至少也300+个Image和Text， 总不能一个个取消吧。 所以我们可以重写Create-UI-Image的事件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

[MenuItem("GameObject/UI/Image")]



 static void CreatImage()



 {



 if(Selection.activeTransform)



 {



 if(Selection.activeTransform.GetComponentInParent<Canvas())



 {



 GameObject go = new GameObject("image",typeof(Image));



 go.GetComponent<Image().raycastTarget = false;



 go.transform.SetParent(Selection.activeTransform);



 }



 }



 }

这样创建出来的Image就不带 RaycastTarget,Text组件原理同上。 Unity版本5.3.3

作者：雨松MOMO

优化UI有时候并没有什么很简洁的方式。本文介绍了一些可能对UI性能提升有帮助的建议，有些建议是针对结构上“不清晰”，或难于维护，或者效果很差。另一些则可能对开发初期的UI用户界面简化有所帮助，但也相对更容易产生一些性能问题。

基于RectTransform的布局

Layout组件的性能开销相当大，因为每次当它们被标记为Dirty时，都必须重新计算所有子节点的坐标和尺寸。如果在给定的Layout内有一些相对较小的固定数量的元素，并且布局的结构也相对简单，那么就有可能将Layout替换为基于矩形变换的布局
（RectTransform-based layout）。

通过设置RectTransform的锚点（Anchors），RectTransform的坐标和大小会根据父节点进行缩放。例如，一个简单的两列布局可以用两个RectTransform实现:

左列的锚点应该是X: (0, 0.5) 以及 Y: (0, 1)

右列的锚点应该是X: (0.5, 1) 以及 Y: (0, 1)

对于RectTransform坐标和大小的计算会由Transform系统自身的源代码进行驱动。通常情况下这比Luyout系统更高效。也可以通过MonoBehaviours来实现基于RectTransform的Layout。然而，这是一个相对复杂的任务，不在本文中描述。

禁用Canvas渲染器

当显示或者隐藏UI的某个部分时，通常是激活（Enable）或者禁用（Disable）UI根节点的GameObject。这会导致被禁用UI下的所有组件都将不再接收输入或者Unity回调。

然而，这也会导致Canvas丢弃它的VBO（Vertex Buffer
Objects，顶点缓存对象）数据。重新激活Canvas需要Canvas（以及它的子Canvas）执行重新构建（Rebuild）
以及重新批处理（Rebatch）操作。如果这种情况非常频繁，那么CPU使用率的增加就会导致应用程序帧率的卡顿。

一个可行但有风险的解决方案是让将那些需要切换显示或隐藏的UI放在单独的Canvas或子Canvas中，然后仅仅激活/禁用附加在Canvas上的Canvas渲染组件（Canvas
Renderer）。

这会导致UI的网格不被绘制，但它们会一直存在于内存中，并且原始的批处理信息（Batching）也会被保留。此外，UI层级结构（Hierarchy）下的OnEnable
或者 OnDisable回调将不会执行。

注意，这并不会将UI图形从图形记录（GraphicRegistry）中消除，所以它们依然会出现在组件列表中，可以被光线投射（Raycast）检测到。隐藏UI也不会禁用任何的MonoBehaviour，所以那些MonoBehaviour依然会接受Unity生命周期相关的回调，比如Update函数。

隐藏UI的MonoBehaviour脚本不直接实现那些Unity生命周期相关的回调函数，而是从UI根节点上的“回调管理器”MonoBehaviour中接收回调，可以避免出现这样的问题。这个“回调管理器”无论UI是否显示都可以访问，并且保证了生命周期事件按需发送。

分配事件相机

如果使用了Unity内置的输入管理器，并将Canvas的渲染模式设为世界空间（World Space）或者屏幕空间相机（Screen Space –
Camera）渲染，有一点很重要，就是分别设置Event Camera和Render
Camera的属性。这可以在脚本中访问Canvas的worldCamera属性进行设置。

如果没有设置worldCamera属性，那么Unity UI会查找标签为Main
Camera的GameObject上附加的Camera脚本来搜索主相机。这个查询会在世界空间（World Space）和相机空间（Camera
Space）的Canvas中都至少分别执行一次。由于GameObject.FindWithTag非常缓慢，Unity强烈建议大家在设计或初始化所有的世界空间（World
Space）和相机空间（Camera Space）的Canvas时，就分配好各自的相机属性。

这个问题不会在渲染模式为Overlay的Canvas中出现。

资源分离打包与加载

游戏中会有很多地方使用同一份资源。比如，有些界面共用同一份字体、同一张图集，有些场景共用同一张贴图，有些怪物使用同一个Animator，等等。在制作游戏安装包时将这些公用资源从其它资源中分离出来，单独打包。比如若资源A和B都引用了资源C，则将C分离出来单独打一个bundle。在游戏运行时，如果要加载A，则先加载C；之后如果要加载B，因为C的实例已经在内存，所以只要直接加载B，让B指向C即可。如果打包时不将C从A和B分离出来，那么A的包里会有一份C，B的包里也会有一份C，冗余的C会将安装包撑大；并且在运行时，如果A和B都加载进内存，内存里就会有两个C实例，增大了内存占用。

资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般打包粒度越细，这两个指标就越小；而且当两个renderQueue相邻的DrawCall使用了相同的贴图、材质和shader实例时，这两个DrawCall就可以合并。但打包也并不是越细就越好。如果运行时要同时加载大量小bundle，那么加载速度将会非常慢——时间都浪费在协程之间的调度和多批次的小I/O上了；而且DrawCall合并不见得会提高性能，有时反而会降低性能，后文会提到。因此需要有策略地控制打包粒度。一般只字体和贴图这种体积较大的公用资源。

　　可以用AssetDatabase.GetDependencies得知一份资源使用了哪些其它资源。

2 贴图透明通道分离，压缩格式设为ETC/PVRTC

最初我们使用了DXT5作为贴图压缩格式，希望能减小贴图的内存占用，但很快发现移动平台的显卡是不支持的。因此对于一张1024x1024大小的RGBA32贴图，虽然DXT5可将它从4MB压缩到1MB，但系统将它送进显卡之前，会先用CPU在内存里将它解压成4MB的RGBA32格式（软件解压），然后再将这4MB送进显存。于是在这段时间里，这张贴图就占用了5MB内存和4MB显存；而移动平台往往没有独立显存，需要从内存里抠一块作为显存，于是原以为只占1MB内存的贴图实际却占了9MB！

所有不支持硬件解压的压缩格式都有这个问题。经过一番调研，我们发现安卓上硬件支持最广泛的格式是ETC，苹果上则是PVRTC。但这两种格式都是不带透明（Alpha）通道的。因此我们将每张原始贴图的透明通道都分离了出来，写进另一张贴图的红色通道里。这两张贴图都采用ETC/PVRTC压缩。渲染的时候，将两张贴图都送进显存。同时我们修改了NGUI的shader，在渲染时将第二张贴图的红色通道写到第一张贴图的透明通道里，恢复原来的颜色：

fixed4 frag (v2f i) : COLOR

fixed4 col;

col.rgb = tex2D(_MainTex, i.texcoord).rgb;

col.a = tex2D(_AlphaTex, i.texcoord).r;

return col * i.color;

fixed4 frag (v2f i) : COLOR

{

fixed4 col;

col.rgb = tex2D(_MainTex, i.texcoord).rgb;

col.a = tex2D(_AlphaTex, i.texcoord).r;

return col * i.color;

}

这样，一张4MB的1024x1024大小的RGBA32原始贴图，会被分离并压缩成两张0.5MB的ETC/PVRTC贴图（我们用的是ETC/PVRTC 4
bits）。它们渲染时的内存占用则是2x0.5+2x0.5=2MB。

3 关闭贴图的读写选项

Unity中导入的每张贴图都有一个启用可读可写（Read/Write
Enabled）的开关，对应的程序参数是[TextureImporter.isReadable](http://docs.unity3d.com/ScriptReference
/TextureImporter-isReadable.html)。选中贴图后可在Import
Setting选项卡中看到这个开关。只有打开这个开关，才可以对贴图使用Texture2D.GetPixel，读取或改写贴图资源的像素，但这就需要系统在内存里保留一份贴图的拷贝，以供CPU访问。一般游戏运行时不会有这样的需求，因此我们对所有贴图都关闭了这个开关，只在编辑中做贴图导入后处理（比如对原始贴图分离透明通道）时打开它。这样，上文提到的1024x1024大小的贴图，其运行时的2MB内存占用又可以少一半，减小到1MB。

4 减少场景中的GameObject数量

　　有一次我们将场景中的GameObject数量减少了近2万个，游戏在iPhone
3S上的内存占用立马减了20MB。这些GameObject虽然基本是在隐藏状态（activeInHierarchy为false），但仍然会占用不少内存。这些GameObject身上还挂载了不少脚本，每个GameObject中的每个脚本都要实例化，又是一比不菲的内存占用。因此后来我们规定场景中的GameObject数量不得超过1万，并且将GameObject数量列为每周版本的性能监测指标。

5 图集

整理图集的主要目的是节省运行时内存（虽然有时也能起到合并DrawCall的作用）。从这个角度讲，显示一个界面时送进显存的图集尺寸之和是越小越好。一般有如下方法可以帮助我们做到这点：

1）在界面设计上，尽量让美术将控件设计为可以做九宫格拉伸，即UISprite的类型为Sliced。这样美术就可以只切出一张小图，我们在Unity中将它拉大。当然，一个控件做九宫格也就意味着其顶点数量从4个增加到至少16个（九宫格的中心格子采用Tiled做平铺类型的话，顶点数会更多），构建DrawCall的开销会更大（见第6点），但一般只要DrawCall安排合理（同样见第6点）就不会有问题。

2）同样是在界面设计上，尽量让美术将图案设计成对称的形式。这样切图的时候，美术就可以只切一部分，我们在Unity中将完整的图案拼出来。比如对一个圆形图案，美术可以只切出四分之一；对一张脸，美术可以只切出一半。不过，与第1）点类似，这个方法同样有其它性能代价——一个图案所对应的顶点数和GameObject数量都增多了。第4点已经提到，GameObject数量的增多有时也会显著占用更多内存。因此一般只对尺寸较大的图案采用这个方法。

3）确保不要让不必要的贴图素材驻留内存，更不要在渲染时将无关的贴图素材送进显存。为此需要将图集按照界面分开，一般一张图集只放一个界面的素材，一个界面中的UISprite也不要使用别的界面的图集。假设界面A和界面B上都有一个小小的一模一样的金币图标，不要因为在制作时贪图方便，就让界面A的UISprite直接引用界面B中的金币素材；否则界面A显示的时候，会将整个界面B的图集也送进显存，而且只要A还在内存中，B的图集也会驻留内存。对于这种情况，应该在A和B的图集中各放一个一模一样的金币图标，A中的UISprite只使用A的图集，B中的UISprite只使用B的图集。

不过，如果两个界面之间存在大量相同的素材，那么这两个界面就可以共用同一张图集。这样可以减少所有界面的总内存占用量。具体操作时需要根据美术的设计进行权衡。一般界面之间相同的通用的素材越多，程序的内存负担就越小。但界面之间相同的东西太多的话，美术效果可能就不生动，这是美术和程序之间又一个需要寻求平衡的地方。

　　另外，数量庞大的图标资源（如物品图标）不要做在图集里，而应该采用UITexture。

4）减少图集中的空白地方。图集中完全透明的像素和不透名的像素所占的内存空间其实是一样的。因此在素材量不变的情况下，要尽量减少图集中的空白。有时一张1024x1024的图集中，素材所占的面积还没超过一半，这时可以考虑将这张图集切成两张512x512的图集。（有人会问为什么不能做成一张1024x512的图集，这是因为iOS平台似乎要求送进显存的贴图一定是方形。）当然，两张不同图集的DrawCall是无法合并的，但这并不是什么问题（见第6点）。

　　应该说，图集的整理在具体操作时并没有一成不变的标准，很多时候需要权衡利弊来最终决定如何整理，因为不管哪种措施都会有别的性能代价。

8 降低贴图素材分辨率

这一招说白了其实就是减小贴图素材的尺寸。比如对一张在原画里尺寸是100x80的，我们将它导入Unity后会把它缩小到50x40，即缩小两倍。游戏实际使用的是缩小后的贴图。不过这一招是必然会显著降低美术品质的，美术立马会发现画面变得更模糊，因此一般不到程序撑不住的时候不会采用。

9 界面的延迟加载和定时卸载策略

如果一些界面的重要性较低，并且不常被使用，可以等到界面需要打开显示的时候才从bundle加载资源，并且在关闭时将卸载出内存，或者等过一段时间再卸载。不过这个方法有两个代价：一是会影响体验，玩家要求打开界面时，界面的显示会有延迟；二是更容易出bug，上层写逻辑时要考虑异步情况，当程序员要访问一个界面时，这个界面未必会在内存里。因此目前为止我们仍未实施该方案。目前只是进入一个新场景时，卸载上一个场景用到但新场景不会用到的界面。

以上的9个方法中，4、5、6需要在一定程度上从策划和美术的角度考虑问题，并且需要持续保持监控以维护优化状态（因为在设计上总是会有新界面的需求或改动老界面的需求）；其它都是一劳永逸的解决方案，只要实施稳定后，就不需要再在上面花费精力。不过2和8都是会降低美术品质的方法，尤其是8。如果美术对品质的降低程度实在忍不了的话，也可能不会允许采用这两个方法。

10避免频繁调用GameObject.SetActive

我们游戏的某些逻辑会在一帧内频繁调用GameObject.SetActive，显示或隐藏一些对象，数量达到一百多次之多。这类操作的CPU开销很大（尤其是NGUI的UIWidget在激活的时候会做很多初始化工作），而且会触发大量GC。后来我们改变了显示和隐藏对象的方法——让对象一直保持激活状态（activeInHierarchy为true），而原来的SetActive(false)改为将对象移到屏幕外，SetActive(true)改为将对象移回屏幕内。这样性能就好多了。