【Unity游戏开发】FairyGUI与NGUI使用对比
发表于2018-10-16
一直在做Unity方面的游戏开发，接触了FairyGUI之后，发现其有超强的UI编辑器，支持跨平台开源UI解决方案，提高制作效率，可以导出到Unity、Flash、Starling等，文档还说未来将支持UE4，Cocos2d-x、libgdx等。
做过Unity的同学都知道，Unity4.6以前的版本原生GUI运行效率是非常低的，在移动设备上基本被卡的嗷嗷的，4.6版本之后Unity开发了一套新的GUI，据说运行效率大大提升，非常好用，大有取代NGUI的意思，而且听说Unity的新版UI系统曾经hire过NGUI的作者，很多观点都和NGUI类似。在没有新版原生UI系统时大部分都用NGUI，可想而知NGUI的影响力。NGUI提供了多种控件和灵活的UI处理方式，但是NGUI也有明显缺点。
1.NGUI需要维护图集，做过项目的同学都知道，图集处理不好会造成资源的重复浪费，就是说要把UI图片预先打成包，以便界面使用，但是在实际项目中改动如果太过频繁，有些根本用不到的图片也不知道有没有用过，删了又担心造成资源丢失的情况，除非对这一块特别熟悉的人，一般人都不敢乱删图片资源。就算图集里面都是有用的资源，但是也会出现这样一种情况：同学1在Atlas A里面增加了一个图片P1运用到某个界面中，同学2不知道Atlas A里面新增了P1，于是他在Atlas B里面又增加了P1运用到另一个界面中，这时Atlas A和Atlas B里面就都包含有图P1，造成了浪费，不过这点浪费这时看可以忽略不计，但是假如图片P1需要更新，这时灾难来了，由于多个Atlas用到了P1，根本不知道要更新哪一个Atlas，而且只要增加图片或者更新图片都需要更新图集，维护起来比较麻烦。
2.NGUI的消息响应机制是利用sendmessage来实现，而sendmessage利用反射机制，本身NGUI组件的身上已经挂了很多默认组件，在运行时就需要先load这些映射关系，先缓存起来，调用的时候在通过安全检查，字符串匹配，参数匹配与转换，最后才去invoke方法。如果在项目开发中又新加一些自定义组件并定义了NGUI事件方法，对运行时的效率就会产生一些影响，反射这个不一定不好，要分具体情况，需要结合实际场景自行判断。
而对于FairyGUI，在图集方面相对好一点，它提供独立的UI编辑器，每个Atlas可以对应一个包也可以对应多个包，包里面的资源可以共用，不会因为包A里面的某资源更新了包B里面的资源没有更新，因为两个包之间可以共用资源，更新一个都可更新。同样，可以自行设置对应的Atlas。
它的优点是UI独立出来了，可以自行组装，然后发布到需要的平台，然后对应的平台可以写独立的逻辑，实现了分层结构。而且UI编辑器功能强大，一般的效果基本都能满足。
缺点是只能在UI编辑器里面制作动画，支持的动画工具比较少，导入到Unity里面运行时UI才能看到，不够直观并且无法修改，运行时的UI目录结构会跟在UI编辑器里面的目录结构不一致。
优点可能也是缺点，缺点也可能是优点，对于拼UI的工作，由于提供了UI编辑器，完全可以由专门的美术来完成UI的拼接，但是沟通成本可能会比较大，因为涉及到功能编写，UI编辑器里面的节点命名和层次结构就需要程序和美术提前约定好。而由于在运行时才会有UI，程序猿在编写UI逻辑时不需要关心到底UI长什么样，只需要写逻辑即可，能够强制实现分层（UI层与逻辑层），方便日后做热更新。
关于FairyGUI与NGUI使用相信大家已经有了一个初步的了解，不足之处，大家可以尽情发表自己的看法。来自：https://blog.csdn.net/andyqingliu/article/details/54706298