Unity+NGUI性能优化方法总结
时间： 12:08:14
&&&& 阅读：2254
&&&& 评论：
&&&& 收藏：0
标签：1 资源分离打包与加载
　　游戏中会有很多地方使用同一份资源。比如，有些界面会共用同一份字体、同一张图集，有些场景会共用同一张贴图，有些会怪物使用同一个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作为贴图压缩格式，希望能减小贴图的内存占用，但很快发现移动平台的显卡是不支持硬件解压DXT5的。因此对于一张大小的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.rgb&=&tex2D(_MainTex,&i.texcoord).&&
&&&&col.a&=&tex2D(_AlphaTex,&i.texcoord).r;&&
&&&&return&col&*&i.&&
　　这样，一张4MB的大小的RGBA32原始贴图，会被分离并压缩成两张0.5MB的ETC/PVRTC贴图（我们用的是ETC/PVRTC 4 bits）。它们渲染时的内存占用则是2x0.5+2x0.5=2MB。
3 关闭贴图的读写选项
　　Unity中导入的每张贴图都有一个启用可读可写（Read/Write Enabled）的开关，对应的程序参数是。选中贴图后可在Import Setting选项卡中看到这个开关。只有打开这个开关，才可以对贴图使用Texture2D.GetPixel，读取或改写贴图资源的像素，但这就需要系统在内存里保留一份贴图的拷贝，以供CPU访问。一般游戏运行时不会有这样的需求，因此我们对所有贴图都关闭了这个开关，只在编辑中做贴图导入后处理（比如对原始贴图分离透明通道）时打开它。这样，上文提到的大小的贴图，其运行时的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）减少图集中的空白地方。图集中完全透明的像素和不透名的像素所占的内存空间其实是一样的。因此在素材量不变的情况下，要尽量减少图集中的空白。有时一张的图集中，素材所占的面积还没超过一半，这时可以考虑将这张图集切成两张512x512的图集。（可能有人会问为什么不能做成一张的图集，这是因为iOS平台似乎要求送进显存的贴图一定是方形。）当然，两张不同图集的DrawCall是无法合并的，但这并不是什么问题（见第6点）。
　　应该说，图集的整理在具体操作时并没有一成不变的标准，很多时候需要权衡利弊来最终决定如何整理，因为不管哪种措施都会有别的性能代价。
6&根据各个UI控件的设计安放Panel，隔开DrawCall
　　有一次我们发现NGUI的UIPanel.LateUpdate函数的CPU开销非常大。仔细研究之后，发现是合并了太多的DrawCall所致，尤其是将运行时会运动变化的UI控件和静止不变的UI控件的DrawCall合在了一起。当一个UI控件（UIWidget）的位置、大小或颜色等属性发生变化时，UIPanel就需要重建这个控件所用的DrawCall，某些情况下还要重建Panel上的所有DrawCall。有时重建一个DrawCall会消耗不少CPU开销，它需要重新计算这个DrawCall上所有控件的顶点信息，包括顶点位置、UV和颜色等。如果很多控件都集中在同一个DrawCall上，那么只要一个控件有一点点变化，这个DrawCall上的所有控件的顶点就都要重新遍历一边；而我们的UI又大量采用了九宫格拉伸，使控件的顶点数量变得更多，因此重建一个DrawCall的开销就更大。
　　因此我们将UI控件分组，将一段时间内会发生变化的控件&&比如怪物头顶的血条和伤害跳字放在同一个Panel上，并且这个Panel上只有这些控件，其余基本不变化的控件就放在别的Panel上。这样两类控件就被隔开到不同的DrawCall不同的Panel中，当一个控件发生变化而导致DrawCall重建时，就不需要遍历那些没有变化的控件。因为在美术设计上，一段时间内在变化的控件总是少数，所以优化效果十分明显，节省的CPU占用率能达到25%。
　　这种方法会增加一些DrawCall，但不会有什么影响。我们项目中前期曾经过于重视DrawCall数量的压缩，但后来发现增加几个DrawCall并不是那么可怕的事情。主程有一次甚至用Cocos2d-x做过试验，即使在500个DrawCall的情况下，动画依然可以跑得很流畅，相比之下贴图大小对流畅度的影响要大得多。
7 优化锚点内部逻辑，使其只在必要时更新
　　在上一点优化了Panel的DrawCall重建效率之后，我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下，控件的锚点也会每帧更新（见UIWidget.OnUpdate函数），而且它的更新是递归式的，使CPU占用率更高。因此我们修改了NGUI的内部代码，使锚点只在必要时更新。一般只在控件初始化和屏幕大小发生变化时更新即可。不过这个优化的代价是控件的顶点位置发生变化的时候（比如控件在运动，或控件大小改变等），上层逻辑需要自己负责更新锚点。
8 降低贴图素材分辨率
　　这一招说白了其实就是减小贴图素材的尺寸。比如对一张在原画里尺寸是100x80的贴图，我们将它导入Unity后会把它缩小到50x40，即缩小两倍。游戏实际使用的是缩小后的贴图。不过这一招是必然会显著降低美术品质的，美术立马会发现画面变得更模糊，因此一般不到程序撑不住的时候不会采用。
9 界面的延迟加载和定时卸载策略（暂未实施）
　　如果一些界面的重要性较低，并且不常被使用，可以等到界面需要打开显示的时候才从bundle加载资源，并且在关闭时将自己卸载出内存，或者等过一段时间再卸载。不过这个方法有两个代价：一是会影响体验，玩家要求打开界面时，界面的显示会有延迟；二是更容易出bug，上层写逻辑时要考虑异步情况，当程序员要访问一个界面时，这个界面未必会在内存里。因此目前为止我们仍未实施该方案。目前只是进入一个新场景时，卸载上一个场景用到但新场景不会用到的界面。
　　以上的9个方法中，4、5、6需要在一定程度上从策划和美术的角度考虑问题，并且需要持续保持监控以维护优化状态（因为在设计上总是会有新界面的需求或改动老界面的需求）；其它都是一劳永逸的解决方案，只要实施稳定后，就不需要再在上面花费精力。不过2和8都是会降低美术品质的方法，尤其是8。如果美术对品质的降低程度实在忍不了的话，也可能不会允许采用这两个方法。
后来又学到一招：
不要频繁的使用 &GameObject.SetActive
&我们游戏的某些逻辑会在一帧内频繁调用GameObject.SetActive，显示或隐藏一些对象，数量达到一百多次之多。这类操作的CPU开销很大（尤其是NGUI的UIWidget在激活的时候会做很多初始化工作），而且会触发大量GC。后来我们改变了显示和隐藏对象的方法&&让对象一直保持激活状态（activeInHierarchy为true），而原来的SetActive(false)改为将对象移到屏幕外，SetActive(true)改为将对象移回屏幕内。这样性能就好多了。
使用NGUI时偶尔会遇到以下两个报错：
Supplied NxActorDesc is not valid. createActor returns NULL.
Actor::updateMassFromShapes: Can‘t compute mass from shapes: must have at least one non-trigger shape!
　　通过在网上搜索，得知第一个错误其实是PhysX引擎的报错。显然Unity使用了PhysX作为物理引擎。第二个报错说的是无法通过形状计算质量，看来也是物理方面的错误。
　　目前这两个错误的具体程序原因未知，但试验发现这和NGUI对象上挂载的BoxCollider形状有关。以下方法可以很容易地重现这两个错误（注意以下步骤都是在编辑状态下，不用播放）：
在Unity编辑器中创建一个空场景。
在菜单栏中点击NGUI -& Create -& 2D UI，创建出一个UI Root。
选中刚创建的UI Root，在菜单栏中点击NGUI -& Create -& Panel，在UI Root之下创建出一个Panel孩子。
选中刚创建的Panel，在菜单栏中点击NGUI -& Create -& Widget，在UI Root之下创建出一个Widget孩子。
选中刚创建的Widget，在它身上挂载一个Box Collider。
关键的地方来了：不要勾选Box Collider的Is Trigger属性；设置Box Collider的大小&&x和y都设为正数，但z设为负数；另外将Widget的local scale设为(0, 0, 0)。
选中Panel，将其隐藏（相当于SetActive(false)），这时就会报&Supplied NxActorDesc is not valid. createActor returns NULL.&。
再把Panel打开（相当于SetActive(true)），就会报&Actor::updateMassFromShapes: Can‘t compute mass from shapes: must have at least one non-trigger shape!&。
　　如果研究过NGUI内部原理，就会知道NGUI内部会强制给每个Panel挂载一个刚体（Rigidboy）。这是因为在Unity中，没有刚体的碰撞体（Collider）属于静态碰撞体，而静态碰撞体的移动会触发物理引擎中大量的性能开销。（见，里面提到&Colliders can be added to an object without a Rigidbody component to create floors, walls and other motionless elements of a scene. These are referred to as static colliders. In general, you should not reposition static colliders by changing the Transform position since this will impact heavily on the performance of the physics engine.&。）恐怕是刚体和碰撞体之间的交互出了问题。
　　一种猜测是：刚体的质量中心是由刚体上各个碰撞体的形状计算出来的（见）。如果碰撞体的形状不正常，那可能就无法计算出质量中心，物理引擎会报错；或者计算出的质量中心就可能是一个非法的数。后一种情况可能还会影响NGUI的触屏检测。有一次我们某个界面上挂载BoxCollider的按钮出bug，点击之后毫无反应，甚至连触摸反馈动画也没有。我本想在UICamera下断点，看看是谁截住了OnClick消息，却发现连UICamera都没感知到触屏。研究了很久才发现那个按钮的BoxCollider的z尺寸设成了负数，调试中我发现那个按钮所在Panel的刚体质量中心是(NaN, NaN, NaN)。将那个BoxCollider的尺寸改成正数后，bug就消失了。（不过后来我也研究过，并不是Box Collider的尺寸为负就一定会导致该bug，可能要正好在某些数值下导致刚体质量中心为(NaN, NaN, NaN)才行。）
　　所以目前的结论就是：如果在NGUI中遇到了物理引擎的报错，或者UICamera没感知到触屏，则检查一下各个BoxCollder的尺寸是否正常。这个尺寸会受到多个因素的影响：包括Box Collider的size参数，还有GameObject（包括自己和祖宗）的scale。
原文：http://blog.csdn.net/zzxiang1985/article/details/
&&国之画&&&& &&&&chrome插件
版权所有 京ICP备号-2
迷上了代码！基于Unity中的NGUI插件，通用的UI如何设计？
招聘信息：
整理自知乎，文/以我的项目经历来说，要保证通用性必须分清需求是框架需要还是项目需要。举一个例子，所有的项目都需要一个弹窗提示的接口，但是不同项目弹窗都不一样，当时做的时候我没有想好怎么分离，那就放到项目类库里，保证框架不受影响，以后再重构。下面根据题主提的要点针对性说下方案（以NGUI框架为基础，UGUI还在研究中）：UI和场景中物体的交互如何控制目前遇到的场景中交互有几种：类似血条的显示：通过摄像机转换坐标的方法转换为UI坐标来同步血条位置。对点击等操作的响应：属于控制管理器，不应该放在UI框架中，但是UI框架需要提供UI尺寸和实际尺寸的比例便于规划控制范围。3D物体的展示：可以直接放在界面中也可以使用renderTexture，前者更方便。切换场景时对 UI 如何处理虽然unity提供了Scene这个功能给我们使用，但是我个人的最终目标是将整个游戏运行在一个场景中，但这并不影响UI框架。一个场景一个单例的管理器（M2），还有一个跨场景的管理器（M1），M2负责具体的创建和关闭，M1负责对象池之类的功能。如果多场景，场景切换时M2实例和界面就都销毁了，不需要特别处理；如果单场景，创建和销毁都已经由M2实例负责了。UI如何分组/分类以方便管理个人看来这一条本身提的比较模糊，因为可以理解为资源的管理也可以理解为结构的管理，下面分别回答。资源管理：小的项目可以使用公用图集（+Texture）的方式，大的项目UI资源太多，只靠公用图集肯定会造成内存的严重占用，所以建议是公用图集+功能图集（+Texture）。功能图集就是一个功能模块的公用图集，在功能操作完毕时就可以释放掉了。这里涉及到的细节太多，就不展开了。结构管理：我的思路是分为三类：1控件，就是button、label、sprite等等。（像buttonGroup就是button的组合，使用代码创建和控制）2弹窗/界面/列表项，这三者都由控件组成。3共用布局，这一类是为了节省时间而分的，比方说卡牌游戏中反复出现的卡牌布局其实就是共用布局，每个界面重复制作显然浪费，是否有这类关键在于UE结构是否明确和复杂布局的复用程度。如何统一管理UI的深度这条可以引申为Z坐标（如果UI中有3D物体或者UI本身就是3D的）、renderQueue、界面的调用顺序等全局属性的管理。这些内容都应该在界面制作的时候就记录在界面信息上，在创建、聚/失焦、关闭界面时记录在管理器中。UI本身的深度其实很好管理，麻烦在UI上可能会有3D物体和特效，不同的shader可能会导致不同的问题。打开、关闭时的动效，以及被遮挡时的动效动效本身其实更应该当作项目需求而不是框架需求。首先建议有单独的动效管理器，其次如果项目规划中对动效规划不明确，可以放在具体实现中。如果项目中没有靠谱的UE设计，框架做得越多其实越累。引用程序界的质能公式：error=(more code)^{2}3DUI相比2D多了很多问题，要提前想清楚，比方说在界面上有3D物体的情况下（不用renderTexture）打开弹窗时，Z坐标和缩放的管理。
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量4568点击量4014点击量3938点击量3237点击量3073点击量2896点击量2733点击量2585点击量2570
&2016 Chukong Technologies,Inc.
京公网安备89}