運用Post Processing致使幀率明顯降低

1）運用Post Processing致使幀率明顯降低
​2）RectMask2D是否是會頻繁觸發SendWillRenderCanvases
3）Unity3D Sence爲什麼一直處於已修改狀態
4）Sprite Atlas打Bundle的冗餘問題
5）IL2CPP在Xcode下增量編譯問題

---

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

UWA 問答社區：answer.uwa4d.com
UWA QQ羣2：793972859（原羣已滿員）

Rendering

Q：項目中運用了Post Processing後，幀率降低巨大。測試場景，模型面數2w，普通的Diffuse材質 ，沒有物理，沒有特效。沒開後處理時，低端機30幀。開啓後處理，幀率抖動，最低達到15幀。後面只用到Bloom和Color Grading。

A：若是Bloom用的很差，GPU性能耗時高是較爲正常的事情。Bloom的上下采樣次數、Filter濾波的Sample點個數、屏幕的分辨率等都是影響Bloom性能的重要因素。

建議題主能夠考慮閱讀《Unity引擎景深實現原理剖析與優化》這篇技術課程，裏面優化DOF的方法依然能夠用到Bloom上。

同時，也可使用GOT Online中的Overview模式，直接查看項目在真機上（最好是高通芯片）的GPU耗時，看看GPU的具體超標狀況：

該回答由UWA提供

---

UGUI

Q：RectMask2D是否是會頻繁觸發SendWillRenderCanvases？

A：是的，Rect Mask 2D會持續每幀計算子節點的裁剪區域。因此Rect Mask 2D下面的元素若是比較多，耗時仍是挺高的，這種狀況能夠換成Mask組件，雖然Mask的Overdraw會高一些。一個省GPU，一個省CPU，兩個是須要權衡的。

感謝Xuan@UWA問答社區提供了回答

---

Editor

Q：Unity 3D Sence一直處於已修改狀態。剛切換過來也直接提示已修改。切換Sence並未做出任何修改，以下圖：

雖然沒什麼難題，但切換別的場景或者退出的時候就要提示讓保存了。

以前發現的一個緣由是由於UI中存在套用的Layout組件呈警告狀態。修改後Sence就恢復正常了。各位有遇到過這種問題嗎？

A：因此說仍是嵌套了Layout組件。這個會致使Sence一直處於修改狀態。

感謝劉旭傑@UWA問答社區提供了回答

---

AssetBundle

Q：遊戲中UI用Sprite Atlas作合圖，打Bundle貌似碰到了一個冗餘問題：（Unity 2019.4.1 lts版本）。

Victory目錄有四張散圖，以及一個Sprite Atlas文件作合圖。Bundle時把整個Victory爲一個Bundle。最終出來的Bundle結構以下：

也在網上搜了一些信息，嘗試去掉Sprite Atlas的Include in build選項（效果未驗證，純粹驗證Bundle），Bundle中少了一份冗餘的Texture 2D，但依舊有幾個Sprite類型的散圖。

疑問：
我理解是，Bundle中已經有一個sactx-1024x2048的合圖了，爲何還有Sprite類型的散圖？這是否算冗餘呢？

用去掉Include in build的方式，遊戲中使用UI Prefab時，是否都須要用Late Binding才能使用圖片（感受很麻煩，UI拼每一個界面，都要程序寫配套代碼）？

A1：最開始描述的問題中（根據第一張截圖）並未看到冗餘的存在，也並不是圖集形式的打包結果。

回答以下：
對於圖集自己的Bundle確定是不算的，須要有各個散圖的信息才能從整圖中獲取散圖，否則就不知道你要的那個圖在哪裏。

不勾選Include in build，Bundle中就不會存在顯式的圖集依賴，必須使用延遲綁定傳遞信息（該圖片從哪一個圖集中獲取）給請求圖片資源的對象。

感謝Welkin_Totoro@UWA問答社區提供了回答

A2：描述下個人思路：

勾選了Include in build，Bundle中就會有一份冗餘：既包含合圖，又包含散圖。但這種狀況下，程序不須要作特殊邏輯，界面就能表現正常（具體Runtime是否合圖，未抓幀驗證）。

不勾選Include in build（正確作法）：Bundle就會只包含Atlas，以及散圖信息（不是完整的散圖）。遊戲內使用Atlas Request Manager來確保圖片能正常顯示，不然會錯亂。若是本身實現了資源加載的話，可能還要本身找時機作Atlas資源卸載。

感謝james@UWA問答社區提供了回答

---

Build

Q：最近在研究加速打包問題，發現IL2CPP生成代碼以後每次Xcode都是全量編譯（直接Build而不是Clean+Archive）。

我參考這裏看了下，
https://forum.unity.com/threa...，
對比了下若是C#代碼沒有變化，生成的CPP代碼的內容確實不變。可是從新生成貌似會致使文件修改時間變化或別的屬性變化，Xcode依然是全部都編譯了一遍。

A1：目前準備用羣裏大佬說的方法繞開：
「Freshair 17:01:28 打出的Xcode用SVN同步到Xcode打包項目下」

我用Dnspy看了下IL2CPP.exe直接修改代價有點大，並且很差維護。用BeyondCompare比較了下發現其實就Preprocessor.h和Native文件夾倆修改時間產生了變化。但願之後官方能注意這些細節。

感謝錢康來@UWA問答社區提供了回答

A2：介紹一篇文章 《Unity Xcode構建緩存》，裏面寫了一個程序解決Unity生成Xcode項目緩存問題。

WriteCache使用Rsync增量傳輸，會節省時間，ReadCache未作優化，實測用時37秒左右，1.5GiB大小Xcode項目——UnityXcodeCache

感謝狂飆@UWA問答社區提供了回答

A3：我以前的作法是細化打包策略，資源打包細分爲差很少10個步驟，對 UI，特效，Lua（分三塊，Core，模塊，Luatable配置），C#層Config，角色，場景，編譯工程，資源覆蓋，快速編譯，生成APK/IPA，雲真機測試，組織成不一樣的打包命令提供給CI。

若是是C#代碼沒變化，能夠只作資源類的打包，對須要從新（此處可增量）打包的AssetBundle，Lua，Config等打包，打包後直接覆蓋到Xcode工程，直接生成IPA包，跳過中間環節，構建過程能夠細化到很細，若是你是Lua側，那估計只須要打包Lua模塊相關，1分鐘內就能夠出到IPA包。

若是是Xcode代碼也發生變化，這個能夠結合Ccache進行提速，資源打包能夠作分佈式打包，多臺黑蘋果去打包各個模塊的資源。再傳遞到版本機上整合，這個過程也能夠hook svn/git的資源提交，在提交後作一次打包，再次發佈的時候能夠增量處理。

其實能夠脫離AssetBundle，把量產資源採用非AssetBundle的方式進行組織。避開沒必要要的導入導出及打包。

感謝debugger@UWA問答社區提供了回答

封面圖來源於網絡

---

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

官方技術QQ羣：793972859（原羣已滿員）