這是第124篇UWA技術知識分享的推送。今天我們繼續為大家精選了若干和開發、優化相關的問題，建議閱讀時間10分鐘，認真讀完必有收穫。
UWA 問答社區：answer.uwa4d.com
UWA （僅限技術交流）
渲染
Q：我們的扭曲效果使用了GrabPass，在PC平臺和iOS都正常，但是Android平臺在不開Bloom的情況下會顯示錯誤，本來是一個很透明的面片，變成了透明度比較低的白片，調試整個Shader之後懷疑是顏色空間的問題，切換回Gamma空間後顯示正常。求教下有人遇到過這個問題麼，附Shader代碼。
附註：frag最後強制轉線性空間後接近正常 return pow(tex2D(_GrabTexture, sceneUVs), 2.2);
UWA：根據題主提供的代碼，我們在紅米4X上復現了該問題。的確如題主所預判，跟機型有關，加上pow(color, 2.2)之後看起來似乎正常了。
查閱了相關的官方文檔，看到有類似的Bug反饋，這裡顯示了GLCore修了，估計GLES沒有修。
https://issuetracker.unity3d.com/issues/grabpass-matrial-with-grabpass-shader-renders-much-brighter-on-opengl-in-linear
同時，我們又在Unity 2018版本上用紅米4X做了測試，發現該問題已解決。建議題主可以嘗試用Unity 2018試試。
該回答由UWA提供，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5b6bc0f8339d267d357c6d30
OpenGL
Q：關於Unity中Graphics API的選擇，我曾在UWA問答上看過相關的帖子，但還是有幾個相關的疑問：
1）像Android，選擇裡面只有ES2.0和3.0選項，那像上圖那樣把兩者都選了，和勾選Auto有什麼區別呢？是不是都是優先ES3.0，然後不行的話就退到ES2.0？
2）康來有說ES2.0的效果會比3.0的效果差一些，我自己改的Unity PBR Shader也遇到2.0的效果比3.0的效果差的情況，抓幀發現是手機上實際的Shader編譯版本不一樣，想問下同樣的Shader（假設都走同樣的分支，不因為不同宏定義走不一樣的代碼），兩者編譯出來還會有這麼大的表現差異嗎?
3）關於效率上，Graphics API的選擇是只影響GPU方面的效率，不會影響CPU上的效率吧？
A：學渲染的小彩筆過來拋個破磚引塊美玉。
第一個問題，題主的理解是正確的，都是優先ES3.0 然後2.0的。
針對題主的第二個問題：ES3.0引入了新版本的GLSL Shading Language，所以編出來的東西肯定不一樣。
另外ES2.0和ES3.0不僅代表了API的變化，也代表了硬體能力的提升。別的不說，ES3.0完全支持了32位浮點數運算，光是這個就足夠帶來效果上的明顯差異。另外，ES2.0要求Depth Buffer至少16Bits，而ES3.0要求支持24Bits和32Bits。
關於第三個問題，因為API的變換，CPU的效率必然會變化，例如VAO，ES3.0支持而ES2.0不支持。
參考文獻：https://www.khronos.org/registry/OpenGL/specs/es/2.0/es_cm_spec_2.0.pdfhttps://www.khronos.org/registry/OpenGL/specs/es/3.0/es_spec_3.0.pdfhttp://www.openglsuperbible.com/2013/12/09/vertex-array-performance
感謝凱奧斯@UWA問答社區提供回答，歡迎大家轉至社區進一步交流：
https://answer.uwa4d.com/question/5b6e3d581e88b37d34e652a1
資源管理
Q：如何生成被4整除的NPOT圖集？如何選擇一個好的圖集劃分策略？我們紋理壓縮格式選擇的是ETC2(Android) + ASTC(iOS)，所以只需要圖片尺寸被4整除就行了。
現在圖集用的是UGUI自帶的SpritePacker，生成的圖集尺寸默認是POT，會導致部分圖集塞不滿，空白區域較多，而美術人工調整圖集歸屬是很麻煩的事，所以希望讓它生成NPOT+被4整除的圖集，這樣圖集歸屬可以隨便弄，空白都不會很多。但看了下自定義圖集打包策略的文檔，似乎沒有相關的接口開放。
TexturePacker也只能提供被2整除的NPOT圖集，所以問問有沒有同學實現過類似的系統，給個思路。
另外，再問幾個問題：
1）項目中存在不同紋理壓縮格式會導致（較大的）性能損失嗎？ 比如「全部ETC2"和「儘量優先ETC1，不行再ETC2」這兩種做法。
2）NPOT現代的實現(比如OpenGLES的NPOT擴展），應該不是自動擴展到POT這種方式吧？ 如果是這種方式，NPOT的內存佔用就是個坑。
3）NPOT的性能和POT比如何？ 能確定的是POT肯定不會比NPOT差，但兩者的性能差距Google有一大堆不同的說法。所以這裡的問題是在現代（移動）GPU上，需要考慮NPOT和POT的性能差距問題嗎？
4）我們之前傾向於照顧美術的習慣，可以的話儘量少約束，所以圖集劃分上希望做到「美術完全不知情不參與」，這樣就會帶來圖集塞不滿的情況。圖集劃分這一塊大家通常是怎麼做的？怎樣在「圖集劃分完美」和「開發\維護成本高昂」之間找一個比較好的平衡？我們主要考慮的還是減少工作成本：別花太多時間在這個上面，然後能保證一個還不錯的效果就行，不需要完美。
A：說一下我們項目的圖集策略，僅供參考：1）只允許方圖；2）保證2的n次冪（解決整除4的問題）；3）格式同樓主，但是不同意ETC1和2混用，明顯ETC2壓縮質量好，速度快；4）保證ICON和圖片的名稱確定和規範化，美術不用關心圖集，由策劃來規劃並進行配表，即使圖集有改動，只需要修改配表的圖集名稱即可；5）圖集的規劃分為公共和系統圖集，但是相關的UI界面都會有圖集的引用索引列表，以此來限制美術及策劃的使用範圍；6）做項目是一個三方制約的環境，給太多的自由，勢必會增加工作和溝通成本，對美術設計進行系統規範的設計是必不可少的。
感謝鄭驍@UWA問答社區提供回答
A：我們目前也是ETC(Android) + ASTC(iOS)，但是要求還是POT的，只是開放了非方形的貼圖尺寸用於合併的二方連續貼圖。UI部分是要求UI使用TexturePacker合併之後的Atlas提交上來，必須是POT的。
關於題主具體的問題，TexturePacker貌似是有編寫插件的方法？不知道是否可以通過插件限定導出尺寸是4的倍數，來滿足你的需求。
照顧美術的習慣是一個好程序的表現，給題主點讚，但是要注意這部分照顧的成本不要轉嫁到性能或者其他職位的身上，否則不如教一下美術，讓美術按照規則來製作。
感謝賈偉昊@UWA問答社區提供回答
A：關於NPOT，可以參考官方文檔：
https://docs.unity3d.com/Manual/ImportingTextures.html
關於補充的第二點：https://answer.uwa4d.com/question/5b4422bbf91024518ab77aed
另外樓主非要用NPOT的圖集，當然也沒人攔得住你，下面有一個JS寫的Pack算法：https://github.com/jakesgordon/bin-packing
感謝凱奧斯@UWA問答社區提供回答
歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5b67bea7339d267d357c6cd8
動畫
Q：我使用Mecanim將模型導入到Unity時，提示「** has translation animation that will be discarded「以及」**has sacle animation that will be dscarded」，即某些關節的Scale/Translate動畫被丟棄，但是有一部分動畫卻能正常播放。所以，Mecanim到底是否支持Scale/Translate動畫呢？
UWA：Mecanim的Humanoid模式是不支持Scale/Translate動畫的，如果Scale/Translate動畫是必要的，可以切換到Generic模式。另外，部分關節的Scale/Translate動畫能正常工作，應該是因為這些關節是非Humanoid關聯的（以Generic模式運行的關節）。
該回答由UWA提供，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5b71086c1e88b37d34e652b4
邏輯代碼
Q：PropertyInfo的CanWrite = false，如果這個屬性是個List，只能讀不能寫，要怎麼給這個List賦值呢？PropertyInfo.SetValue不行，因為這個屬性不能寫入，現在想通過List的Add方法添加值，不知道怎麼做好，希望大家能給些建議。
A：題主可以嘗試用PropertyInfo.GetValue傳入對象，返回值用as關鍵字轉換成List，接著調用Add。(PropertyInfo.GetValue(obj) as List).Add(xxx)。不過這樣可能會有問題：如果這個List是每次new出來的，那麼依然無法修改對象內部變量。
感謝凱奧斯@UWA問答社區提供回答，歡迎大家轉至社區進一步交流：
https://answer.uwa4d.com/question/5b6a47591e88b37d34e65258
今天的分享就到這裡。當然，生有涯而知無涯。在漫漫的開發周期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網站上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之「石」，也能攻你之「玉」。
官方技術博客：blog.uwa4d.com官方問答社區：answer.uwa4d.com官方技術（僅限技術交流）
封面圖片來自網絡
UWA GOT (Online) 內測中
構建高質量的管理流水線，讓每一次測試更有意義！
近期精彩回顧基於屏幕空間渲染的液體模擬 【虛幻引擎學習之路】基於Unreal引擎的大地形加載研究【萬象更新】看完性能簡報，想不優化好都難！UWA問答：用心解決「你」的每一個問題！