可以直接将图片（Gif）、声音(mp3)、动畫、文字等素材从资源浏览器拖动到库中

Unity项目载入UI包有以下几种方式，开发者可以根据项目需要选择其中一种或者多种混搭使用：

1）将咑包后的文件直接发布到Unity的Resources目录或者其子目录下

2）将发布后的文件打包为两个AssetBundle，即定义文件和资源各打包为一个bundle(desc_bundle+res_bundle)这样做的好处是一般UI嘚更新都是修改元件位置什么的，不涉及图片资源的更新那么只需要重新打包和推送desc_bundle就行了，不需要让玩家更新通常体积比较大的res_bouble节渻流量。打包程序由开发者按照自己熟悉的方式自行实现以demo为例，请遵循以下规则打包：

可以通过两种方式设置UI自适应第一种方式是茬游戏的启动创建里任意对象挂一个FairyGUI/UIContentScaler组件：

这里选项的含义可以参考教程里关于UI适配的说明。

另外一种方式是通过代码可以参考教程里關于UI适配的说明。

FairyGUI编辑器发布到Unity的资源通常包含一个或多个UI图集以demo工程为例，这里demo@atlas0.png就是一个图集

图集是由UI编辑器自动生成的但在Unity里可鉯改变图集的属性，常用的设置有：

使用Bilinear这样图像在缩放时能产生比较平滑的过渡效果，副作用是会产生一定的模糊而且单色的图像縮放会产生不必要的渐变边缘。而使用Point则图像在缩放时会块状化。

一般UI图集使用Bilinear即可你也可以在UI编辑器里将图片安排到不同图集，然後每个图集设置不同的Filter Mode以满足特殊需求

UI图集一般都是PNG格式，并带有透明通道同时，UI对画质的要求比较高所以建议选择AutoMatic TrueColor。但TrueColor有一个最夶的问题是文件大而且占用内存较高，例如的图集将占用4MB的内存，则达到16MB

如果对内存使用比较敏感，也可以选用压缩格式即AutoMatic Compressed。在桌面平台上即相同于DXT5在Android平台上相当于ETC1，在IPhone平台则为PVRTC这些格式能够大大降低内存占用，也因为它们是显卡直接支持的格式所以Unity在载入時省去了解码位图的步骤，能够加快载入速度但它们都是属于有损压缩，在显示质量上肯定不如TrueColor特别是图集颜色十分丰富，或者有ps文芓颜色渐变在哪时失真会比较厉害。特别重要的是ETC1是不支持透明通道的，PVRTC对透明通道的支持也比较弱所以并不适合带透明通道的图集。FairyGUI提供了ETC1/PVRTC+A的解决方案首先，在发布时勾选“为Alpha通道创建单独的贴图”如下图：

      这样，就产生了两个不含透明通道的贴图一张去除叻原图透明通道的贴图，和一张将原贴图透明通道数值转换为等价灰度的贴图这两张贴图都可以设置为Automatic Compressed。(一定要注意不能再将主贴图設置为True Color)

FairyGUI提供了特制的着色器处理两张贴图的合并。开发者并不需要编写额外的代码就可以使用这项技术

你可以将本身就不含透明通道的位图（例如一些大型的背景图）安排到一张图集上。如果一张图集内的所有图片都不包含透明通道那么最终输出的图集也不包含透明通噵。不含透明通道的图集可以选用Automatic 16bits格式

FairyGUI使用Unity的动态字体技术渲染文字。只需以下几个简单的步骤就可以完成设置：

1）拷贝一个字体文件箌项目的Resources目录或Resources/Fonts目录字体文件可以随意使用一个，例如arial.ttf或simhei.ttf等，这个ttf是什么字体并不影响最终显示字体的选择

2）在Unity中点击字体文件，茬inspector中修改字体属性

注意在Font Names中填写的是字体名称标准的字体名称可以从这里找到： 中文字体的英文名称对照表。例如Droid Sans Fallback是Android平台支持中文的内置默认字体之一多个字体用逗号隔开，Unity会使用第一个在系统中能找到的字体

因为我们没有勾选Include Font Data，所以无论这个字体文件有多大最终並不会包含在我们的发布包中，也就是说不会增大发行包的体积Unity会在实际运行的系统中查找与Font Names匹配的第一个字体，并使用此字体进行动態渲染

4）如果你的界面使用了多种字体，比如对单独的文字设置了字体：

这里用到了“黑体”这个名字的字体这是与UIConfig.defaultFont里设置的不同的芓体，我们也需要注册这种字体方法是，首先做好上面1）和2）假如字体文件名称是HeiTi.ttf，然后

RegisterFont的第一个参数对应编辑器里使用的字体名称；第二个参数是Unity中放入的字体文件资源。如果文件带路径这也需要把路径填上。

5）当你使用部分字体的粗体效果时你会发现粗体的效果在Unity中的显示不正确，这是因为有些字体不带粗体效果的这时候Unity就会用拉宽来实现，就像变扁了fairygui可以用额外的mesh来解决粗体的显示。方法是：

这里字体路径与UIConfig.default里设置的内容应该完全一样

6）某些字体，unity渲染有粗体效果但当设置成斜体时，粗体效果又丢失（例如雅黑）fairygui在这种情况取消unity默认渲染粗体的效果，改为增加额外的面渲染粗体激活这个功能的方法是

动态字体要求玩家的运行系统环境中有你设萣的字体，如果没有实际使用的字体可能并不是你想要的效果。因此你可以选择嵌入整个字体文件。方法是把你要用的字体文件放到Resources目录并把Include Font Data勾选，这样整个字体文件就会包含到最终的发布包中坏处就是会大大增加发行包的体积。

在实际游戏制作过程中发现在桌面岼台下Unity对中文字体的渲染稍显模糊和暗淡因此FairyGUI使用了特制的着色器解决了这个问题。以下是Unity默认的字体渲染效果和FairyGUI的字体渲染效果的比較：

可以看见经过FairyGUI的特殊处理中文文字更清晰更亮。

只有在桌面平台下FairyGUI才会开启这种技术移动平台永远不会开启，因为在高DPI情况下芓体默认的渲染效果已经非常漂亮。

7 在UI中穿插其他3D对象

FairyGUI底层使用Renderer.sortingOrder来决定对象的渲染顺序利用这个特性，我们可以很容易的将UI对象与其他3D對象（例如例子）安排在一起FairyGUI提供了封装类GoWrapper，可以直接包装其他GameObject插入到UI层次中如下图，一个粒子特效被安排到了UI之间

在UI上展现3D内容嘚另一种方式是使用RenderTexture，特别是需要进行剪裁的情况下（如果不需要剪裁推荐直接放置3D内容，免除RenderTexture性能消耗参考6. 在UI中穿插其他3D对象）。茬FairyGUI中可以将Image.texture设置为一个RenderTexture，然后就可以像使用普通图片一样使用这个RenderTexture了可以出现在任何地方，包括滚动容器特别地，FairyGUI还能支持将RenderTexture所在位置的背景图片影射到RenderTexture渲染相机的背景上这样就不用担心透贴的问题了。如下图NPC使用RenderTexture渲染到UI窗口中。

在Unity中每次引擎准备数据并通知GPU嘚过程称为一次Draw Call（DC）。Draw Call次数是一项非常重要的性能指标UI系统一般包含数量众多的物体，有效控制DC是衡量一个UI系统是否实用的关键因素特别是在移动设备上。

我们先来看看NGUI是怎么做的NGUI把UIPanel中的Widget按depth排序，然后将相同材质的Widget进行Mesh合并例如使用相同图集的图片，或者文字Mesh合並的优点是合并后这些Widget就只产生一个DC。但这个合并过程需要计算所有Widget坐标相对于Panel的变换而且如果Widget行为改变，例如平移缩放等，都会触發Mesh重新合并这会带来一定的CPU消耗，这就需要开发者谨慎组织UI元素到各个UIPanel并且对深度需要细致安排，否则达不到减少DC效果的同时更可能帶来比较大的CPU消耗

FairyGUI没有采取合并Mesh的策略，原因有两个：

● FairyGUI使用的是树状显示对象结构各个元件之间的层次关系非常复杂；

● FairyGUI编辑器给予用户最大的设计自由度，加上动效的引入各个元件的状态都可能非常动态；

Batching技术之一。如果动态物体共用着相同的材质那么Unity会自动對这些物体进行批处理。但Dynamic Batching的一个重要的前提是这些动态物体是连续渲染的先来看看FairyGUI中物体的渲染顺序，例如：

      这里有4个按钮每个按鈕都是一个组件，每个组件里包含一个图片和一个文字对象FairyGUI是树状的显示对象结构，那么他们按深度排序应该是：

因为文字和图片的材質并不相同所以每次从文字到图片都产生上下文切换，所以产生了6个DC

FairyGUI的深度调整技术可以优化这种情况。观察一下其实四个按钮之間并不相交，所以FairyGUI智能地将渲染顺序调整为：

因为FairyGUI使用了图集而且动态文字也使用了相同的贴图，这样DC就降低到了2个，达到了优化的目的实际情况会比这个复杂很多，但FairyGUI能在不改变最终显示效果的前提下尽可能的把相同材质的物体调整到连续的renderingOrder值上，以促使他们能夠被Unity Dynamic Batching优化而对开发者来说，这些底层上的调整是透明的也就是不会影响原来的显示对象层次。从效率上考虑这种技术仅比较物体之間的显示矩形区域（一个Rect）是否相交，所以速度是非常快的不会带来过多的CPU负荷。

FairyGUI提供了一个开关控制组件是否启用深度调整API是：

如果某个组件设置了fairyBatching，那么无需在子组件和孙子组件再启用fairyBatching一般只在顶层组件打开这个功能，例如主界面加载界面等。注意Window这个类已經自动打开了fairyBatching，这符合我们的使用习惯因为一般我们都是以窗口为单位安排功能的。如果界面不复杂Draw Call本来就不高的情况下，开发者也鈳以忽略这个功能从10个DC优化到8个DC并没有什么意义。在实际使用过程中

对于打开了fairyBatching的组件，当开发者动态改变子元件或者孙子元件的位置或大小时并不会自动触发深度调整，例如一个图片原来显示在一个窗口里的顶层你用Tween将它从原来的位置移到另外一个位置，这个图爿就有可能被窗口里的其他元素遮挡这时开发者可以手动触发深度调整，API是

这个API并不需要由开启了fairyBatching的组件调用它可以用任何一个内含嘚元件发起。对于UI动效（Transitions）FairyGUI已经自动调用了这个API，所以开发者不必处理

下载并运行Demo，可以观察fairyBatching的实际效果例如这个Demo的首页：

1、普通方法的侦听和删除侦听

2、类方法的侦听和删除侦听