1）Addressable如何刪除舊資源
2）Addressable如何更新Catalog文件
3）Editor在Android平臺下加載AssetBundle的疑問
4）資源被打成AssetBundle後，圖集被多次加載在內存中
5）Gfx.WaitForPresent耗時與GPU的關係
這是第209篇UWA技術知識分享的推送。今天我們繼續爲大家精選了若干和開發、優化相關的問題，建議閱讀時間10分鐘，認真讀完必有收穫。
UWA 問答社區：answer.uwa4d.com
UWA QQ羣2：793972859（原羣已滿員）
Addressable
Q1：目前計劃使用Addressable來實現資源熱更新，實際真機測試發現當資源更新後，舊的資源Addressable並不會把它刪除，同時可以看到App佔用的數據文件會越來越大。請問有什麼辦法可以把指定的Group或Label的資源刪除嗎？
試了Addressable.ClearDependencyCacheAsync也不行。實際測試這個接口只能刪除最新版本的資源。當本地已經是最新版本資源時這個接口確實有效；但是如果本地需要更新資源時，這個接口應該也是嘗試去刪除最新資源，然而本地並沒有最新版的資源，所以大概就無效了。
A：調用Addressable.ClearDependencyCacheAsync實質是調用了 “Caching.ClearAllCachedVersions();”。事實上是使用了Unity的Caching系統。
在Windows編輯器環境測試了一下。
Caching的目錄爲“C:\Users\UserName\AppData\LocalLow\Unity\ProjectFolder”，當正常下載AssetBundle以後，該目錄內就出現 “stage01_298bd883434eedb69ea7316cb23e0b0d\662ab7a0d2aa99bc7a2dbb7baec63872” 之類的目錄，並保存着當前的AssetBundle版本，當更新AssetBundle並執行下載以後，該目錄也會出現其他AssetBundle的Caching目錄。在執行下載之前，先執行了一下“Caching.ClearCache();”，這時會發現Caching目錄內已經被清空，所有版本的AssetBundle都沒有了。下載完成後，該目錄只保留了最新的AssetBundle資源。由此可推，即使不通過Addressable系統，仍然可以通過Caching把所有的資源都清理掉。
於是繼續進行第二個實驗，連續更新幾次AssetBundle以後，Caching目錄內已經有多個版本的AssetBundle目錄了，當有新的更新後執行 “Addressables.ClearDependencyCacheAsync(key);”，發現的確並沒有將舊版本的AssetBundle都刪除。因爲“Caching.ClearAllCachedVersions”的參數是對應的AssetBundle名字，而Addressables的管理AssetBundle包名是帶Hash的，因爲每個版本的AssetBundle文件名都不一樣的，Caching系統也就無法分辨了。
繼續做實驗，將打包名字去掉Hash，Caching目錄內的AssetBundle目錄名也不帶Hash了，然後連續更新幾個版本後發現，該AssetBundle目錄內多了幾個不同Hash版本的目錄，內部纔是真正的AssetBundle。於是走“Addressables.ClearDependencyCacheAsync(key)”，這時就能正確地刪除舊版本，然後再更新新版本了。
Q2：確實不勾選Hash打包可以成功刪除了，這種方式貌似就是覆蓋式的打包，不知道會不會有其他隱患，目前來看夠用。
A：隱患就是如果按照Label來做更新檢查，本來可以只下載差異部分，但是因爲同樣使用Label做清除Caching的工作就會造成重複下載原本不必要更新的部分。於是就需要遍歷所有的Location然後去檢查更新，並將有更新的AssetBundle放入列表，然後再依次清除舊緩存，重新下載。這樣就和傳統方案沒太大區別了。
Q3：請問下不勾選Hash其實就不用清除了吧？名字一樣不是會直接覆蓋嗎？
A：不勾選Hash，只是在Cache的目錄內第一級資源同名子目錄是一致的，但是裏面保存具體數據的子目錄是遞增的，因爲有不同版本。每個版本都會有一個子目錄。這個是Caching系統管理的。
感謝黃程@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5ee9ea195d07d80acd262421
Addressable
Q：項目使用Addressable做資源管理，資源更新方面因爲原來有一套下載更新流程，就不使用Remote功能，全部Group都是cannot change post release。只是單純用Addressable打包，然後比較差異下載回本地，使用“Addressables.InternalIdTransformFunc”指向新資源的路徑。
但是由於下載回來新的Bundle的crc跟原始Catalog的crc不一致，會報錯“CRC Mismatch. Provided 16302c0b, calculated 17167beb from data. Will not load AssetBundle”。
希望在下載完資源後重新加載新的Catalog文件，應該怎麼實現？嘗試使用了“Addressables.LoadContentCatalogAsync”接口加載下載回來的Catalog文件，但是還是報錯。
A：使用“Addressables.LoadContentCatalogAsync”後還是出錯的可能性有一種：因爲默認的Catalog對應的Locator並沒有移除，造成查找時首先在默認的Locator內找到資源，而因爲不走Addressable的更新流程，那麼默認的Locator對應的crc永遠就是舊的，於是出錯了。
感謝黃程@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5ef31f5b1bd523380210b866
Rendering
Q：Unity Editor下加載AssetBundle，材質球Keywords正常，但是某些屬性不存在。
Unity 2018.4.23f1 Android版本，Shader用的是新建的SurfaceShader，Shader Stripping設置如下圖。
Mat、Shader、Prefab打在同一個Assetbundle上，在Editor中運行加載該Assetbundle上的Prefab，會發現一些屬性不存在，而原本掛在這個場景中的Prefab，則是正常。
A：打包成APK後連接FrameDebugger看到在場景中的球和AssetBundle加載後實例化的球的Shader參數信息完全是一樣的，所以可能是在Android平臺Build後的AssetBundle在Editor中加載纔會出現樓主所說的問題。
另外再做了一個對比試驗，將平臺切換成PC。在編輯器裏，場景中原有的球和AssetBundle加載出來的球的渲染就是完全一樣的了。
感謝Xuan@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5ee0883e50fb7c2938d1f265
AssetBundle
Q：資源被打成AssetBundle以後，發現圖集被多次加載在內存中，這正常嗎？
若是不正常，是什麼原因造成這個問題的呢？怎麼解決？（Unity版本是2017.3.9）
A1：可能是在通過AssetBundle.Unload(false)卸載AssetBundle對象後，重新創建該AssetBundle對象並加載之前加載過的資源到內存，這樣就出現了冗餘。還有一種就是打包時出現了冗餘。
感謝李星@UWA問答社區提供了回答
A2：根據經驗說說造成這種情況的原因。
確認打包的時候，圖集是依賴的打包，而沒有被打包到各個prefab裏面。這個推薦使用UWA的在線AssetBundle資源檢測工具，直接把整個項目的AssetBundle上傳，可以查出很多問題。
你把Assetbundle包給卸載了。AssetBundle.Unload(false)，這樣Assetbundle關聯斷了，就會重新加載資源，如果樓主用的是LZ4的壓縮格式，不推薦再去調用Unload(false)了，第一LZ4的ab包本身佔用極少的內存，第二Unload(false)的資源多了，調用Resources.UnloadUnusedAssets接口，容易造成卡頓。應該自己寫引用AssetBundle計數，直接Unload(true)。
感謝簡單就好@UWA問答社區提供了回答
A3：根據經驗有以下幾點供參考。
使用Unload(true) 更好一些。經常會有人操作不規範掛住一些資源，然後越積累越多，主動釋放安全很多。
Unload(false) 會導致再次加載同一資源被開一個新的區域。某些重複利用率較高的資源，會出問題。比如，材質A和材質B都引用一個貼圖，加載材質A根據依賴加載貼圖，然後釋放AssetBundle；加載材質B時，會加載第二份貼圖。所以用Unload(false) 並不能達到及時釋放ab的效果。
反覆加載的問題。卸載AssetBundle之後，再次使用尚未析構的資源，又需要重新加載AssetBundle，雖然LZ4的加載速度可以忽略不計。
感謝歐月松@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5ee662bc5fad93669b232572
Rendering
Q：請教一下，在報告中看到Gfx.WaitForPresent很高，是不是就說明GPU壓力很大？CPU均值在19ms左右，是不是說明壓力在GPU端而不是CPU？是否應該先去優化GPU？
A1：Gfx.WaitForPresent的值高一般是開了多線程渲染，要麼在做垂直同步，要麼GPU負擔較重，CPU已經做完了等着GPU完成做呈現。建議查一下具體渲染的內容，或者在Profile內看看渲染線程的工作情況。
感謝黃程@UWA問答社區提供了回答
A2：Gfx.WaitForPresent就是GPU瓶頸：
- 降分辨率；
- Shader優化，優化指令，高中低配使用不同的Shader LOD；
- 做視距控制，不光減DrawCall，不透明物體同樣存在Overdraw，特別是場景複雜度高的情況下。
感謝BQ哥@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5eb2db994d93790618e0eccf
封面圖來源於網絡
今天的分享就到這裏。當然，生有涯而知無涯。在漫漫的開發週期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網站上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之“石”，也能攻你之“玉”。
官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com
官方技術QQ羣：793972859（原羣已滿員）