Unity3D:資源包的壓縮(Asset Bundle Compression)
原文:http://blog.csdn.net/coollen_mmx/article/details/51647899
資源包壓縮
Unity支援三種資源包的壓縮方式:LZMA,LZ4和不壓縮。
LZMA格式
資源包預設編譯是壓縮格式的。標準壓縮格式使用的是單一的LZMA演算法的序列化的資料檔案流,使用前需要獲取完整的資料再解壓縮。
LZMA壓縮包下載容量最小,但會導致解壓變慢和載入時間更長。
LZ4格式
Unity還支援LZ4壓縮,它會導致較大的壓縮檔案,但是這種方式不要求完整的資料包就可以解壓縮。LZ4演算法是“基於塊”的,因此當物件從一個LZ4壓縮包載入時,僅用於該物件的相應塊會被解壓。這發生在瞬間,並
不壓縮格式
第三個壓縮選項是不壓縮。未壓縮的資源包很大,但一旦下載後則訪問最快。
壓縮包的快取
WWW.LoadFromCacheOrDownload函式下載並快取資源包到磁碟上,這極大的加快了載入速度。從Unity 5.3開始,快取資料也可以使用LZ4演算法壓縮。相比未壓縮的包它能節省40%~60%的空間。在下載過程中會同時進行壓縮,因此終端使用者幾乎不會察覺。當資料從網路到達,Unity將解壓並以LZ4格式重新壓縮它。在下載資料流同時重新壓縮,這意味著一旦資料足夠就馬上進行快取壓縮,並一直持續增長到下載完成。在此之後,資料在需要時會從快取記憶體的包中即時解壓並讀取。
快取壓縮預設是啟用的,由屬性Caching.compressionEnabled控制。它同時影響快取到磁碟和儲存在記憶體中的資源包。
AssetBundle載入API概述
此表提供了使用不同的壓縮型別和不同的載入方法時記憶體和效能開銷的比較。
無壓縮 |
塊壓縮(LZ4) |
流壓縮(LZMA) |
|
WWW * |
記憶體:未壓縮的包的大小+(當WWW未釋放時,未壓縮的包的大小)。效能:沒有額外的開銷。 |
記憶體:LZ4HC壓縮的包的大小+(當WWW未釋放時,LZ4HC壓縮的包的大小)。效能:沒有額外的開銷。 |
記憶體:LZ4壓縮的包的大小+(當WWW未釋放時,LZMA壓縮的包的大小)。效能:LZMA解壓+ 在下載過程中LZ4壓縮。 |
LoadFromCacheOrDownload |
記憶體:沒有額外的開銷。效能:從磁碟讀取。 |
記憶體:沒有額外的開銷。效能:從磁碟讀取。 |
記憶體:沒有額外的開銷。效能:從磁碟讀取。 |
LoadFromMemory(非同步) |
記憶體:未壓縮的包的大小。效能:沒有額外的開銷。 |
記憶體:LZ4HC壓縮的包的大小。效能:沒有額外的開銷。 |
記憶體:LZ4壓縮的包的大小。效能:LZMA壓縮+ LZ4壓縮。 |
LoadFromFile(非同步) |
記憶體:沒有額外的開銷。效能:從磁碟讀取。 |
記憶體:沒有額外的開銷。效能:從磁碟讀取。 |
記憶體:LZ4壓縮的包的大小。效能:從磁碟讀取+ LZMA壓縮+ LZ4壓縮。 |
WebRequest的(也支援快取) |
記憶體:未壓縮的包的大小。效能:沒有額外開銷[+是否從磁碟讀取快取]。 |
記憶體:LZ4HC壓縮的包的大小。效能:沒有額外的開銷[+是否從磁碟讀取快取]。 |
記憶體:LZ4壓縮的包的大小。效能:下載過程中LZMA壓縮+ LZ4壓縮[+是否從磁碟讀取快取]。 |
*當使用WWW下載資源包,WebRequest還需要一個從socket讀取資料的8x64KB的累加器快取。
因此,使用在遊戲中使用低階載入API時遵循以下原則:
1. 為遊戲部署資源包時使用StreamingAssets:使用BuildAssetBundleOptions);使用基於塊的壓縮方式來構建包和資源包;使用LoadFromFileAsync來載入它。這使您的記憶體資料壓縮和載入速度幾乎等於讀取快取。
2. 下載用作DLC的資源包:使用預設的編譯選項(LZMA壓縮)和LoadFromCacheOrDownload / WebRequest來下載和快取它。這樣你可以有最好的壓縮比,並得到資源包。LoadFromFile載入效能進一步提升。
3. 加密包:使用BuildAssetBundleOptions;使用基於塊的壓縮方式,並使用LoadFromMemoryAsync載入(通常這是唯一方案)。
4. 自定義壓縮:使用BuildAssetBundleOptions;使用非壓縮方式來構建資源包。用自定義的演算法解壓之後使用LoadFromFileAsync載入包。
你應該使用非同步函式,因為他們不阻塞主執行緒,並且能讓載入更高效和操作佇列化。絕對避免在同時使用同步和非同步函式,這可能會在主執行緒上產生"打嗝"。
相容性
資源包容器格式發生了變化,來支援新的壓縮型別,並且為進一步改進提供基礎。Unity5還支援由Unity 4建立的包,但是更早期版本(2.X,3.X)不支援。
---------------------------------------------------- 以下是原文 ----------------------------------------------------
Asset Bundle Compression
Unity supports three compression options for Asset Bundles: LZMA, LZ4, and Uncompressed.
LZMA Format
By default, when Asset Bundles are built, they are stored in a compressed format. The standard compressed format is a singleLZMAstream of serialized data files, and needs to be decompressed in its entirety before use.
LZMA-Compressed bundles give the smallest possible download size, but has relatively slow decompression resulting in higher apparent load times.
LZ4 Format
Unity also supportsLZ4compression, which results in larger compressed file sizes, but does not require the entire bundle to be decompressed before use. LZ4 is a “chunk-based” algorithm, and therefore when objects are loaded from an LZ4-compressed bundle, only the corresponding chunks for that object are decompressed. This occurs on-the-fly, meaning there are no wait times for the entire bundle to be decompressed before use. The LZ4 Format was introduced in Unity 5.3 and was unavailable in prior versions.
Uncompressed Format
The third compression option is no compression at all. Uncompressed bundles are large, but are the fastest to access once downloaded.
Caching of Compressed Bundles
TheWWW.LoadFromCacheOrDownloadfunction downloads and caches asset bundles to disk and thus greatly speeds up loading afterwards. From Unity 5.3 onwards, cached data can also be compressed with the LZ4 algorithm. This saves 40%–60% of space compared to uncompressed bundles. Recompression happens during download and thus is almost unnoticeable by the end users. As data arrives from the socket, Unity will decompress it and recompress it in LZ4 format. This recompression occurs during the download streaming, which means the cache compression begins as soon as enough of the data is downloaded, and continues incrementally until the download is complete. After that, data is read from the cached bundle by decompressing chunks on-the-fly when needed.
Cache compression is enabled by default and is controlled by theCaching.compressionEnabled
property. It affects bundles cached to disk and stored in memory.
Mem: no extra memory is used. Perf: reading from disk. |
Mem: no extra memory is used. Perf: reading from disk. |
Mem: no extra memory is used. Perf: reading from disk. |
|
Mem: uncompressed bundle size. Perf: no extra processing. |
Mem: LZ4HC compressed bundle size. Perf: no extra processing. |
Mem: LZ4 compressed bundle size. Perf: LZMA decompression + LZ4 compression. |
|
Mem: no extra memory is used. Perf: reading from disk. |
Mem: no extra memory is used. Perf: reading from disk. |
Mem: LZ4 compressed bundle size. Perf: reading from disk + LZMA decompression + LZ4 compression. |
|
(also supports caching) |
Mem: uncompressed bundle size. Perf: no extra processing [+reading from disk if cached]. |
Mem: LZ4HC compressed bundle size. Perf: no extra processing [+reading from disk if cached]. |
Mem: LZ4 compressed bundle size. Perf: LZMA decompression + LZ4 compression during download [+reading from disk if cached]. |
1. Deploying asset bundles with your game as StreamingAssets - use BuildAssetBundleOptions.ChunkBasedCompression when building bundles and AssetBundle.LoadFromFileAsync to load it. This gives you data compression and the fastest possible loading performance with a memory overhead equal to read buffers.
2. Downloading asset bundles as DLCs - use default build options (LZMA compression) and LoadFromCacheOrDownload/WebRequest to download and cache it. Here you’ll have the best possible compression ratio and AssetBundle.LoadFromFile loading performance for further loads.
3. Encrypted bundles - choose BuildAssetBundleOptions.ChunkBasedCompression and use LoadFromMemoryAsync for loading (this is pretty much the only scenario where LoadFromMemory[Async] should be used).
4. Custom compression - use BuildAssetBundleOptions.UncompressedAssetBundle to build and AssetBundle.LoadFromFileAsync to load a bundle after it was decompressed by your custom compression algorithm.