【厚積薄發】Addressable如何刪除舊資源

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問答社區提供了回答

---

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問答社區提供了回答

---

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問答社區提供了回答

---

AssetBundle

Q：資源被打成AssetBundle之後，發現圖集被屢次加載在內存中，這正常嗎？

如果不正常，是什麼緣由形成這個問題的呢？怎麼解決？（Unity版本是2017.3.9）

A1：多是在經過AssetBundle.Unload(false)卸載AssetBundle對象後，從新建立該AssetBundle對象並加載以前加載過的資源到內存，這樣就出現了冗餘。還有一種就是打包時出現了冗餘。

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

A2：根據經驗說說形成這種狀況的緣由。

1. 確認打包的時候，圖集是依賴的打包，而沒有被打包到各個prefab裏面。這個推薦使用UWA的在線AssetBundle資源檢測工具，直接把整個項目的AssetBundle上傳，能夠查出不少問題。
2. 你把Assetbundle包給卸載了。AssetBundle.Unload(false)，這樣Assetbundle關聯斷了，就會從新加載資源，若是樓主用的是LZ4的壓縮格式，不推薦再去調用Unload(false)了，第一LZ4的ab包自己佔用極少的內存，第二Unload(false)的資源多了，調用Resources.UnloadUnusedAssets接口，容易形成卡頓。應該本身寫引用AssetBundle計數，直接Unload(true)。

感謝簡單就好@UWA問答社區提供了回答

A3：根據經驗有如下幾點供參考。

1. 使用Unload(true) 更好一些。常常會有人操做不規範掛住一些資源，而後越積累越多，主動釋放安全不少。
2. Unload(false) 會致使再次加載同一資源被開一個新的區域。某些重複利用率較高的資源，會出問題。好比，材質A和材質B都引用一個貼圖，加載材質A根據依賴加載貼圖，而後釋放AssetBundle；加載材質B時，會加載第二份貼圖。因此用Unload(false) 並不能達到及時釋放ab的效果。
3. 反覆加載的問題。卸載AssetBundle以後，再次使用還沒有析構的資源，又須要從新加載AssetBundle，雖然LZ4的加載速度能夠忽略不計。

感謝歐月鬆@UWA問答社區提供了回答

---

Rendering

Q：請教一下，在報告中看到Gfx.WaitForPresent很高，是否是就說明GPU壓力很大？CPU均值在19ms左右，是否是說明壓力在GPU端而不是CPU？是否應該先去優化GPU？

A1：Gfx.WaitForPresent的值高通常是開了多線程渲染，要麼在作垂直同步，要麼GPU負擔較重，CPU已經作完了等着GPU完成作呈現。建議查一下具體渲染的內容，或者在Profile內看看渲染線程的工做狀況。

參考文章：《扒一扒Profiler中這幾個「佔坑鬼」》

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

A2：Gfx.WaitForPresent就是GPU瓶頸：

1. 降分辨率；
2. Shader優化，優化指令，高中低配使用不一樣的Shader LOD；
3. 作視距控制，不光減DrawCall，不透明物體一樣存在Overdraw，特別是場景複雜度高的狀況下。

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

封面圖來源於網絡

---

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

官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com 官方技術QQ羣：793972859（原羣已滿員）