一直在做Unity方面的遊戲開發，經同事介紹了解到有這麽一個GUI能提供跨平臺的能力，有獨立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對比