精华内容
下载资源
问答
  • NGUI 优化

    2017-03-23 23:23:00
    1. Update  Ngui 组件继承关系是 UIWidget:UIRect :MonoBehaviour. 因此由每个组件的独自调用update变更为,由...2. NGUI UIDrawcall 优化:  参考:NGUI开发技巧(上,下) https://v.qq.com/x/page/j0336jnc...

    1. Update

      Ngui 组件继承关系是  UIWidget : UIRect : MonoBehaviour. 

    因此由每个组件的独自调用update变更为,由某个更新点,统一调用会效率提升。并且可以调整更新频率。

     

    2. NGUI UIDrawcall 优化:

     参考:NGUI开发技巧(上,下)

          https://v.qq.com/x/page/j0336jncwn5.html

          https://v.qq.com/x/page/r0342tl5e47.html

     

      工具:NGUI->Open-> Panel Tool && UIDrawCall Tool 

      A. UIDrawCall 个数优化。

       一个panel可以多个UIDrawcall UIDrawcall个数 = 将此panel下的widget按depth排序,材质相同的划归为一个UIDrawCall. 

         所以减少DrawCall个数就要尽可能的避免材质交叉,即把材质相同的widget的depth调到相邻。

       优化方法:

            a. 文字与图片depth规划好。

            b. 调 widget.depth

      B. UIDrawCall.UpdateGeometry:  Set the draw call's geometry

        包括某一个UIDrawCall内部三角形重建,另一种情况是此UIPanel下的所有DrawCall的重建。

         第一种情况常出现在:此DrawCall内顶点数据变更(如transform位移,缩放,颜色变化)都会触发此mydrawCall.updateGeometry().

         第二种情况(重建所有DrawCall)出现在 UIPanel.mRebuild = true 的情况。如

          a. UIPanel.RemoveWidget (UIWidget w): w 正好是某个drawCall的边界组件。

              b. 材质交叉:使用了a材质的widget.depth插入了使用b材质的某个drawcall. 

              c. panel.OnInit 及 OnEnable时。

       优化原理:

           a. 避免重建.  

         b. 不可避免重建时,减少重建的量。

         常用方法:

            a. 动静分离:加UIPanel.重建时只重建动态部分的三角形

      C. UITexture不是使用的图集所以会单独占用一个DrawCall.  

      D. UI上的粒子特效: 不会影响UIDrawCall个数。

     

    3. UILable:  OutLine, Shadow. 效果

    4. UISprite: 平铺类型

    5. UIFont: 

        文字的材质合并不到一起,可能的原因是使用了不同的字体。       

     

    转载于:https://www.cnblogs.com/javalzy/p/6607988.html

    展开全文
  • 【Unity】NGUI优化

    2015-04-28 07:27:17
    NGUI优化从以下入手:资源,贴图,内存,GameObject,UI(DrawCall)。 资源优化 》资源分离打包与加载; 资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般只分离字体和贴图这种体积较大的...
    NGUI优化从以下入手:资源,贴图,内存,GameObject,UI(DrawCall)。

    资源优化
    》资源分离打包与加载;
    资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般只分离字体和贴图这种体积较大的公用资源。可以用AssetDatabase.GetDependencies得知一份资源使用了哪些其它资源。
    》界面的延迟加载和定时卸载策略;

    贴图优化
    》贴图透明通道分离,压缩格式设为ETC/PVRTC;
    安卓上硬件支持最广泛的格式是ETC,苹果上则是PVRTC。因此我们将每张原始贴图的透明通道都分离了出来,写进另一张贴图的红色通道里。这两张贴图都采用ETC/PVRTC压缩。渲染的时候,将两张贴图都送进显存。同时我们修改了NGUI的shader,在渲染时将第二张贴图的红色通道写到第一张贴图的透明通道里,恢复原来的颜色。
    》关闭贴图的读写选项;
    》整理图集;
    整理图集的主要目的是节省运行时内存(虽然有时也能起到合并DrawCall的作用)。
    1)在界面设计上,尽量让美术将控件设计为可以做九宫格拉伸,即UISprite的类型为Sliced。
    2)同样是在界面设计上,尽量让美术将图案设计成对称的形式。GameObject数量的增多有时也会显著占用更多内存。因此一般只对尺寸较大的图案采用这个方法。
    3)确保不要让不必要的贴图素材驻留内存,更不要在渲染时将无关的贴图素材送进显存。不过,如果两个界面之间存在大量相同的素材,那么这两个界面就可以共用同一张图集。另外,数量庞大的图标资源(如物品图标)不要做在图集里,而应该采用UITexture。
    4)减少图集中的空白地方。
    有时一张1024x1024的图集中,素材所占的面积还没超过一半,这时可以考虑将这张图集切成两张512x512的图集。
    》降低贴图素材分辨率;

    NGUI内存优化
    NGUI的Texture和Sprite释放;切换场景后第一时间调用 Resources.UnloadUnusedAssets () 释放掉。
    但是如果脚本程序用到NGUI的组建的时候,比如直接拖到脚本上的物体,或者Find的物体等,只要引用NGUI的组建,它就会加到内存中,切换场景也不会释放,Resources.UnloadUnusedAssets ();也不会释放,你要结束的时候删除这些引用,就会释放掉了;

    GameObject优化
    》减少场景中的GameObject数量;
    GameObject身上还挂载了不少脚本,每个GameObject中的每个脚本都要实例化,又是一比不菲的内存占用。因此后来我们规定场景中的GameObject数量不得超过1万,并且将GameObject数量列为每周版本的性能监测指标。
    避免频繁调用GameObject.SetActive
    让对象一直保持激活状态(activeInHierarchy为true),而原来的SetActive(false)改为将对象移到屏幕外,SetActive(true)改为将对象移回屏幕内。这样性能就好多了。

    UI界面优化(Drawcall)
    》根据各个UI控件的设计安放Panel,隔开DrawCall;
    将UI控件分组,将一段时间内会发生变化的控件——比如怪物头顶的血条和伤害跳字放在同一个Panel上,并且这个Panel上只有这些控件,其余基本不变化的控件就放在别的Panel上。
    》NGUI的DrawCall优化

    1.少用Panel;

    2.少用Atlas;

    3.尽量避免夹层(即不同材质的UISprite相互间层级夹杂,如L2,L4使用mat1,L1,L3使用mat2,这样就形成夹层现象);


    具体分层实现思路如下:

    1.背景、按钮等置于底层,因为彼此间可能有层级关系,因此分配了1-4这么几个层级来放置底层UISprite;

    2.文字展现基本置于顶层,因此把所有UILabel的层次提高,如第5层这样的;

    3.同一个UIPanel下的texture和font尽量放在同一个atlas下。也表达了另外一个意思,使用同一个atlas的元素尽量放在同一个UIPanel下面。

    4.如果一个UIPanel下面使用了多个atlas,那么尽量让使用相同atlas的元素连续,尽量避免atlas交叉。


    》优化锚点内部逻辑,使其只在必要时更新;
    即使是在控件静止不动的情况下,控件的锚点也会每帧更新(见UIWidget.OnUpdate函数),而且它的更新是递归式的,使CPU占用率更高。因此我们修改了NGUI的内部代码,使锚点只在必要时更新。一般只在控件初始化和屏幕大小发生变化时更新即可。




    展开全文
  • 关于Unity中的NGUI优化,你可能遇到这些问题汇总。

    原文链接:https://blog.uwa4d.com/archives/QA_NGUI-1.html

    关键字

    界面制作
    界面切换
    网格重建
    UICamera.Update
    Draw Call
    加载
    字体


    一、界面制作

    Q1:我用的是NGUI,本来已经打包图集了,输出时候是不是就不用理会那些原始2D Sprite图 ?粒子贴图需要Packing Tag吗?

    在NGUI中使用Atlas后,原纹理是不需要进行打包或进行其他特殊处理的,因为理论上这些资源在运行时已不再需要。粒子系统所使用的纹理并不是Sprite类型的,因此不需要设置Packing Tag。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58dbba664e69b5ed22e68ab4

    Q2:NGUI变形,如下图走样了,请问是不是图片压缩导致的?
    请输入图片描述

    当UI纹理在设备上的显示分辨率低于原始分辨率时,会因为出现aliasing现象,导致UI局部变形。通常对于粗线条、块状的UI图素,变形通常是不明显的,但对于细线条的UI图素,则可能非常明显。
    通常该问题可以考虑三种方式来改善:

    1. 在NGUI中将UIRoot的Scaling Style设置为Flexible,这种方式的好处在于UI纹理不会因为设备分辨率的限制而降低,而缺点在于相同的UI纹理在高分辨率设备上显得比较小,而在低分辨率设备上显得比较大,从而提高了UI布局的复杂度;
    2. 将UI纹理的显示分辨率(Sprite的size属性)设定为高于原始分辨率,其缺点在于高分辨率设备上可能会产生模糊,但大多数情况下“模糊”相比于“走样”更不易察觉;
    3. 开启UI纹理的Mipmap,从而在低分辨率设备上自动切换到低Level,以“模糊”替换“走样”,但缺点在于增加了纹理的大小,因此只适用于出现了明显变形的少量UI。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d49f5dc5233b18793e0c4b

    Q3:能否在NGUI多分辨率适应方面提供一些解决方案或者思路?

    多分辨率适应涉及到以下几个方面:

    1. 布局。通常可以通过 NGUI 中的 Anchor 组件来实现,能够保证 UI 到屏幕上指定锚点的距离;
    2. UI 背景图比例。通常我们建议将背景图的长宽比放大,以适配不同长宽比的屏幕,但要注意两边需要留空,或者保留可被裁掉的元素;
    3. UI 的整体缩放。可以通过 UIRoot 组件的 Scaling Style 来统一配置。

    需要提醒的是,不同类型的游戏对布局的需求通常也不同,因此还是需要结合实际开发情况来做调整。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d2930c9ad5c0094f461e66

    Q4:我看到UICamera.Update()的GC调用特别高,只要我一移动就会产生2.8K的GC,看起来是NGUITools.FindInParents这个方法导致的,有没有什么可以优化的方法呢?

    请输入图片描述
    请输入图片描述

    在 Editor 下,当调用GetComponent() 且 T组件并不在当前的GameObject 上时,确实会出现GC Alloc,但这在发布后是不会出现的,因此建议在真机上做一个验证。这是因为在Editor下,Unity的MissingComponentException实现所致,在出现以上情况时,Unity 并不是直接返回一个 NULL,而是返回一个代理 Object用来储存一些相关信息,在后续被访问时可以给出更详细的报错信息。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d29ccb4ecd88b86cb570d5

    二、网格重建

    Q1:我用NGUI开发,因为角色名字导致重建,使得UIPanel.LateUpdate的CPU占用很高。如果将它们分离到多个UIPanel里,是否这个开销会相对小一些?

    将较多的动态UI元素分组放在不同的UIPanel中确实是UWA比较推荐的方式,一方面可以降低重建的概率,某些分组中可能没有UI元素发生变化,从而不会进行重建;另一方面可以降低重建的开销。通过分组,可以将每个UIPanel所产生的Mesh控制在较小的范围内,从而控制其重建的开销(通常重建的开销会因Mesh的增大而明显升高,且不是线性的关系)。虽然这种做法会产生额外的DrawCall,但DrawCall的开销与网格重建相比通常都非常小。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d259d97dc35e7f0efb4738

    Q2:我的UWA报告中看到几乎每次切换场景都会有UIPanel.LateUpdate()这个函数的堆内存开销,请问说明了什么问题,我是否还能优化?
    请输入图片描述

    UIPanel.LateUpdate持续分配较大量的堆内存,说明UI界面在制作上存在以下问题:

    1. Panel中Widgets数量过多,且存在频繁的变动,导致UIPanel需要进行大量的网格重建;
    2. 动静态UI元素没有分离;
    3. 建议研发团队对UI界面的制作进行进一步检测,尽可能将静态UI元素和动态UI元素分开,存放于不同的Panel下。同时,对于不同频率的动态元素也建议存放于不同的Panel中。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d259167dc35e7f0efb4734

    Q3:UWA建议“尽可能将静态UI元素和频繁变化的动态UI元素分开,存放于不同的Panel下。同时,对于不同频率的动态元素也建议存放于不同的Panel中。”那么请问,如果把特效放在Panel里面,需要把特效拆到动态的里面吗?

    通常特效是指粒子系统,而粒子系统的渲染和UI是独立的,仅能通过Render Order来改变两者的渲染顺序,而粒子系统的变化并不会引起UI部分的重建,因此特效的放置并没有特殊的要求。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d29af75a5050b366a6b6ab

    三、界面切换

    Q1:我在Profiler中看到GameObject.Deactivate耗时较大,请问该如何优化?

    实际上GameObject.Activate/Deactivate本身通常不会产生很高的开销,主要都是由其上或其子节点上的组件的OnEnable/OnDisable操作引起,比如UI相关的组件在OnEnable和OnDisable中都会有较多的操作,所以较复杂的UI界面的GameObject.Activate/Deactivate会有很高的开销。因此,针对这一问题,如果是由自定义的脚本造成,那么就需要考虑优化OnEnable/OnDisable的逻辑;如果是UI,那么可以对频繁切换激活状态的UI采用平移出屏幕、修改Culling Layer等方式来替换。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58dba87a96a4860c52acada7

    Q2:游戏中出现UI界面重叠,该怎么处理较好?比如当前有一个全屏显示的UI界面,点其中一个按钮会再起一个全屏界面,并把第一个UI界面盖住。我现在的做法是把被覆盖的界面 SetActive(False),但发现后续 SetActive(True) 的时候会有 GC.Alloc 产生。这种情况下,希望既降低 Batches 又降低 GC Alloc 的话,有什么推荐的方案吗?

    可以尝试通过添加一个 Layer 如 OutUI, 且在 Camera 的 Culling Mask 中将其取消勾选(即不渲染该 Layer)。从而在 UI 界面切换时,直接通过修改 UIPanel 的 Layer 来实现“隐藏”。但需要注意事件的屏蔽,禁用动态的 UI 元素等等。
    这种做法的优点在于切换时基本没有开销,也不会产生多余的 Draw Call,但缺点在于“隐藏时”依然还会有一定的持续开销(通常不太大),而其对应的 Mesh 也会始终存在于内存中(通常也不太大)。
    以上的方式可供参考,而性能影响依旧是需要视具体情况而定。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58dd18e84e69b5ed22e68ad7

    Q3:通过移动位置来隐藏UI界面,会使得被隐藏的UIPanel继续执行更新(LateUpdate有持续开销),那么如果打开的界面比较多,CPU的持续开销是否就会超过一次SetActive所带来的开销?

    这确实是需要注意的,通过移动的方式“隐藏”的UI界面只适用于几个切换频率最高的界面,另外,如果“隐藏”的界面持续开销较高,可以考虑只把一部分Disable,这个可能就需要具体看界面的复杂度了。一般来说在没有UI元素变化的情况下,持续的 Update 开销是不太明显的。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58dd18a54e69b5ed22e68ad5

    Q4:如图,我们在UI打开或者移动到某处的时候经常会观测到CPU上的冲激,经过进一步观察发现是因为Instantiate产生了大量的GC。想请问下Instantiate是否应该产生GC呢?我们能否通过资源制作上的调整来避免这样的GC呢?如下图,因为一次性产生若干MB的GC在直观感受上还是很可观的。
    请输入图片描述

    准确的说这些 GC Alloc 并不是由Instantiate 直接引起的,而是因为被实例化出来的组件会进行 OnEnable 操作,而在 OnEnable 操作中产生了 GC,比如以上图中的函数为例:

    上图中的 UILabel.OnEnable 是在实例化一个 UI 界面时,UI 中的文本(即 UILabel 组件)进行了 OnEnable 操作,其中主要是初始化文本网格的信息(每个文字所在的网格顶点,UV,顶点色等等属性),而这些信息都是储存在数组中(即堆内存中),所以文本越多,堆内存开销越大。但这是不可避免的,只能尽量减少出现次数。

    因此,我们不建议通过 Instantiate/Destroy 来处理切换频繁的 UI 界面,而是通过 SetActive(true/false),甚至是直接移动 UI 的方式,以避免反复地造成堆内存开销。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d3d663dae058bb3c56af47

    四、字体

    Q1:对NGUI字体错乱有什么好的解决方案吗?

    有这么几种可能:

    1. 一次展开文字太多了。这种情况在部分高通机型和Unity早期版本上都经常出现,现在也偶尔有,究其原理是FontTexture的扩容操作做得不够快或者收到了硬件驱动的限制。
      一般来说有两种方法可以解决:(1)减少面板中的字体内容;(2)一开始就用超大量的字体去扩容,将动态字体的FontTexture扩大到足够大;
    2. 文字渲染与开发团队编写的多线程渲染发生了冲突。这种情况也常有发生,特别是通过GL.IssuePluginEvent方式来开启多线程渲染的项目,就会容易出现问题。
      就我们的优化经验来看,第一种情况发生的可能性比较大。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d2558d7dc35e7f0efb4728

    Q2:我在用Profiler真机查看iPhone App时,发现第一次打开某些UI时,Font.CacheFontForText占用时间超过2s,这块主要是由什么影响的?若iPhone5在这个接口消耗2s多,是不是问题很大?这个消耗和已经生成的RenderTexture的大小有关吗?

    Font.CacheFontForText主要是指生成动态字体Font Texture的开销, 一次性打开UI界面中的文字越多,其开销越大。如果该项占用时间超过2s,那么确实是挺大的,这个消耗也与已经生成的Font Texture有关系。简单来说,它主要是看目前Font Texture中是否有地方可以容下接下来的文字,如果容不下才会进行一步扩大Font Texture,从而造成了性能开销。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58dbad6b09b061fe195d60b4

    五、加载相关

    Q1:加载UI预制的时候,如果把特效放到预制里,会导致加载非常耗时。怎么优化这个加载时间呢?

    UI和特效(粒子系统)的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成:

    1. 纹理资源加载耗时
    UI界面加载的主要耗时开销,因为在其资源加载过程中,时常伴有大量较大分辨率的Atlas纹理加载,我们在之前的Unity加载模块深度分析之纹理篇有详细讲解。对此,我们建议研发团队在美术质量允许的情况下,尽可能对UI纹理进行简化,从而加快UI界面的加载效率。
    请输入图片描述

    2. UI网格重建耗时
    UI界面在实例化或Active时,往往会造成Canvas(UGUI)或Panel(NGUI)中UIDrawCall的变化,进而触发网格重建操作。当Canvas或Panel中网格量较大时,其重建开销也会随之较大。

    3. UI相关构造函数和初始化操作开销
    这部分是指UI底层类在实例化时的ctor开销,以及OnEnable和OnDisable的自身开销。

    上述2和3主要为引擎或插件的自身逻辑开销,因此,我们应该尽可能避免或降低这两个操作的发生频率。我们的建议如下:

    1. 在内存允许的情况下,对于UI界面进行缓存。尽可能减少UI界面相关资源的重复加载以及相关类的重复初始化;
    2. 根据UI界面的使用频率,使用更为合适的切换方式。比如移进移出或使用Culling Layer来实现UI界面的切换效果等,从而降低UI界面的加载耗时,提升切换的流畅度。
    3. 对于特效(特别是粒子特效)来说,我们暂时并没有发现将UI界面和特效耦合在一起,其加载耗时会大于二者分别加载的耗时总和。因此,我们仅从优化粒子系统加载效率的角度来回答这个问题。粒子系统的加载开销,就目前来看,主要和其本身组件的反序列化耗时和加载数量相关。对于反序列化耗时而言,这是Unity引擎负责粒子系统的自身加载开销,开发者可以控制的空间并不大。对于加载数量,则是开发者需要密切关注的,因为在我们目前看到的项目中,不少都存在大量的粒子系统加载,有些项目的数量甚至超过1000个,如下图所示。因此,建议研发团队密切关注自身项目中粒子系统的数量使用情况。一般来说,建议我们建议粒子系统使用数量的峰值控制在400以下。
      请输入图片描述

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58d25a537dc35e7f0efb4740

    Q2:我有一个UI预设,它使用了一个图集, 我在打包的时候把图集和UI一起打成了AssetBundle。我在加载生成了GameObject后立刻卸载了AssetBundle对象, 但是当我后面再销毁GameObject的时候发现图集依然存在,这是什么情况呢?

    这是很可能出现的。unload(false)卸载AssetBundle并不会销毁其加载的资源 ,是必须调用 Resources.UnloadUnusedAssets才行。关于AssetBundle加载的详细解释可以参考我们之前的文章:你应该知道的AssetBundle管理机制。

    该问题来自UWA问答社区,如您对该问题仍有疑问,可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/58da55111ccdfe463a4f87c7
    展开全文
  • NGUI优化方法

    2015-04-29 09:13:22
    做3d移动端内存一直是人们头疼的问题,加载的资源释放了,还有其他的需要释放,比如ngui释放,其实主要是NGUI的Texture和Sprite释放,如果你脚本程序没用到NGUI组建的引用的话,切换场景后第一时间调用 Resources...

    转载自:http://www.taidous.com/thread-2348-1-1.html

    做3d移动端内存一直是人们头疼的问题,加载的资源释放了,还有其他的需要释放,比如ngui释放,其实主要是NGUI的Texture和Sprite释放,如果你脚本程序没用到NGUI组建的引用的话,切换场景后第一时间调用

    Resources.UnloadUnusedAssets ();

    就会释放掉。

    但是如果你脚本程序用到NGUI的组建的时候,比如直接拖到脚本上的物体,或者Find的物体,等,只要引用NGUI的组建,它就会加到内存中,切换场景也不会释放,Resources.UnloadUnusedAssets ();也不会释放,你要结束的时候删除这些引用,就会释放掉了

    我引用ios的思想去释放的,写了个dealloc方法


    在你的脚本之间交互类中写

    [C#]  纯文本查看  复制代码
    ?
    01
    02
    03
    04
    05
    06
    07
    08
    09
    10
    11
    12
    13
    void dealloc(){
         先调用其他脚本的dealloc
         再释放本脚本中的
        比如我把这些引用加到一个数组里
     
         for ( int i = 0; i < UISpritsInScene.Count; i++) {
             DestroyImmediate(UISpritsInScene);
             UISpritsInScene= null ;
         }
     
         Resources.UnloadUnusedAssets ();
         System.GC.Collect ();
    }

    就可以释放掉,对移动端大有好处,我从之前的130MB内存,优化到现在的50MB左右,很是稳定


    展开全文
  • NGUI优化方法总结

    2015-04-29 09:55:27
    1.尽量少使用Panel 2.Panel下面的子物体,尽量使用同一个图集 ...3.尽量控制使用动态字体,不要大量使用动态字体控件,如果可以的话,将字体也做成图集 ...4.如果同一个Panel下,必须使用多个图集,或使用了动态...
  • NGUI优化之Drawcall

    2014-05-17 01:01:00
    今天在运行之前的程序时,无意中发现一个简单的menu菜单页面drawcall居然达到接近30了,这个数值感觉太高了。 后网上查询关于降低drawcall的方法,发现主要有以下几点: 1.少用Panel; 2.少用Atlas;...
  • 当ScrollView中Grid子级太多的时候,会导致卡顿的效果。通过重写MultiRowWrapContent的函数即可有效解决。只需要在Grid上绑定这一个脚本,填写Item的数量,以及单元格大小,滑动的时候就会自动调整Item位置,来实现...
  • NGUI List优化

    2018-04-20 11:33:00
    腾讯是如何做 Unity 手游性能优化的 ...Unity - NGUI - 优化ScrollView的一些心的 https://www.cnblogs.com/9-de/p/5109057.html NGUI滑动优化,滑动系数,滑动慢问题UIScrollView https://www.bobs...
  • NGUI开发优化技巧

    2018-06-01 14:45:50
     主要用Constrained设置(content width和content height)进行整体布局------Constrained On Mobiles(NGUI做好了不同的适配)  或者如果是选取了Flexiable且横屏状态下,就需要动态改变适配的高度(一般是PC端...
  • NGUI ScrollView优化

    2016-08-19 14:14:42
    参考网址: http://blog.gamerisker.com/archives/433.html
  • Unity+NGUI性能优化方法总结---优化 资源分离打包与加载是最有效的减小安装包体积与运行时内存占用的手段。一般打包粒度越细,这两个指标就越小;而且当两个renderQueue相邻的DrawCall使用了相同的贴图、材质和...
  • 引言 接上一篇文章对UIPanel的分析。定量的分析哪些因素会影响NGUI drawcall的增减。 SortWidgets FillAllDrawCalls的部分代码 if (mSortWidgets) SortWidgets(); // 对widgets进行排序 for (int i = 0; i ; ++i)
  • NGUI UIScrollView卡顿,使用对象池性能优化解决方案
  • NGUI UIScrollView 性能优化

    热门讨论 2014-10-30 18:48:41
    配套博文:http://blog.csdn.net/anyuanlzh/article/details/40621889
  • NGUI Drawcall 优化

    千次阅读 2015-03-20 11:01:56
    NGUI 方面的Draw Call 优化: (1) 打包图集 一、每个材质/纹理的渲染一定是会产生DrawCall的,这个DrawCall只能通过打包图集来进行优化。 二、从功能角度进行划分,例如UI可以划分为公共部分,以及每个...
  • NGUI drawcall优化

    2020-05-27 19:22:53
    NGUI drawcall优化 UILable、UISprite、UITexture都是继承UIWidget,同一Panel上的UIWidget满足texture、shader、material都相同并且depth相同或连续可合批 Drawcall多的主要原因是widget的depth相互穿插渲染时不...
  • NGUI DrawCall优化

    千次阅读 2016-03-11 23:32:48
    上一篇博客主要是简单的介绍了下NGUI合并DrawCall的基本原理,就是将一个UIPanel里所有的UIWidget按照Depth的大小进行排序,然后遍历排序后的UIWidget列表,将Depth相邻的并且懂事引用同一个Atlas的UIWidget的几何...
  • UGUI和NGUI的区别: 使用率:NGUI占大多数,NGUI和UGUI的使用占比为81% : 19%; 易用性:NGUI占一定优势,UGUI仍在慢慢改善; 性能:如果都合理搭配,UGUI...但NGUI优化相对更简单一些,主要是因为NGUI的Drawca
  • NGUI Draw Call优化

    2018-02-01 15:46:31
    NGUI Draw Call优化 转自:http://www.cnblogs.com/ybgame/p/3588795.html 现在的游戏跑起来会有接近130-170个左右的DrawCall,游戏运行起来明显感觉到卡,而经过一天的优化,DrawCall成功缩减到...
  • NGUI性能优化方法总结

    2017-12-20 18:00:33
     在上一点优化了Panel的DrawCall重建效率之后,我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下,控件的锚点也会每帧更新(见UIWidget.OnUpdate函数),而且它的更新是递归式的...
  • 使用NGUI项目优化总结

    2017-03-23 13:37:25
     在上一点优化了Panel的DrawCall重建效率之后,我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下,控件的锚点也会每帧更新(见UIWidget.OnUpdate函数),而且它的更新是递归式的...
  • NGUI更新开销:NGUI进行自身的数据更新以及生成网格的过程中所产生的开销,目前UI部分的CPU耗时大部分都是这部分的开销; NGUI的更新开销几乎全部来源于UIPanel.LateUpdate中;一般超过3~4ms,说明这部分更新开销...
  • Unity3D之NGUI优化

    2015-04-28 00:21:13
     在上一点优化了Panel的DrawCall重建效率之后,我们发现NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下,控件的锚点也会每帧更新(见UIWidget.OnUpdate函数),而且它的更新是递归式的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,997
精华内容 798
关键字:

ngui优化