背景和目的

本文的背景是Killer專案已進行到了一定階段。雖然之前定下了UI製作規範，但中途也更新了規範，但程式和美術沒有具體面對面溝通，也沒有闡述規範的原因和落地方法。
所以，本文目的是為UI美術同事介紹：1、手遊效能相關的標準是什麼；2、具體制作時需要注意什麼；3、什麼樣的UI流程是高效的。
注，以下內容並非要求UI美術同學都掌握、或者要求UI美術單獨去處理。而是希望UI美術同學能知道有這些一回事需要考慮。最重要的是：在設計之初，能意識到可能有問題，需要找程式去溝通。

體驗和效能

極端的體驗和極端的效能都不現實。

極端的體驗
極端的效能（從2015年的標準來看）

在手遊平臺上，我們應該追求的是體驗和效能平衡

。

體驗和效能的平衡

效能評估標準

遊戲中，任一元素（UI圖片、特效、模型等）對效能的影響都可以拆分為以下4種影響。

影響效能的4大方面

現就UI相關的影響進行舉例如下。

CPU消耗

CPU負責把UI介面的邏輯結構進行更新、彙總，並負責把這些資料準備好。最後把這些資訊傳給GPU。

UI一般影響CPU的因素包括：

• 介面結構複雜度
• 介面結構變化頻率
• 動畫複雜度

複雜的介面結構

GPU消耗

GPU負責最終畫面的繪製、渲染。因為渲染是複雜的流程、且運算量巨大、且手機GPU固有的硬體限制（核心數少、浮點運算速度慢），手遊的效能瓶頸往往都發生在GPU。
也就是說，GPU消耗是效能優化的重中之重

。
UI一般影響GPU的因素包括：

• 繪製次數（drawcall），和單張圖片的數量等因素相關
• 圖片最終在螢幕所展現的面積
• 圖片是否透明
• shader的複雜度
• 重繪度（overrdraw，單位畫素的重新繪製次數）

其中，特別值得注意的是drawcall和重繪複雜度。

drawcall

每一個不同“材質”的東西都需要佔用一個drawcall。每多一個drawcall必然帶來額外的CPU消耗和GPU消耗。

UI介面的drawcall次數為125次

可以簡單認為，當兩個東西的材質的shader相同，且紋理相同，則它們是同一個材質，在渲染它們的時候，引擎會進行優化，會合併drawcall為1個。

overdraw

overdraw健康的UI介面
overdraw不健康的UI介面

overdraw表示單位畫素的重新繪製次數
右部表示overdraw的程度，越“亮”的區域表示overdraw的程度越高，也就越消耗GPU。

外存消耗

外存消耗指的是資源在使用者“硬盤裡佔用了多少多少M”。
如果外存過大，可能導致使用者不願意下載，或者下載安裝後，硬碟空間不夠，安裝不成功。
一般影響外存的因素包括：

• 圖片數目
• 圖片的解析度大小
• 圖片是否壓縮

另外，優化了外存，記憶體往往也會從中受益。

記憶體消耗

記憶體消耗指的是“遊戲在實際執行時，佔用多少M”。
如果記憶體過大，可能會導致使用者遊戲體驗不流暢，甚至crash。
一般影響記憶體的因素包括：

• 圖片數目
• 圖片的解析度大小
• 圖片的解析度是否是2的N次方，
• 圖片是否壓縮

UI製作要點

UI輸出的圖片，可在Unity裡設定為新的等比縮放解析度

正因如此，UI美術同學在輸出UI貼圖時，一般情況下按美術示意圖的原解析度輸出即可。

輸出圖原本的解析度為788x488

輸出圖在Unity裡被設定為寬高不超過512

單獨調解析度的工作，目前是由開發同學進行。最理想的工作流程，是UI美術同學在導圖到Unity的時候，就單獨按需設定解析度（和特效場景模型同學的工作流程一樣）。
至於什麼情況下需要進行降解析度操作，見下文。

低頻變化的圖片的解析度可以很小

本方法能為GPU、外存、記憶體帶來好處

低頻變化的圖片指的是純色的、漸變等變化比較平緩的圖片。
低頻變化的圖片拉伸後仍能表現非常類似的效果，這是因為GPU在圖片取樣時會進行相鄰畫素的插值，從而能大概還原之前的平滑度。
總而言之，低頻變化的圖片的解析度可以很小。
例項如下。

低頻變化圖片：原圖512x512
低頻變化圖片：輸出給程式的圖片縮小為32x32
低頻變化圖片：程式在使用時將32x32拉伸為512x512

“好”的UI可以拉起“不好的”UI的表現

本方法能為GPU、外存、記憶體帶來好處

“好”的UI可以拉起“不好的”UI的表現

“好”的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擋住。

UI圖片一般情況下都不需要mipmap

本方法能為外存、記憶體帶來好處

mipmap會生成多張小圖來避免縮小圖片時沒必要的取樣消耗

mipmap會生成多張小圖來避免縮小圖片時沒必要的GPU取樣消耗。但使用mipmap的圖片會比不使用的圖片多佔用約三分之一的外存和記憶體。
由於KL專案以iPhone4作為目標解析度進行製作，且認為此解析度是需支援的最小解析度，也就是說，UI圖片很少有縮小的情況出現，所以KL專案的UI圖片都不需要mipmap，減少沒必要的外存、記憶體消耗。
其他專案如果需相容更低解析度的裝置，則要按需選擇mipmap。

多張UI圖片可以打包在一起

本方法能為GPU帶來極大好處，但可能為外存、記憶體帶來壞處

操作很簡單，選擇需要打包的圖了之後，在屬性面板裡鍵入任意同一英文字串（比如這裡的PackUIBattle）就好了。

在Unity多圖打包的方法：在Packing Tag加上英文字串

這樣了之後，多張圖被打包在一張圖裡面。

多張UI圖通過SpritePacker的打包結果

由於多張圖片打包在了一起，根據上面提過的合併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的。Restricted的GPU，對於mipmap、tiled的紋理會把它pad成POT。
然而，ETC、PVRTC壓縮紋理只支援POT的紋理，NPOT的話都不會進行ETC、PVRTC壓縮。
真機實驗得知，NPOT且選擇Compress時，Unity會在安卓上會以16b進行壓縮、在iOS上則truecolor不壓縮。
所以，需壓縮、或mipmap、或tiled的非打包單張紋理需強制POT。
筆者身邊的紅米、三星、華為等手機，都支援NPOTSupport.Full，只發現小米3支援NPOTSupport.Restricted，小米3W支援NPOTSupport.Full。

打包的UI圖片的解析度可以是任意的

但依然推薦輸出偶數解析度，避免未來帶來不可知的麻煩。

UI最好能用九宮格+區域性裝飾實現

本方法能為GPU、外存、記憶體帶來好處

Unity UGUI支援直接使用Sprite Editor直接進行九宮格製作

九宮格已經是非常常用的UI製作方法。
九宮格UI幾乎是百利無一害，所以希望UI同學能用九宮格的儘量用九宮格。
使用九宮格有以下幾個值得注意的技巧：

• 九宮格UI圖片可以做得很小隻給正方形的圖，而並非上面一個長條形的圖
• 如果UI圖片內部是低頻變化（人話：比較平滑的紋理），依然可以使用九宮格
• 如果UI圖片內部是高頻變化（人話：比較細的複雜紋理），一般情況下就不能使用九宮格了
  • 但可以把這些高頻變化的紋理設計成只在邊緣出現，讓九宮格十字架內依然是低頻變化，那這種UI圖依然可以九宮格
• 切九宮格時，邊緣部分應儘量細、內部十字架部分應該儘量飽滿。這樣可以確保這個UI能夠使用於非常小的場合而不穿幫

字型選擇方案

本方法能為外存、記憶體帶來好處，可能為GPU帶來好處

在選擇遊戲字型的時候，除了確保美觀程度之外，還需考慮：

• 字型種類：應當保持在2類以內：用於標題的中文偏設計的字型、用於正文的中文偏正式的字型。如需，可額外加入英文偏設計的字型；
• 字型編碼型別：如果是中文字型，需考慮是否GB2312編碼甚至是GBK編碼。避免字型出現有些常用中文字沒有的情況；
• 在選擇字型時，應留意在手機上的表現。比如一些字型比較細，在手機上看不清，到後面需要都加粗加描邊，帶來沒必要的消耗，也帶來了之後額外的繁瑣的字型相關工作。

由於選擇了細字型，導致在手機上需要都加粗加描邊，帶來沒必要的消耗（比如overdraw）

製作流程

UI同學和程式同學一起維護Unity UI資原始檔夾

當前的工作流程是美術同學輸出了UI圖片後，傳到FTP，通知程式同學具體路徑，程式同學從FTP拷貝資源到UnityUI資原始檔夾，為了版本一致，程式同學可能需要對它進行重新命名，才用上了一張新資源。

Unity UI資原始檔夾裡存放著真正採用到遊戲的資料夾。
這個資料夾事實上已經存在了，但只有程式同學在維護。現在需要UI美術同學、程式同學一起來維護它。
這樣有以下好處：

• Unity的資料夾裡，可以直接存放任意格式的圖片甚至是psd。Unity在構建時才將這些圖片轉為需要用的格式
• 可以直接在Unity看到圖片在手機裡記憶體、外存的真正佔用
• 方便查詢真正在用的UI資源
• 由於這個資料夾的資源是正式且確保資源不重複，所以方便美術同學間協作，防止資訊不對稱制作了重複資源
• 當有UI小幅修改時，美術直接修改即可。而不是走一個美術修改、傳給程式、程式替換的臃腫流程
• 給資源重用落地提供基礎

事實上，我們的特效、場景、模型都已經是這樣做了，一起維護一個真正採用到遊戲的資料夾

資源元件重用

老生常談、不得不談。
資源重用可以節省策劃同學工作量、美術同學工作量、程式同學工作量，節省外存、記憶體，也節省使用者體驗學習成本，。
如果減法百利無一害，何必狂做加法吃力不討好。

Flash專案可重用貼圖的資源庫
Unity專案可重用貼圖的資源庫

一個可以幫助資源重用的思考流程大致是這樣的：

1. UI美術同學如果在接到新UI需求；
2. 先想UI的某個元件能不能用資源庫裡已有UI資源元件來完成；
3. 如果能，則重用，僅僅在Photoshop裡製作示意圖，不輸出該UI元件資源；
4. 如果不能，才設計新UI元件資源；同時，新資源也遵循可重用規則；
5. 新資源歸檔回資源庫；
6. 多次重複1-5步後，資源庫會越來越容易滿足未來的新UI的需求。

適配裝置解析度的UI製作思路

接近16：9的iPhone5（1136
x640）的關卡介面
接近1：1的iPad Retina（2048x1536）的關卡介面

最近新出的手遊為了更好的體驗，都採取了填滿裝置螢幕的解析度適配的UI方案。所以要求策劃同學、UI同學在設計時，就要考慮解析度適配問題。而並不能僅僅瞄準一款熱門裝置比如iPhone5進行設計。

Unity UGUI有很好的UI適配方案。概括描述如下：

矩形的原點都在左下角。
3個重要的矩形：實在存在的父矩形、用於輔助的anchor矩形、實在存在的子矩形（當前矩形）。
父矩形內部包含了anchor矩形和子矩形。

下列圖中，外框表示父矩形、“四葉花瓣尖”組成anchor矩形、藍點表示子矩形。

圖：anchor矩形四角跟父矩形四角一一對應。即歸一化距離（即距離佔父矩形寬或高的比例）固定。對應的兩個角之間就好像用橡皮筋綁起來一樣。比如圖中左上花瓣跟左上角距離總是50%寬、60%高。注意到，圖中anchor矩形四角聚在一起，這樣父矩形大小變化時，anchor矩形大小不會變化。
圖：anchor矩形四角跟父矩形四角一一對應。對應的兩個角之間的歸一化距離（即距離佔父矩形寬或高的比例）固定。對應的兩個角之間就好像用橡皮筋綁起來一樣。比如圖中左上花瓣跟左上角距離總是10%寬、50%高。注意到，圖中anchor矩形四角各自分開，這樣父矩形大小變化時，anchor矩形大小也會變化。
圖：子矩形四角跟anchor矩形四角一一對應。對應的兩個角之間的距離固定。對應的兩個角之間就好像用鐵棒鎖起來一樣。比如圖中左上藍點跟左上花瓣的距離總是80畫素寬、30畫素高。注意到，圖中anchor矩形四角聚在一起，這樣父矩形大小變化時，由於anchor矩形大小不會變化，所以子矩形大小不會變化。
圖：子矩形四角跟anchor矩形四角一一對應。對應的兩個角之間的距離固定。對應的兩個角之間就好像用鐵棒鎖起來一樣。比如圖中左上藍點跟左上花瓣的距離總是40畫素寬、20畫素高。注意到，圖中anchor矩形四角各自分開，這樣父矩形大小變化時，由於anchor矩形大小也會變化，所以子矩形大小也會變化。

總之，anchor矩形四角跟父矩形四角一一對應，對應的兩個角之間的歸一化距離（即距離佔父矩形寬或高的比例）固定；子矩形四角跟anchor矩形四角一一對應。對應的兩個角之間的距離固定。

通過這樣的關係，就可以實現各種不同的適配方案。比如以下這些。

當四花瓣聚在一起時，父矩形改變大小，子矩形大小不會改變。位置會鎖定在歸一化距離。

橫向縱向皆不拉伸

當四花瓣格子橫向分開時，父矩形改變大小，子矩形橫向大小會相應改變。

橫向拉伸、縱向不拉伸

當四花瓣格子橫向縱向皆分開時，父矩形改變大小，子矩形橫向縱向大小皆會相應改變。

相關推薦