Unity制作头顶血条方式对比与优化

制作方式主要有四种：OnGUI、NGUI、UGUI、Shader

区别

UGUI的Canvas 有世界坐标和屏幕坐标

UGUI的Image可以使用material

UGUI通过Mask来裁剪，而NGUI通过Panel的Clip

NGUI的渲染前后顺序是通过Widget的Depth，而UGUI渲染顺序根据Hierarchy的顺序，越下面渲染在顶层.

UGUI 不需要绑定Colliders，UI可以自动拦截事件

UGUI的Anchor是相对父对象，没有提供高级选项，个人感觉uGUI的Anchor操作起来比NGUI更方便

UGUI没有Atlas一说，使用Sprite Packer

UGUI的Navgation在Scene中能可视化

UGUI的事件需要实现事件系统的接口，但写起来也算简单

UGUI的Button属性面板的的OnClick

优劣势对比

OnGUI

在Unity4.6之前，官方提供的是OnGUI函数来开发UI界面，当然问题也比较多，首先不支持可视化开发，其次UI始终位于所有3D对象的上方，无法实现在UI上添加3D模型的效果。

现在一般这套系统多用来在Unity编辑器中开发界面或者快速搭建一些调试界面时使用。

Shader

对于不同屏幕比例纠结时，用shader画好点。网上只看到用来制作简单血条，具体对比尚不清楚。

比较主流的是用NGUI和UGUI，先贴出部分对比图



UGUI

这套官方的UI系统就是被Unity请去的NGUI作者开发的，所以在操作上两者大体一致，同时UGUI是开源的系统，获得UGUI的源码链接：https://bitbucket.org/Unity-Technologies/ui/src

官方案例：https://www.assetstore.unity3d.com/en/#!/content/25468

优点：

首先，5.2版本之后，Unity逐渐将一部分UGUI的计算放到子线程去做，以此来缓解主线程的压力；

其次，UGUI的UIMesh生成是通过底层C++代码实现的，而NGUI只能通过在上层不断创建vertex list来进行，这样在堆内存的管理上，UGUI确实要好很多，带来的隐性收益就是GC触发次数会少很多。

NGUI还保留着图集，需要进行图集的维护。而UGUI没有图集的概念，可以充分利用资源，避免重复资源。

UGUI出现了锚点的概念，更方便屏幕自适应。

UGUI尚未成熟，但毕竟是官方的，新出的unity5使用了全新的ab打包方式，看上去要封杀ngui的样子。

缺点：

不能很可视化的制作 draggable object

暂时没有 localization（本地化）支持

scroll view只有Panel，没有camera scroll view

没有 UIWrap 来 循环 scrollview 内容

暂时没有Tween组件及Play Audio，Button Offset，需要DoTween之类插件辅助

UGUI没有 UIWrap 来循环 scrollview 内容。

NGUI

大名鼎鼎的NGUI是可以看做是开发Unity游戏必备的插件，支持可视化开发，同时也支持2D和3D UI的开发，想在UI上显示3D模型和粒子也没问题。一套NGUI的学习笔记：http://www.cnblogs.com/hammerc/p/4481597.html

优点：

NGUI支持图文混排，UGUI暂未发现支持此功能。

ngui是外部开发的插件，但是ngui比ugui早很多

UGUI注意点:

要防止多个canvas叠加点击穿透，canvas里面的graphics raycaster调整到恰当选项

防止canvas在物体上层，点击canvas却穿透到物体上，触发物体的点击的事件，请参见下面示例代码

NGUI注意点:（超级影响性能的几点）

动画最好作用于panel而不是sprite

Sprite Type中的tile能不用就不用，卡死人

参考文章：

http://blog.csdn.net/u011926026/article/details/53982117

http://www.cnblogs.com/zhaoqingqing/p/3975043.html

http://www.cnblogs.com/hammerc/p/4837204.html

http://www.manew.com/forum.php?mod=viewthread&tid=39435&page=0

（较详细）http://www.gimoo.net/t/1603/56f09911972bb.html

个人决定用UGUI，以为为记录的注意事项

一般会把slider下面的Background和Handle Slide Area删除掉或者禁用掉。

要实现任务跟随，必须把Canvas的渲染模式选择WorldSpace，然后把相机添加进去，这是最重要最关键的一步。

在Player身上加一个Follow脚本，在Player身上加脚本而不在slider身上加脚本的原因是我想让血条超出屏幕就关闭显示，这样对优化有好处。

给每个物体下挂一个canvas，便于管理，但是会每个canvas会产生一条DrawCall？？

参考文章：

（较详细）http://www.jianshu.com/p/a9fd13594f18

http://blog.sina.com.cn/s/blog_657455c00102vf8w.html

http://blog.csdn.net/u011185231/article/details/50363392

http://blog.csdn.net/u011185231/article/details/50363731

http://www.cnblogs.com/liang123/p/6325846.html

UGUI性能优化

UGUI会自动检测优化，如果多个材质间没有遮挡或只有小部分不影响的遮挡则会合并DrawCall为一个。如下图：



尽可能保证Text在Image的上方。字体的DrawCall就可能自动会优化，而不需要像NGUI那样让字体跟图片pack在一起来减少DrawCall。

尽可能保证Image之间不存在不必要的重叠。

UI变色：修改材质和修改顶点色两种方式

合并DrawCall一定要是相同的材质，修改材质会将本来已合并的DrawCall分离开，就导致了DrawCall的增加及Canvas的重建。

修改顶点色（Button中Transition中的ColorTint方式）只会修改Canvas中的数据。

UI边框：Sliced & Fill Center

Sliced模式的Sprite更节省纹理尺寸。

中空的边框不应该勾选Fill Center，可减小Fill rate。

Mask的代价，通过Stencil buffer实现

移动平台需要Use 24-bit Depth Buffer（Tegra GPU 2、3上不支持，4支持）。

Mask中的UI元素无法与其他batch，从而增加DrawCall。

可以的话尝试用Filled Sprite代替。

动画：Text vs Image

如果Image上做了动画则Canvas需要重建，Image的顶点数一般不会很多，开销不会很大。

Text与文本内容（生成的网格数）相关，如果文字比较多则相比Image开销可能会翻倍。

Canvas的重建主要就是为了合并DrawCall，可以将有动画的文字放在单独的Canvas中去，手动分离DrawCall（增加DrawCall）后就不会再要去跟别的文字作合并，该Canvas就不需要再重建故减少了重建开销。

尽可能使用缓冲池。如人物身上的伤害数字，生成时会有较大的开销因为有Mesh的生成等过程。

参考文章：

（原文）http://www.cnblogs.com/suoluo/p/5417152.html

（链接列表）http://www.manew.com/home.php?mod=space&uid=105915&do=thread&view=me&from=space