https://blog.csdn.net/liuhangang/article/details/79522103
之前刚来现在这个项目的时候，我就跟我们的主程提过使用FGUI去替代UGUI的事情。 原因有以下：
可以让策划与美术参与到UI的制作中， 并且贯穿整个游戏开发的全程。 对于游戏项目来说，UI开发是必不可少且十分费时间的一件事情，而且在一个功能模块在完成之后， 逻辑的大改的次数可能不是特别多， 但是UI大改的次数， 我觉得至少都得3次以上。 至少我到现在，没有遇到那个游戏项目的UI的改版是在3次以下。 所以让UI的制作能脱离程序环节是必不可少的。
上面一点说到UI脱离程序环节的的重要性，可能会有童鞋说，UGUI 和NGUI也可以让策划参与制作啊， 也能让程序不脱离拼UI的苦逼境界。 确实，这点我无法反驳。 但是我可以用实际的例子举例， 我的第二个游戏项目就是使用的Unity， 而且UI是用的UGUI， 那个时候我们使用的Unity的版本是4.6. 我们的UI的制作是全部由策划去拼的，程序不用参与UI制作当中，确实节省了程序大量的时间，但是或多或少还是有一些缺点。说说策划参与UGUI制作我遇到的问题:
但是因为UGUI的节点是由父子关系的， 而且程序在写逻辑代码的时候大概率会依赖于这个UI结构。所以需要策划先去学习Unity的UGUI的层级的概念， 而且还有一些复杂的结构，所以一般情况在策划制作完成UI之后，程序可能都需要简单的修改修改，而且策划同时还要管理Unity的UI的UI的合理规划，所以对于策划来说技术门槛有点高。
当进行UI修改的时候， 难免会修改到UI的层级路径， 因为我们是项目纯lua开发。所以UI逻辑也是lua依靠find写的。所以一旦策划修改层级路径之后，就会出现运行不了的Bug。
UGUI的DrawCall的合并依赖于UGUI层级的规划，层级规划的好与不好的情况，一个复杂的UI界面的Drawcall应该会多10-20个。
UGUI的重绘也是依赖UGUI的Canvas， 即每次重绘都是整个Canvas一起重绘。所以需要对UI的设计有较好的规划，比如一个复杂的界面是一个单独的Canvas，这样在UI重绘的时候，不会引起其它的界面重绘，但这个与项目是怎么显示和隐藏界面的方法有很大的关系，这里就不展开了。
FGUI是仿照Adobe系列制作的UI以及功能设计，同时也是所见即所得的方式，而且还能够编辑器进行简单的测试。能够很方便的使美术参与到游戏UI的设计修改中， 不仅仅是策划参与，也给予了美术足够高的参与度。这是UGUI不能提供的一个很便利的方式，因为UI美术基本是不可能去学或者说学不会Unity的操作，而且流程确实过于复杂。
FGUI的资源管理很方便，美术只要自己规划的好， 就不会出现资源重复，或者找不到等等问题， 因为编辑器是怎么放置资源，怎么引用资源，公有资源放在哪里，独有资源放哪里，在编辑器中都是一目了然。都很方便，还有其它很多比较方便的功能，需要大家自己去体验和学习。
还有一个很重要的原因，也是我个人坚决想要推行FGUI的原因。 就是针对于初级开发者来说， 做UI这个活是又脏又累，而且还学不到太多东西， 花的也很多。 但是你说你不做呢， 有不太可能， 因为游戏项目，UI的开发比重其实占比是很大的。最后还是勉为其难的做下去，导致个人觉得自己在干了1-2年之后技术实力还是没有什么提高，最后对UI开发又了很强的抵触心理。 我自己开发UI的时间不长， 除了第一家公司的时候， 全公司基本就我一个写UI， 而且是使用Cocos2dx用C++手写UI之后，就基本没有再写过什么UI模块了， 一般是开发底层框架和开发工具居多。但是这样的事情我看的很多，又很多感受。 我觉得做一个leader，一定要考虑下面兄弟们的感受， 要让有自己在公司工作技术能有所精进， 合理安排工作。
