關於Addressable打包大小的疑問

1）關於Addressable打包大小的疑問
2）華爲機型上人物模型鋸齒嚴重問題
3）Unity 2019圖片壓縮格式選擇
4）Splash用到的紋理常駐內存
5）新版TileMap的重疊面渲染問題

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

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

Addressable

Q：如何得到Addressable打出的AssetBundle的文件大小？Addressable是通過把各個資源設置到各個Group中，而Group在設置這些資源時，可以打到一個AssetBundle還是要分開打呢？後續實際打包AssetBundle，相當於是黑盒不透明的，但實際應該有這個需求，對於打出來的Bundle過大或者過小都不合適。我嘗試基於它的AnalyzeRule，寫自定義的檢查類，卻沒有發現跟AssetBundle有關的API。大家知道是爲什麼嗎？或者能知道它的Catalog相關的API也可以。

A：可以寫一個CustomBuildMode繼承BuildScriptPackedMode，重寫裏面的Name和DoBuild，這樣每次打包都可以看到每個組生成的Bundle的大小，具體代碼如下：

寫完代碼後，創建一個CustomBuildMode.asset，並加入到AddressableSettings的Build And Play Mode裏面，然後就可以進行Build並看到Bundle的大小了。

感謝Xuan@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5e649911438f7d0db495c724

Rendering

Q：我們的遊戲在華爲機型上的模型貼圖都很模糊，鋸齒非常嚴重，但在其它機型上就沒有這個問題。我們在系統設置中關閉了智能分辨率，效果就好很多。大家有遇到過類似的問題嗎？怎麼解決呢？我查看華爲的官方論壇，發現這個問題似乎是個通病。

A：1.華爲機型開啓智能分辨率，會導致遊戲運行時分辨率較低，從而導致模型貼圖都較爲模糊。在遊戲一啓動的時候讀取設備的物理分辨率，執行Screen.SetResolution強制設置分辨率就能夠正常顯示。

2.如何正確地獲取設備物理分辨率？在降低分辨率之後，通過Android API獲取到的設備分辨率都是降低之後的分辨率值。

3.嘗試之後，發現了getRealMetrics，調用這個接口獲取分辨率（降低之後的分辨率值），再通過density值判斷，若爲2，即這是被降低分辨率的值。

所以最後處理方式爲：遊戲一啓動判斷是華爲的機型設備，通過getRealMetrics獲取屏幕分辨率，再通過density值判斷是否被智能降低了，如果值爲2，將獲取到分辨率值擴大1.5倍（基本上就是真實分辨率），然後用SetResolution設置。

用這個方法在華爲設備上測試均正常顯示（目前還沒發現顯示有異常）。

感謝極致遊戲@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5e82ea3f18502d37b0fc26d4

Texture

Q：向大家請教一下關於圖片壓縮格式選擇問題。我看了之前的博客，安卓選擇的是ETC2，蘋果選擇的是PVRTC。現在項目升級到了Unity 2019.2.21f1後，多了很多格式。

請教一下下面幾個問題，Unity版本是2019.2.21f1：
1. 新版本Unity 2019 Format中安卓和蘋果的格式，該怎麼選擇？
2. 安卓現在可以使用ASTC格式了嗎？市場份額是多少？
3. Resize Algorthm和Override ETC2 fallback分別代表什麼意思？以及怎麼選擇？
4. HDR、6X6和10X10，該怎麼選擇好呢？
麻煩科普下，謝謝！

A1：第一個問題，個人覺得iOS選ASTC，Android選ETC2比較好。
第三和第四個問題，我建議可以看看官方文檔：Texture的文檔，看完這個你基本上就能夠明白了。然後根據項目需求，相信能夠有個比較好的選擇。
感謝李星@UWA問答社區提供了回答

A2：現在Texture新上線的項目已經開始普及ASTC的使用了，所以全面選擇ASTC，2019可以默認import的時候選擇ASTC，尤其是對光照貼圖和法線有很好的效果。Unity現在默認是6x6，也可以根據項目選擇其它大小。
感謝鄭驍@UWA問答社區提供了回答

A3：現在立項的項目，iOS和安卓都應該選擇ASTC了，因爲連模擬器都已經支持ASTC，我們的項目由於需要做PBR效果，ETC2在壓縮上的失真還是會比較嚴重的。如果實在需要兼容原來的機器（不支持ASTC)，可以多編譯一份ETC2的資源放到服務器上，判斷機型後再下載就行了，畢竟這部分機器很少。我自己的項目是這麼做的，後臺監控到需要下載ETC2資源的玩家也是少之又少。
感謝簡單就好@UWA問答社區提供了回答

A4：如果版本包不發東南亞、中東、非洲和南美，那基本上全都可以用ASTC了；如果要發以上舊機型多的地區，建議用Unity默認的方案（pvrtc @ ios & etc @ android）。

感謝鄭昊@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5e4d17b886a3954891983920

Memory

Q：Splash用到的紋理會一直常駐內存，應該怎麼處理？

A1：測試後發現在Unity 2017.4.33和Unity 2018.4.12中都有這個問題，而且切換場景後，仍舊不會被卸載。

可以通過如下的方式解決這個問題：初始場景中，在腳本中引用Splash中用到的Sprite，然後強制Unload這些Sprite，可以去除這些紋理的佔用，大致方式如下圖：

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

A2：還有個方案：不用Unity提供的遊戲內閃屏，改用平臺原生方式實現。

iOS上用Storyboard方式：

安卓上改一下Java代碼，自己放個View擋在前面。

感謝littlesome@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5e8d9b058cabe84a011afc45

Rendering

Q：爲了讓新版的TileMap受到光照影響，替換TileMap爲LitShader，並且做了以下操作：
1. TileMap的mode爲Chunk（塊渲染）。
注：Individual模式下不存在該問題，因爲每個地塊都是獨立渲染的，但是Draw Call很高。
2. 打了一個平行光和聚光燈。

出現了問題，平行光下所有的Tile渲染正常，聚光燈渲染範圍則重疊面，渲染不正常（不同於zfighting），這是爲什麼呢？

以下爲Shader截圖：

正常渲染，僅方向光：

不正常渲染：

A：Chunk模式下做了一下測試，大概結論是在聚光燈的情況下，重疊的部分有三個顏色疊加（一個Base Pass，兩個Add Pass）；沒有重疊的部分有兩個顏色疊加（一個Base Pass，一個Add Pass）。其中的Base Pass是由強度爲0的平行光及環境光等組成，Add Pass是聚光燈。重疊部分多了一個Add Pass的顏色，所以看起來就會“不和諧”。

先來說一下爲什麼會有重疊部分。假設一張128x128的紋理，按照默認100Pixels Per Unit的設置來算，這個紋理的長度爲1.28x1.28，但是TileMap的一個方格子是1x1，所以把這個紋理往格子裏放，兩邊就各多了0.14，這樣平鋪的時候就會有重疊部分了。

從上圖可以看到，越往聚光燈強度高的地方，重疊的顏色看起來越“異常”，因爲剛好多出來一份聚光燈的顏色貢獻。

上圖爲第一個Base Pass，Keyword爲平行光和球諧環境光，Blend模式爲SrcAlpha OneMinusSrcAlpha，這個紋理的Alpha爲1。這裏的繪製效果相當於Blend模式爲One Zero，後畫的顏色會完全覆蓋先畫的顏色。因此當只有一個平行光的時候，只有這一個Pass，顏色非常和諧。

上圖爲第二個Add Pass，Keyword爲探照燈，Blend模式爲SrcAlpha One，效果相當於Blend模式爲One One，重疊的部分會把顏色往Color Buffer裏面疊加兩次。

以上是Chunk模式，對於Individual模式，發現了和Chunk模式不太一樣的地方，渲染效果如下：

從上面的圖可以看到，豎直方向上沒有不和諧。仔細看了一下FrameDebugger，發現渲染的順序和想象的不一樣。

前四個渲染分別是1個Base，1個Base，1個Add，1個Add。第五個Draw Call的時候，爲 Base Pass，Blend模式變成了One Zero，於是豎直方向上重疊的部分上之前的顏色被拋棄了。所以豎直方向最終效果並沒有不和諧，而水平方向仍舊是重疊的部分多加了一次。