Unity專案中UI美術必須知道的程式要點
原文地址:http://youxiputao.com/articles/4820
本文轉載自IndieACE(遊戲葡萄)，是開發者DonaldW寫給UI美術同事的一篇文章，原文題為《Unity專案中UI同學需知的程式相關要點》，分享給大家，希望促程序序和美術之間的相互理解。
背景和目的
本文的背景是《獨立防線》（Killer）專案已進行到了一定階段。雖然之前定下了UI製作規範，但中途也更新了規範，但程式和美術沒有具體面對面溝通，也沒有闡述規範的原因和落地方法。
所以，本文目的是為UI美術同事介紹：1.手遊效能相關的標準是什麼；2.具體制作時需要注意什麼；3.什麼樣的UI流程是高效的。
注，以下內容並非要求UI美術同學都掌握、或者要求UI美術單獨去處理。而是希望UI美術同學能知道有這些一回事需要考慮。最重要的是：在設計之初，能意識到可能有問題，需要找程式去溝通。
體驗和效能
極端的體驗和極端的效能都不現實。在手遊平臺上，我們應該追求的是體驗和效能平衡。
效能評估標準
遊戲中，任一元素（UI圖片、特效、模型等）對效能的影響都可以拆分為以下4種影響：CPU消耗、GPU消耗、外存消耗和記憶體消耗。
現就UI相關的影響進行舉例如下。
CPU消耗
CPU負責把UI介面的邏輯結構進行更新、彙總，並負責把這些資料準備好。最後把這些資訊傳給GPU。
UI一般影響CPU的因素包括：
-
介面結構複雜度
-
介面結構變化頻率
-
動畫複雜度
GPU消耗
GPU負責最終畫面的繪製、渲染。因為渲染是複雜的流程、且運算量巨大、且手機GPU固有的硬體限制（核心數少、浮點運算速度慢），手遊的效能瓶頸往往都發生在GPU。
也就是說，GPU消耗是效能優化的重中之重。
UI一般影響GPU的因素包括：
-
繪製次數（drawcall），和單張圖片的數量等因素相關
-
圖片最終在螢幕所展現的面積
-
圖片是否透明
-
shader的複雜度
-
重繪度（overrdraw，單位畫素的重新繪製次數）
其中，特別值得注意的是drawcall和重繪複雜度。
drawcall
每一個不同“材質”的東西都需要佔用一個drawcall。每多一個drawcall必然帶來額外的CPU消耗和GPU消耗。
可以簡單認為，當兩個東西的材質的shader相同，且紋理相同，則它們是同一個材質，在渲染它們的時候，引擎會進行優化，會合並drawcall為1個。
overdraw
overdraw表示單位畫素的重新繪製次數。
右部表示overdraw的程度，越“亮”的區域表示overdraw的程度越高，也就越消耗GPU。
外存消耗
外存消耗指的是資源在使用者“硬盤裡佔用了多少多少M”。
如果外存過大，可能導致使用者不願意下載，或者下載安裝後，硬碟空間不夠，安裝不成功。
一般影響外存的因素包括：
-
圖片數目
-
圖片的解析度大小
-
圖片是否壓縮
另外，優化了外存，記憶體往往也會從中受益。
記憶體消耗
記憶體消耗指的是“遊戲在實際執行時，佔用多少M”。
如果記憶體過大，可能會導致使用者遊戲體驗不流暢，甚至crash。
一般影響記憶體的因素包括：
-
圖片數目
-
圖片的解析度大小
-
圖片的解析度是否是2的N次方，
-
圖片是否壓縮
UI製作要點
UI輸出的圖片，可在Unity裡設定為新的等比縮放解析度。
正因如此，UI美術同學在輸出UI貼圖時，一般情況下按美術示意圖的原解析度輸出即可。
單獨調解析度的工作，目前是由開發同學進行。最理想的工作流程，是UI美術同學在導圖到Unity的時候，就單獨按需設定解析度（和特效場景模型同學的工作流程一樣）。
至於什麼情況下需要進行降解析度操作，見下文。
低頻變化的圖片的解析度可以很小
本方法能為GPU、外存、記憶體帶來好處
低頻變化的圖片指的是純色的、漸變等變化比較平緩的圖片。
低頻變化的圖片拉伸後仍能表現非常類似的效果，這是因為GPU在圖片取樣時會進行相鄰畫素的插值，從而能大概還原之前的平滑度。
總而言之，低頻變化的圖片的解析度可以很小。
例項如下。
低頻變化圖片：
低頻變化圖片：輸出給程式的圖片縮小為32x32：
低頻變化圖片：程式在使用時將32x32拉伸為512x512：
“好”的UI可以拉起“不好的”UI的表現
本方法能為GPU、外存、記憶體帶來好處
“好”的UI可以拉起“不好的”UI的表現這句話可以有以下的理解：
-
不壓縮的UI可以拉起壓縮的UI表現
-
高解析度的UI可以拉起低解析度的UI表現
-
高頻率變化的UI可以拉起低頻率變化的UI表現
如上圖的放射線部分，它實際是由兩張不同的放射線圖上下疊加而成。下層的放射線順時針轉動，上層的放射線逆時針轉動。
由於上層的放射線作為表現的主體所以採取了“好”的設定（解析度高、非壓縮），那麼作為表現的襯托部分的下層圖，就算採用比較“不好”的設定（解析度低，壓縮），也不容易察覺。
所以，針對這種多UI同時或同位置出現的情況，可以酌情調低某些UI的設定。
當然，這個例子中，上下兩層採取同一張高品質的圖也是解決方案之一。
輸出圖片的解析度可以酌情低於視網膜的解析度
本方法能為GPU、外存、記憶體帶來好處
從iPhone4開始興起了視網膜級別的PPI。這讓手機的任意App的任意介面的任意一幀，都看不出任何畫素感，提高了App的使用者體驗。
但在遊戲中，遊戲有以下特點：
-
遊戲的UI資源是獨立原創的（App的UI資源有可能直接使用作業系統自帶的資源，節省外存），會帶來非常客觀的外存、記憶體消耗
-
遊戲是動態的
-
遊戲的一幀內，最吸引玩家眼前的往往是一個區域性
-
再根據上面提到的“好”的UI可以拉起“不好的”UI的表現
所以在遊戲中，可以酌情將特定非重點的UI圖片的解析度降低。
遊戲中具體處理的例子：表現的主體是視網膜解析度的，而它下面的彈出框背景作為表現襯托，採取了低於視網膜解析度也察覺不出。
去除UI圖片中不必要的通道、不必要的區域
本方法能為GPU、外存、記憶體帶來好處
如上圖。地球UI圖片是沒必要有透明通道的，因為它一直以整張底圖的形式存在於遊戲。
地圖UI圖右部是可以斟酌是否需要存在的，因為它在遊戲中一直都被帶有背景的排名列表UI擋住。
UI圖片一般情況下都不需要mipmap
本方法能為外存、記憶體帶來好處
mipmap會生成多張小圖來避免縮小圖片時沒必要的GPU取樣消耗。但使用mipmap的圖片會比不使用的圖片多佔用約三分之一的外存和記憶體。
由於《獨立防線》專案以iPhone4作為目標解析度進行製作，且認為此解析度是需支援的最小解析度，也就是說，UI圖片很少有縮小的情況出現，所以《獨立防線》專案的UI圖片都不需要mipmap，減少沒必要的外存、記憶體消耗。
其他專案如果需相容更低解析度的裝置，則要按需選擇mipmap。
多張UI圖片可以打包在一起
本方法能為GPU帶來極大好處，但可能為外存、記憶體帶來壞處
操作很簡單，選擇需要打包的圖了之後，在屬性面板裡鍵入任意同一英文字串即可。
這樣了之後，多張圖被打包在一張圖裡面。
由於多張圖片打包在了一起，根據上面提過的合併drawcall的原因，會大幅減少這些圖片帶來的GPU消耗。
打包之後，會產生多餘的透明區域，所以打包可能帶來的壞處就是增大了外存、記憶體。
所以，關鍵是選擇哪些圖片進行打包。來規避透明區域的出現。選擇規則如下：
-
不用的圖不打包。因為打包的圖，就算從不使用，也還是會進入到最終的ipa或者apk裡；
-
小的圖儘可能打包
-
大圖（比如大於512x512，常見的有UI底圖）不打包。因為大圖會很有可能產生透明區域；
-
降低需要打包中的解析度最大的圖。
不打包的單張UI圖片解析度必須是偶數、很有可能需要是2的N次冪
本方法能為GPU、外存、記憶體帶來好處
按照上面的多張UI圖片可以打包在一起做了之後，不打包的圖應該是少量的。
但由於這些圖是獨立存在於記憶體，所以有更嚴格的要求：
-
單張UI圖片解析度必須是偶數。
-
單張UI圖片當有以下任一特點時，解析度必須是2的N次冪
-
需壓縮的單張UI圖片。
-
需tiled的單張UI圖片。tiled即圖片平鋪，常用於四方連續UI圖。
-
需mipmap的單張UI圖片。即多層圖片。一般情況下，UI的圖片都不需mipmap，所以不用考慮這個。
-
@程式同學：現在大部分移動裝置GPU是支援非2的N次方的。即NPOTSupport.Full或者Restricted的。Full的GPU對任意解析度的紋理都能直接訪問；Restricted的GPU，一般情況下對任意解析度的紋理都能訪問，但對於mipmap、tiled的紋理會把它pad成POT。
所以，mipmap、或tiled的非打包單張紋理需強制POT。
筆者身邊的紅米、三星、華為等手機，都支援NPOTSupport.Full，只發現小米3支援NPOTSupport.Restricted，小米3W支援NPOTSupport.Full。
@程式同學：ETC1（4bit/pixel）成功壓縮的要求是POT且不帶透明通道，否則將以16bit/pixel的方式壓縮儲存；PVRTC成功壓縮的要求是POT且方形，否則將以true color（32bit/pixel）不壓縮儲存。常用的方案是，把UI圖片打包到一張大圖，且大圖同時滿足ETC1和PVRTC的要求，即POT、且透明通道拆分到大圖的下半部、且方形。
這需要有特殊的shader對這張大圖進行取樣：RGB取原本uv、A取uv向下偏移0.5。下半部的Alpha部分可以把Alpha值除以3平均分部到RGB通道，取樣時把RGB相加作為Alpha，這樣有利於ETC1壓縮的效果。
因大圖的製作需要上半部是UI圖片的RGB部分、下半部是UI圖片的Alpha部分。所以需要自研或獲取適合的atlas演算法對UI圖片進行排版。此時上面提到的Unity自帶的Sprite Packer方法將不再適用。
排版後的大圖的可容忍浪費解析度是原圖的16bit/4bit=4倍，或32bit/4bit=8倍。
打包的UI圖片的解析度可以是任意的
但依然推薦輸出偶數解析度，避免未來帶來不可知的麻煩。
UI最好能用九宮格+區域性裝飾實現
本方法能為GPU、外存、記憶體帶來好處
九宮格已經是非常常用的UI製作方法。
九宮格UI幾乎是百利無一害，所以希望UI同學能用九宮格的儘量用九宮格。
使用九宮格有以下幾個值得注意的技巧：
-
九宮格UI圖片可以做得很小隻給正方形的圖，而並非上面一個長條形的圖
-
如果UI圖片內部是低頻變化（人話：比較平滑的紋理），依然可以使用九宮格
-
如果UI圖片內部是高頻變化（人話：比較細的複雜紋理），一般情況下就不能使用九宮格了
-
但可以把這些高頻變化的紋理設計成只在邊緣出現，讓九宮格十字架內依然是低頻變化，那這種UI圖依然可以九宮格
-
-
切九宮格時，邊緣部分應儘量細、內部十字架部分應該儘量飽滿。這樣可以確保這個UI能夠使用於非常小的場合而不穿幫
字型選擇方案
本方法能為外存、記憶體帶來好處，可能為GPU帶來好處
在選擇遊戲字型的時候，除了確保美觀程度之外，還需考慮：
-
字型種類：應當保持在2類以內：用於標題的中文偏設計的字型、用於正文的中文偏正式的字型。如需，可額外加入英文偏設計的字型；
-
字型編碼型別：如果是中文字型，需考慮是否GB2312編碼甚至是GBK編碼。避免字型出現有些常用中文字沒有的情況；
-
在選擇字型時，應留意在手機上的表現。比如一些字型比較細，在手機上看不清，到後面需要都加粗加描邊，帶來沒必要的消耗，也帶來了之後額外的繁瑣的字型相關工作。