這是第134篇UWA技術知識分享的推送。今天我們繼續為大家精選了若干和開發、優化相關的問題，建議閱讀時間10分鐘，認真讀完必有收穫。

UWA 問答社群：answer.uwa4d.com

UWA QQ群：465082844（僅限技術交流）

UI

Q：我們新專案中想使用下FairyGUI，主要還是為了減輕程式工作量，請問大家有在專案中使用過的嗎？主要是關於圖集、DrawCall優化、一些滾動條的優化和Richtext解析等等，想問下在這些方面FairyGUI有沒有很好的支援呢。另外可以支援自定義UI控制元件麼？有經驗的朋友都可以分享下嗎？

A1：兩個上線產品，一個自家的一個朋友的：

http://www.9game.cn/xxyg/ http://www.9game.cn/mengxiangqiyuan/

主要幾個點： 1）對美術十分友好，各種習慣跟Adobe系列的一致，編輯器本身就是AS3開發的； 2）包裝了一些概念，十分方便拼介面工作；如關聯=>螢幕適配 、控制器=>狀態控制等等； 3）之前的版本解析使用xml，GC較多，最新版本已經更新為二進位制，介面建立的CPU和記憶體消耗都降低了很多，但是還在內部使用，並未應用到線上；這個功能FairyGUI也剛剛釋出不到兩個月； 4）自帶圖集支援Alpha通道分離，在貼圖壓縮和機型相容上可以直接應用到；PS：建議稍微修改原始碼，讓Alpha的貼圖格式為Alpha8，實測這樣的在保證視覺效果的前提下可以把貼圖壓很比較小； 5）各種基本的東西：DrawCall、圖集、各種型別元件等等這些都屬於還不錯的狀態，一般不會遇到什麼支援不了的； 6）講一個除錯缺點，FairyGUI的元件並不是MonoBehaviour型別的，所以在Unity裡面看到的GameObject並不能和元件一一對應，遇到一些奇怪問題的時候需要一定想象力，不能像UGUI或者NGUI簡單直接看到UI的引數； 7）FairyGUI是跨平臺的，會遇到FairyGUI編輯器中預覽的和UnityEditor裡面看到的不一樣的情況，如果對Flash的渲染有一定了解，應該不算什麼障礙，如果沒有相關經驗還是需要踩一點坑的。

感謝袁首京@UWA問答社群提供了回答

A2：作者也來湊湊熱鬧。最大的優勢當然是開發效率，用了FairyGUI的基本都中毒，這種開發模式的效率是其他UI遠遠不能比的，越大的專案優勢越明顯。UI開發有一個很大的特點是重構次數比較多，一旦發生這種情況，通常都會有讓一執行緒序員辭職的念頭，但用FairyGUI的就可以做到雲淡風輕。

大家很關注的效能，我覺得NGUI/UGUI為了降低DrawCall採用的合併Mesh技術對UI製作要求太高，一旦動靜分離不合理會引發災難。FairyGUI提供的優化技術是動態後期優化，在製作時對UI人員基本沒有要求。簡單的說，就是你隨便拼，FairyGUI負責自動優化。兩者的執行效能，你很難感受到差別。但如果UGUI你不優化，就會和FairyGUI有很大差別。所以有一個說法，FairyGUI可以輕鬆應付低端機，但UGUI卻要花大力氣。

GC問題是C#庫不可迴避的話題，FairyGUI也在不停迭代中改進。最近推出的二進位制格式，更是解決了大家一直有意見的載入問題。FairyGUI執行時，如果不發生文字和圖片的更換，是沒有GC的，即使各種動效（位移、透明、旋轉等等）在不停執行。這一點是很難得的，因為一般情況下，你如果要用其他UI實現這些效果，那麼勢必要引入其他外掛或者自己寫大量程式碼，那麼這些程式碼的優化是要你自己完成的。

最後也來說說缺點，首先FairyGUI需要你學習多一個編輯器，瞭解一種不同的開發模式，在FairyGUI目前知名度遠遠不及UGUI的情況下，選擇FairyGUI需要決策者有前瞻性；其次FairyGUI結合UI實際運用的痛點，自帶了很多快取機制，例如遊戲中List總是避免不了不停重新整理，所以FairyGUI的List是自帶Cache的等等，你需要了解一下這些特點，否則會造成FairyGUI有記憶體洩漏的錯覺。

感謝谷主@UWA問答社群提供了回答

該問答來自UWA問答社群，歡迎大家轉至社群交流：

https://answer.uwa4d.com/question/5bd275efa4201c0aa434742a

渲染

Q：我們專案採用了PBR材質，在伽馬顏色空間下PBR中光照計算的結果是錯誤的。所以現在考慮轉到線性空間中。Unity從5.5版本開始支援移動裝置上的線性空間，OpenGL ES3.0的裝置佔比已經足夠高，裝置支援不是問題。

現在的問題是如果直接推行線上性空間製作貼圖對美術的工作習慣挑戰較大，所以想採用線上性空間匯入時勾選sRGB來區分線性和伽馬的方式來處理，想知道這種方式是否有特別需要注意的地方？期待有相關經驗的大佬賜教。

A1：我們之前的專案用了線性空間，新專案肯定也會使用線性空間。前段時間也推薦和協助了朋友的創業團隊從Gamma空間轉到了線性空間。所以，我對於線性空間是強烈推薦的，當然，如果美術團隊中有人有線性空間相關的製作經驗，這樣程式推行起來會更好更快。

題主已經體會到線性空間的好處，這裡就不細說，迴歸到問題本身。按照我對題主描述的理解，題主的想法是為了減少美術對於之前貼圖修改的工作量，想把整個專案切換到線性空間，然後讓之前按照Gamma空間的規範製作的貼圖不勾選sRGB，讓新制作的內容勾選sRGB來做，不知道這樣理解題主的想法是否正確。

說先要明確的是線性空間的工作流程可不僅僅針對於貼圖，貼圖是否是線性的只是其中一小部分，線性空間核心改變的問題是光照疊加的計算。

做一個簡單實驗，在沒有貼圖的情況下，光照強度為1，Cube的顏色為(128, 128, 128)，線上性空間下和Gamma空間下的渲染效果：（Unity 5.6版本，Standard材質） 哪個是線性哪個是伽馬空間？不重要，重要的是兩者是不同的。也就是說單純顏色在兩種空間下，一盞燈的光照效果就有差別，那如何保證美術使用伽馬空間製作的美術效果，線上性空間下是和之前的效果完全一致呢？

我個人覺得是很難。

擷取帶貼圖的例子來看：  

隨意找的一張貼圖，不用在意貼圖內容，對比效果可以發現，他們之間會有差異。那什麼情況下是相同的呢？選擇Unlit材質看下：

說了這麼多是想說明，線性空間的工作流程不僅僅和貼圖格式相關，而且對光照渲染更加有影響。所以，我個人不建議混用兩種色彩空間方式，起碼在一個場景內不建議混用。

當然，對於客戶端來說，沒有說什麼東西是一定“正確”的，混用之後美術覺得效果ok，那也不是說這種方案不能用。但可能會要提前考慮一些問題：

1）後續效果調整可能會有些麻煩，出現顧此失彼的情況；

2）美術製作可能會混亂，因為線性空間和伽馬空間下總是會有各自的製作經驗，比如線性空間下貼圖的製作亮度會普遍偏亮一些等等經驗，混用色彩空間的結果，可能會讓美術也會迷惑，或者新來的美術對於之前資源的維護會存在困擾，不知道應該按照怎樣的經驗來製作。所以如果要這樣做，最好界定好兩種空間分別使用的界限。

3）經驗告訴我們，無論是遊戲開發還是戀愛，長痛不如短痛……

Anyway，雖然我個人不建議這樣做，但畢竟實踐出真知，建議題主在自己專案裡先試試，看看我能夠想到的問題是否都有一個滿意的答案，也許你們可以在色彩空間混用這塊走出一條康莊大道也說不定。

感謝賈偉昊@UWA問答社群提供了回答

A2：Unity工程已經切了線性空間了，就必須是線性圖（比如法線圖、強度圖、引數圖）勾掉sRGB、Gamma圖（比如顏色度）勾sRGB了。 如果你是想用這種方式還原Gamma的處理方式，是不合理的。

感謝李洋洋@UWA問答社群提供了回答

題主：非常感謝賈偉昊和李洋洋的解答。

可能我的表述不清，所以引起了理解偏差。我描述不是原來Gamma空間製作的貼圖不勾選sRGB選項。我的意圖有兩個，一個是之前在Gamma空間做的資源可以儘可能少地進行改動，另一個是後面的美術資源製作如果可以，就是儘可能少改變美術出資源的習慣，當然，沒有好的方法的話美術也得去適應新的工作流。

先解釋下我們轉線性空間的背景，我們在Gamma空間倒騰了一段時間，現在來看，我們一直走在錯誤的道路上，我們確定修改為線性空間就是因為在Gamma顏色空間的效果跟SP裡的出入比較大，美術反饋說很絕望，然後查了些資料發現SP是線上性空間工作，在Gamma空間基本上沒有調出比較一致的可能性，也有人通過修改Shader等進行一些Gamma矯正使美術製作工具和Unity環境中的效果一致，考慮到現在大部分機器已經支援線性空間了，我們就直接切到了線性空間。

之前看了些資料，但主要的關注點都在貼圖上，但是看到偉昊的那句“那個是伽馬空間，那個線性空間，不重要，重要的是兩者是不同的”，這句給我的啟發非常大。確實，至於是Gamma空間還是線性空間確實不重要，而更重要的是儘可能地在美術製作工具裡和引擎環境中保持一致，保證在引擎中的效果儘可能少地打折，以及減少美術同學從美術製作工作匯入引擎的調整時間。

不一致的原因也不復雜，在伽馬顏色空間下，Unity採用放任的方式，就是你給我什麼輸入我就拿什麼計算，到最後裝置顯示的時候做一次伽馬矯正，線性空間的差別是會根據貼圖是否勾選sRGB做一次線性轉換，在最後的輸出階段還是做一次反伽馬矯正，大約就是pow4.5的計算，就是說不管你有沒有貼圖取樣參與計算，線上性空間下最後一步的反伽馬矯正都是要做的，這就是差別的原因。

理解了為什麼不同，剩下的就是考慮美術製作要注意的問題。

在切換到Unity線性空間的情況下，PBR製作需要關注的地方我注意到的有以下方面：

1）就是李洋洋提到的， 線性圖不能勾選sRGB選項，而伽馬圖需要勾選sRGB；

2）切換到線性空間後，想在SP裡的表現和Unity引擎裡完全一致，也基本上不可能，它們有很多的不同之處，比如光照資訊不同，SP裡面是從環境貼圖拿光照，很強，沒有主光源。一些效果在SP內找不到相近的效果，一些演算法實現不同，比如說DRDF，如果希望引擎內和SP內表現一致，還是需要做一些工作，把材質從引擎內移到SP中。

3）和我們美術溝通，發現他們會拿資料圖，比如說粗照度，高光圖等去PS裡處理，如果不注意設定，那麼在SP裡輸出的線性圖，在PS裡逛一圈出來成了伽馬圖了。目前我還沒有清晰的流程來處理這種情況，包括SP裡匯出的貼圖資料通道合併，之前也是拿到PS裡來處理的。這也有問題，可能不知覺間一張線性圖就成伽馬圖了。

4）線性空間的半透圖在PS裡混合的時候，是在伽馬空間混合的，在Unity線性空間的話會線上性空間混合，結果會一致。可以通過設定線性混合，但是就得出線性圖了，目前我們還沒做出規範是否要出線性圖，後面可能採用就是直接出伽馬圖，跟之前出圖習慣一致，然後混合的時候直接在Unity調整到想要的效果。

再次感謝賈偉昊和李洋洋的解答。因為我們剛轉到線性空間，正處於摸索階段，我的理解可能存在偏差，如有理解不對的地方，希望可以幫忙指出來，感激不盡。

感謝趙林@UWA問答社群提供以上分享

該回答來自UWA問答社群，歡迎大家轉至社群交流：

https://answer.uwa4d.com/question/5bd1724fae74300ab0497bed

視訊

Q：我們測試發現，在使用Unity打包的時候可以正常播放，但是在使用Unity命令列進行打包的時候，打包IL2CPP的包在VideoPlayer播放MP4視訊時會出現藍屏，但是有聲音，沒有發現異常，有人遇到過這個問題嗎？

A：adb命令連線手機獲取Android系統Log才發現ReportException: UnityLogError Could not find material Hidden/VideoDecodeAndroid 異常，檢視本地手動的GraphiceSetting發現沒有這個Shader的設定。 但是前臺Unity直接打包IL2CPP就正常，命令列就會有這種異常，手動加上該Shader儲存GrahpicsSettings.asset後進行命令列打包正常。

感謝鬱建秋@UWA問答社群分享了該回答，歡迎大家轉至社群交流：

https://answer.uwa4d.com/question/5bcd9818a4201c0aa43473dd

編輯器

Q：美術同事上傳了許多Prefab之後，我們程式同事開啟Unity工程，Console就立即報出了許多如上圖的錯誤訊息，但是沒有指出是哪些Prefab或Asset造成的，請問各位有遇到這種狀況嗎？該如何定位問題原因呢？我們的unity版本是5.5.4。

A1：由於除數為0造成的問題，可以檢查美術生成的資源，有些資源數值變成的無窮小或者無窮大，這時碰撞盒計算出現錯誤，就會報錯。

感謝鄭驍@UWA問答社群提供了回答

A2：推薦一下Misaka同學的MonoHooker

https://github.com/easy66/MonoHooker

Hook到CreatePreviewForAsset方法上，把引數打印出來。

感謝凱奧斯@UWA問答社群提供了回答

該回答來自UWA問答社群，歡迎大家轉至社群交流：

https://answer.uwa4d.com/question/5bc9e25e8af62a50acb8e12e

今天的分享就到這裡。當然，生有涯而知無涯。在漫漫的開發週期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網站上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之“石”，也能攻你之“玉”。

官網：www.uwa4d.com

官方技術部落格：blog.uwa4d.com

官方問答社群：answer.uwa4d.com

官方技術QQ群：465082844（僅限技術交流）

圖片來自網路