原標(biāo)題：關(guān)于LZMA和LZ4壓縮的疑惑解析

這是第112篇UWA技術(shù)知識(shí)分享的推送。今天我們繼續(xù)為大家精選了若干和開發(fā)、優(yōu)化相關(guān)的問題，建議閱讀時(shí)間10分鐘，認(rèn)真讀完必有收獲。

UWA QQ群：465082844(僅限技術(shù)交流)

AssetBundle

Q：昨天看到問答社區(qū)上UWA_Xin對(duì)LZMA和LZ4壓縮的解答，在此有些疑問。

問題1：我在網(wǎng)上看到這篇文章(https://www.cnblogs.com/AaronBlogs/p/6837828.html)提到，AssetBundle在加載的時(shí)候需要擴(kuò)展出來一塊內(nèi)存來解壓，我覺得解壓這個(gè)說法是有問題的，因?yàn)槿绻急唤鈮撼鰜砹?#xff0c;就不需要LoadAsset了。資源都已經(jīng)在內(nèi)存中了，而我們測(cè)試的時(shí)候，用LZ4要比LZMA內(nèi)存小了快200MB，所以我覺得LZMA是在加載AssetBundle的時(shí)候會(huì)把資源都解壓出來的，并不是只是多了一個(gè)LZ4的AssetBundle大小。

我看了UWA關(guān)于《移動(dòng)游戲加載性能和內(nèi)存管理全解》的視頻講解，上面說用LZMA壓縮的時(shí)候LoadFromCache在第一次讀取時(shí)會(huì)很耗時(shí)，是由于Cache會(huì)把AssetBundle包重新壓縮成LZ4使得第二次讀取的時(shí)候速度加快，所以上面截圖說的LZMA會(huì)把AssetBundle再壓縮成LZ4其實(shí)只是針對(duì)的LoadFromCache這個(gè)接口而言的，而不是針對(duì)的LoadFromFile，猜想LoadFromFile是直接從硬盤讀取的，不存在Cache的操作，所以上圖是不是說得有誤？

問題2：LZ4壓縮AssetBundle包是按照Chunk來讀取的，那么在解壓AssetBundle包的時(shí)候一般是在讀取AssetBundle的頭文件信息，那么解壓AssetBundle包的時(shí)候LZ4的Chunk優(yōu)勢(shì)是沒有優(yōu)勢(shì)的嗎？加載AssetBundle的時(shí)候LZMA和LZ4的速度應(yīng)該一樣的嗎？(如果LZMA是完全解壓整個(gè)包體就另當(dāng)別論了)。

UWA：問題1解答：我覺得解壓這個(gè)說法是有問題的，因?yàn)槿绻急唤鈮撼鰜砹?#xff0c;就不需要Loadasset了，資源都已經(jīng)在內(nèi)存中了。

解壓和加載是兩回事的。題主給的文章里說的解壓是針對(duì)WWW接口的，WWW加載LZMA，是需要解壓進(jìn)內(nèi)存的，但這個(gè)只能算是二進(jìn)制流，相當(dāng)于是未壓縮的AssetBundle，后續(xù)的LoadAsset依然是要做的…但第二次調(diào)用的LoadFromCache就不用了，因?yàn)榇疟P的Cache里已經(jīng)是“未壓縮的AssetBundle”了。

上面截圖說的LZMA會(huì)把AssetBundle再壓縮成LZ4，這不僅僅是針對(duì)LoadFromCache的，LoadFromFile也是一樣，只是LoadFromFile是不Cache到磁盤的，完全在內(nèi)存中進(jìn)行，所以這個(gè)接口加載LZMA的AssetBundle一樣會(huì)變很慢，同時(shí)造成內(nèi)存的明顯上漲。

問題2解答：根據(jù)問題1的解釋，LZ4相比LZMA在加載的時(shí)候還是有很大優(yōu)勢(shì)的。但最后還是留下了一個(gè)疑問，而我們測(cè)試的時(shí)候用LZ4，要比LZMA內(nèi)存小了快200MB，所以我覺得LZMA是在加載AB的時(shí)候會(huì)把資源都解壓出來的，并不是只是多了一個(gè)LZ4的大小。經(jīng)過這邊的一些測(cè)試，這個(gè)內(nèi)存的差異確實(shí)更加接近未壓縮的的大小，而不是LZ4的大小。

所以題主可不可以再多做一步，就是把用到的打成未壓縮的，看看是不是確實(shí)接近200MB呢？

該回答由UWA提供，歡迎大家轉(zhuǎn)至社區(qū)進(jìn)行進(jìn)一步交流

粒子系統(tǒng)

Q：粒子系統(tǒng)是否能夠支持GPU Instancing？做了些例子都沒能看到GPU Instancing生效。

UWA：Unity 2018已經(jīng)支持Particle System的GPU Instancing了，不過必須是Mesh模式的，具體可以看這個(gè)文檔：

https://docs.unity3d.com/Manual/PartSysInstancing.html

https://answer.uwa4d.com/question/5afe9bb56b104d27ac3aadaa

加載

Q：如果我代碼中聲明了個(gè)Texture然后加載了圖片，是不是無論我的這個(gè)Component銷毀或者這個(gè)GameObejct銷毀，都不會(huì)釋放這個(gè)Texture的內(nèi)存？必須在OnDestroy 里銷毀才可以呢？

A1：因?yàn)槟硰圱exture的內(nèi)存只會(huì)有一份，但是可能會(huì)被多個(gè)對(duì)象引用，所以不可能跟隨Component或GameObject的銷毀而銷毀。

估計(jì)是考慮到資源管理(某張Texture當(dāng)前幀不用了，可能過兩幀又要用了，而這部分IO消耗不小，所以需要開發(fā)者自行管理)，所以這部分并沒有走GC。使用Resources.UnloadAsset卸載Texture。

感謝凱奧斯@UWA問答社區(qū)提供了回答

A2：Component銷毀 或者 Gameobject銷毀都不會(huì)卸掉new出來的Texture的內(nèi)存，需要調(diào)用Object.Destroy()方法，把new出來的Texture對(duì)象作為參數(shù)傳進(jìn)去，然后查看Profiler就可以驗(yàn)證。

感謝上午八點(diǎn)@UWA問答社區(qū)提供了回答

編輯器

Q：有辦法臨時(shí)屏蔽掉腳本的一些編譯Warning嗎？比如 The variable 'xxx' is declared but never used之類的。

A1：File->Build Settings->Player Settings->Logging

A2：強(qiáng)烈建議題主修掉這些Warning，而不是屏蔽掉它們。我覺得，程序保證代碼沒有Bug是底線，沒有Warning是合格線……尤其是你舉例的這種，雖然編譯器會(huì)幫你做優(yōu)化，但是保不齊什么時(shí)候?qū)懫渌壿嫷臅r(shí)候會(huì)坑了你。

感謝賈偉昊@UWA問答社區(qū)提供了回答

動(dòng)畫

Q：游戲在運(yùn)行一段時(shí)間后，出現(xiàn)了一個(gè)CPU高占用函數(shù)：Director.ProcessPlaySateChanges ，它產(chǎn)生了3616ms的耗時(shí)，請(qǐng)問這是怎么產(chǎn)生的，確認(rèn)C#代碼中無此方法調(diào)用，有人遇到過這個(gè)問題嗎？(版本Unity 5.6.5p3)

A：經(jīng)排查已找到原因，是UI中的一個(gè)播放動(dòng)畫前調(diào)用了函數(shù) Animator.Rebind()導(dǎo)致的。

感謝張劍@UWA問答社區(qū)提供了問題和回答

今天的分享就到這里。當(dāng)然，生有涯而知無涯。在漫漫的開發(fā)周期中，您看到的這些問題也許都只是冰山一角，我們?cè)缫言赨WA問答網(wǎng)站(answer.uwa4d.com)上準(zhǔn)備了更多的技術(shù)話題等你一起來探索和分享。歡迎熱愛進(jìn)步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之“石”，也能攻你之“玉”。返回搜狐，查看更多

責(zé)任編輯：

總結(jié)

以上是生活随笔為你收集整理的java视频压缩 lz4_关于LZMA和LZ4压缩的疑惑解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。