管理加載的資產
在內存敏感的環境中仔細控制加載的對象的大小和數量非常重要。從活動場景中移除時，Unity不會自動卸載對象。資產清理在特定時間觸發，也可以手動觸發。
AssetBundles本身必須小心管理。由本地存儲上的文件（在Unity緩存中或通過AssetBundle.LoadFromFile加載的文件）支持的AssetBundle具有最小的內存開銷，很少消耗超過幾十千字節。但是，如果存在大量的AssetBundles，則此開銷仍可能會出現問題。
由于大多數項目允許用戶重新體驗內容（例如重放級別），因此知道何時加載或卸載AssetBundle非常重要。如果AssetBundle卸載不當，可能會導致內存中的對象重復。在某些情況下不當卸載AssetBundles也會導致不良行為，例如導致紋理丟失。要理解為什么會發生這種情況，請參閱資產，對象和序列化章節的“ 對象間參考”部分。
管理資產和AssetBundles時要了解的最重要的一點是，在為UnloadAllLoadedObjects參數調用AssetBundle.Unload時，行為與true或false 一致。
該API將卸載正在調用的AssetBundle的頭信息。所述unloadAllLoadedObjects參數確定是否還從卸載這個AssetBundle實例化的所有對象。如果設置為true，則源自AssetBundle的所有對象也將立即被卸載 - 即使它們當前正在活動場景中使用。
例如，假設材料M是從AssetBundle AB加載的，并且假設M當前處于活動場景中。
如果調用了AssetBundle.Unload（true），那么M將從場景中移除，銷毀并卸載。但是，如果調用AssetBundle.Unload（false），則AB的標題信息將被卸載，但M仍將保留在場景中并且仍然有效。調用AssetBundle.Unload（false）會中斷M和AB之間的鏈接。如果稍后再次加載AB，則AB中包含的對象的新副本將被加載到內存中。
如果稍后再次加載AB，則將重新加載AssetBundle標題信息的新副本。但是，M沒有從AB的這個新副本中加載。Unity不會在AB和M的新副本之間建立任何關聯。
如果AssetBundle.LoadAsset（）被稱為重載中號，統一將不能解釋的舊副本中號為數據的實例AB。因此，Unity將加載M的新副本，并且在場景中將有兩個相同的M副本。
對于大多數項目來說，這種行為是不可取的。大多數項目應該使用AssetBundle.Unload（true）并采用一種方法來確保對象不重復。兩種常用方法是：
在應用程序的整個生命周期（例如在級別之間或在加載屏幕期間）卸載臨時AssetBundles時具有明確定義的點。這是更簡單和最常見的選擇。
僅當各個對象的所有構成對象都未使用時，才維護各個對象的引用計數并卸載AssetBundles。這允許應用程序卸載并重新加載單個對象而不復制內存。
如果應用程序必須使用AssetBundle.Unload（false），那么單個對象只能通過兩種方式卸載：
在場景和代碼中消除對不需要的對象的所有引用。完成后，調用Resources.UnloadUnusedAssets。
非加性地加載場景。這將銷毀當前場景中的所有對象并自動調用Resources.UnloadUnusedAssets。
如果一個項目有明確定義的點，可以使用戶等待對象加載和卸載（例如在游戲模式或級別之間），則應使用這些點來卸載盡可能多的對象并加載新的對象。
最簡單的方法是將項目的離散塊打包到場景中，然后將這些場景及其所有依賴項構建到AssetBundles中。然后，應用程序可以進入“加載”場景，完全卸載包含舊場景的AssetBundle，然后加載包含新場景的AssetBundle。
雖然這是最簡單的流程，但有些項目需要更復雜的AssetBundle管理。由于每個項目都不同，因此沒有通用的AssetBundle設計模式。
在決定如何將對象分組為AssetBundles時，通常最好先將對象綁定到AssetBundles中，如果它們必須同時加載或更新。例如，考慮角色扮演游戲。個別地圖和過場動畫可按場景分組為AssetBundles，但在大多數場景中都需要一些對象。可以構建AssetBundles來提供肖像，游戲內用戶界面以及不同的角色模型和紋理。后面的對象和資產可以被分組到第二組資產包中，這些資產包在啟動時加載并在應用的整個生命周期內保持加載狀態。
如果Unity必須在AssetBundle卸載后從它的AssetBundle重新加載對象，則可能會出現另一個問題。在這種情況下，重新加載將失敗，對象將作為（缺失）對象出現在Unity編輯器的層次結構中。
這主要發生在Unity丟失并恢復對其圖形上下文的控制時，例如，當移動應用程序被暫停或用戶鎖定其PC時。在這種情況下，Unity必須將紋理和著色器重新上傳到GPU。如果這些資產的源AssetBundle不可用，則應用程序將以洋紅色呈現場景中的對象。
4.2。分配
將項目的AssetBundles分發給客戶端有兩種基本方式：與項目同時安裝或在安裝后下載。
是否在安裝之后或之后發布AssetBundles的決定是由項目運行平臺的功能和限制決定的。移動項目通常選擇安裝后下載，以減少初始安裝大小并保持在無線下載大小限制以下。控制臺和PC項目通常會在AssetBundles初始安裝時運送。
正確的體系結構允許在安裝后將新內容或修訂的內容修補到補丁中，而不管最初如何交付AssetBundles。有關這方面的更多信息，請參閱Unity手冊的“ 使用AssetBundles進行修補”部分。
4.2.1。隨項目一起發貨
將AssetBundles與項目一起發送是最簡單的發布方式，因為它不需要額外的下載管理代碼。為什么一個項目可能會在安裝時包含AssetBundles有兩個主要原因：
減少項目構建時間并允許更簡單的迭代開發。如果這些AssetBundles不需要與應用程序本身分開更新，那么AssetBundles可以通過將資產包存儲在流式資產中而包含在應用程序中。請參閱下面的流媒體資源部分。
發布可更新內容的初始版本。通常這樣做是為了節省最終用戶在初次安裝后的時間，或者作為以后打補丁的基礎。流式資產對于這種情況并不理想。但是，如果編寫自定義下載和緩存系統不是一種選擇，則可以從Streaming Assets將可更新內容的初始修訂加載到Unity緩存中。
4.2.1.1。流媒體資產
在安裝時在Unity應用程序中包含任何類型的內容（包括AssetBundles）的最簡單方法是在構建項目之前將內容構建到/ Assets / StreamingAssets /文件夾中。構建時包含在StreamingAssets文件夾中的任何內容都將被復制到最終的應用程序中。
本地存儲上StreamingAssets文件夾的完整路徑可在運行時通過屬性Application.streamingAssetsPath訪問。然后可以在大多數平臺上通過AssetBundle.LoadFromFile加載AssetBundles。
Android開發人員：在Android上，StreamingAssets文件夾中的資源存儲到APK中，并且可能需要更多時間才能加載（因為存儲在APK中的文件可能使用不同的存儲算法）。使用的算法可能會因Unity版本而異。您可以使用7-zip等存檔器打開APK以確定文件是否被壓縮。如果是這樣，您可以期望AssetBundle.LoadFromFile（）執行得更慢。在這種情況下，您可以使用 UnityWebRequest.GetAssetBundle檢索緩存版本作為解決方法。通過使用UnityWebRequest，AssetBundle將在第一次運行期間解壓縮并緩存，從而使后續執行速度更快。請注意，這將需要更多的存儲空間，因為AssetBundle將被復制到緩存中。或者，您可以導出您的Gradle項目，并在構建時向您的AssetBundles添加擴展。然后，您可以編輯build.gradle文件并將該擴展名添加到noCompress部分。完成后，您應該可以使用AssetBundle.LoadFromFile（）而無需支付解壓縮性能成本。
注意：流式資產在某些平臺上不是可寫位置。如果安裝后需要更新項目的AssetBundles，則可以使用WWW.LoadFromCacheOrDownload或編寫自定義下載程序。
4.2.2。下載后安裝
將AssetBundles交付給移動設備的最佳方法是在應用程序安裝后下載它們。這也允許在安裝后更新內容而不強制用戶重新下載整個應用程序。在許多平臺上，應用程序二進制文件必須經過昂貴且冗長的重新認證過程。因此，開發一個良好的安裝后下載系統至關重要。
交付AssetBundles的最簡單方法是將它們放置在Web服務器上并通過UnityWebRequest交付。Unity會自動將下載的AssetBundles緩存在本地存儲上。如果下載的AssetBundle是LZMA壓縮的，則AssetBundle將以未壓縮或重新壓縮為LZ4（取決于Caching.compressionEnabled設置）存儲在緩存中，以便將來加載更快。如果下載的捆綁包壓縮了LZ4，則AssetBundle將被壓縮存儲。如果緩存填滿，Unity將從緩存中刪除最近最少使用的AssetBundle。有關更多詳細信息，請參閱內置緩存部分。
通常建議使用來啟動UnityWebRequest如果可能，或WWW.LoadFromCacheOrDownload只有使用Unity 5.2或以上。如果內置API的內存消耗，緩存行為或性能對于特定項目不可接受，或者項目必須運行特定于平臺的代碼以實現其要求，則只投資于定制下載系統。
可能阻止使用UnityWebRequest或WWW.LoadFromCacheOrDownload的情況示例：
當需要對AssetBundle緩存進行細粒度控制時
當項目需要實施自定義壓縮策略時
-
當項目希望使用平臺特定的API來滿足某些要求時，例如需要在非活動狀態下傳輸數據。
- 示例：使用iOS的后臺任務API在后臺下載數據。
如果AssetBundles必須在Unity沒有適當的SSL支持的平臺（如PC）上通過SSL提供。
4.2.3。內置緩存
Unity有一個內置的AssetBundle緩存系統，可用于緩存通過UnityWebRequest API 下載的AssetBundles，該API包含一個接受AssetBundle版本號作為參數的重載。此編號不存儲在AssetBundle內部，并且不由 AssetBundle系統生成。
緩存系統跟蹤傳遞給UnityWebRequest的最新版本號。當使用版本號調用此API時，高速緩存系統通過比較版本號來檢查是否存在緩存的AssetBundle。如果這些數字匹配，系統將加載緩存的AssetBundle。如果數字不匹配，或沒有緩存的AssetBundle，Unity將下載一個新副本。這個新副本將與新版本號相關聯。
緩存系統中的AssetBundles僅由其文件名來標識，而不是由其下載的完整URL標識。這意味著具有相同文件名的AssetBundle可以存儲在多個不同的位置，例如內容傳送網絡。只要文件名稱相同，緩存系統就會將它們識別為相同的AssetBundle。
每個應用程序都要決定將版本號分配給AssetBundles的適當策略，并將這些數字傳遞給UnityWebRequest。這些數字可能來自各種唯一標識符，例如CRC值。請注意，雖然AssetBundleManifest.GetAssetBundleHash（）也可用于此目的，但我們不建議使用此功能進行版本控制，因為它僅提供估算值，而不是真正的散列值計算）。
有關更多詳細信息，請參閱Unity手冊的“ 使用AssetBundles進行修補”部分。
在Unity 2017.1之后，緩存 API已經被擴展，以允許開發人員從多個緩存中選擇一個活動緩存，以提供更精細的控制。以前的Unity版本只能修改Caching.expirationDelay和Caching.maximumAvailableDiskSpace以刪除緩存的項目（這些屬性保留在Cache類中的Unity 2017.1中）。
expirationDelay是自動刪除AssetBundle之前必須經過的最小秒數。如果在此期間沒有訪問AssetBundle，它將被自動刪除。
maximumAvailableDiskSpace指定本地存儲空間量（以字節為單位），緩存在開始刪除最近使用過的最近比expirationDelay使用的AssetBundle之前可能會使用的空間量。達到限制時，Unity將刪除最近最少打開的緩存中的AssetBundle（或通過Caching.MarkAsUsed標記為已使用）。Unity會刪除緩存的AssetBundles，直到有足夠的空間完成新的下載為止。
4.2.3.1。緩存啟動
由于AssetBundles是通過其文件名來標識的，因此可以使用應用程序隨附的AssetBundles來“啟動”緩存。為此，請將每個AssetBundle的初始版本或基本版本存儲在/ Assets / StreamingAssets /中。該過程與“項目發貨”部分中詳細介紹的過程相同。
第一次運行應用程序時，可以通過從Application.streamingAssetsPath加載AssetBundles來填充緩存。從此，應用程序可以正常調用UnityWebRequest（UnityWebRequest也可用于最初從StreamingAssets路徑加載AssetBundles）。
4.2.3。自定義下載程序
編寫自定義下載程序可讓應用程序完全控制AssetBundles的下載，解壓縮和存儲方式。由于所涉及的工程工作并不平凡，我們只為大型團隊推薦這種方法。編寫自定義下載器時有四個主要考慮事項：
下載機制
存儲位置
壓縮類型
修補
有關修補AssetBundles的信息，請參閱使用AssetBundles修補部分。
4.2.3.1。下載
對于大多數應用程序，HTTP是下載AssetBundles最簡單的方法。但是，實現基于HTTP的下載程序不是最簡單的任務。自定義下載程序必須避免過多的內存分配，過多的線程使用和過多的線程喚醒。Unity的WWW類不適合這里詳盡描述的原因。
在編寫自定義下載器時，有三個選項：
C＃的HttpWebRequest和WebClient類
自定義本機插件
資產商店包
4.2.3.1.1。C＃類
如果應用程序不需要HTTPS / SSL支持，則C＃的WebClient類提供了下載AssetBundles最簡單的機制。它能夠將任何文件直接異步下載到本地存儲，而無需過多管理內存分配。
要使用WebClient下載AssetBundle，請分配該類的一個實例，并將其傳遞給AssetBundle的URL以下載和目標路徑。如果需要對請求參數進行更多控制，可以使用C＃的HttpWebRequest類編寫下載程序：
從HttpWebResponse.GetResponseStream獲取一個字節流。
在堆棧上分配一個固定大小的字節緩沖區。
從響應流中讀入緩沖區。
使用C＃的File.IO API或任何其他流式IO系統將緩沖區寫入磁盤。
4.2.3.1.2。資產商店包
多個資產商店軟件包提供本地代碼實現，以通過HTTP，HTTPS和其他協議下載文件。在為Unity編寫自定義本機代碼插件之前，建議您先評估可用的Asset Store軟件包。
4.2.3.1.3。自定義原生插件
編寫自定義本機插件是在Unity中下載數據最耗時，但最靈活的方法。由于編程時間要求高且技術風險高，只有在沒有其他方法能夠滿足應用程序要求的情況下才推薦此方法。例如，如果應用程序必須在Unity中沒有C＃SSL支持的平臺上使用SSL通信，則可能需要定制本機插件。
自定義本機插件通常會包裝目標平臺的本機下載API。示例包括iOS 上的NSURLConnection和Android 上的java.net.HttpURLConnection。請參閱每個平臺的本機文檔以獲取有關使用這些API的更多詳細信息。
4.2.3.2。存儲
在所有平臺上，Application.persistentDataPath指向一個可寫的位置，應該用于存儲應該在應用程序運行之間保持的數據。在編寫自定義下載器時，強烈建議使用Application.persistentDataPath的子目錄來存儲下載的數據。
Application.streamingAssetPath不可寫，對于AssetBundle緩存是一個糟糕的選擇。streamingAssetsPath的示例位置包括：
OSX：在.app包內; 不可寫。
Windows：在安裝目錄中（例如Program Files）; 通常不可寫
iOS：在.ipa包內; 不可寫
Android：在.apk文件中; 不可寫
4.3。資產分配策略
決定如何將項目資產劃分為AssetBundles并不簡單。很容易采用簡單的策略，比如將所有對象放置在自己的AssetBundle中或僅使用一個AssetBundle，但這些解決方案具有明顯的缺點：
-
擁有太少的AssetBundles ...
增加運行時內存使用量
增加加載時間
需要更大的下載量
-
擁有太多的AssetBundles ...
增加構建時間
可能會使開發復雜化
增加總下載時間
關鍵的決定是如何將對象分組為AssetBundles。主要戰略是：
邏輯實體
對象類型
并發內容
有關這些分組策略的更多信息可以在手冊中找到。
4.4。常見的陷阱
本節介紹使用AssetBundles項目中常見的幾個問題。
4.5.1。資產重復
Unity 5的AssetBundle系統將在對象構建到AssetBundle中時發現對象的所有依賴關系。此依賴關系信息用于確定將包含在AssetBundle中的一組對象。
明確分配給AssetBundle的對象只會構建到該AssetBundle中。當Object的AssetImporter的assetBundleName屬性設置為非空字符串時，對象將被“顯式分配” 。這可以在Unity Editor中通過在對象的檢查器中選擇一個AssetBundle或從編輯器腳本中完成。
也可以將對象分配給AssetBundle，方法是將它們定義為AssetBundle構建映射的一部分，該映射要與重載的BuildPipeline.BuildAssetBundles（）函數一起使用，該函數接受一組AssetBundleBuild。
在AssetBundle中未明確分配的任何對象都將包含在所有包含引用未標記對象的1個或多個對象的AssetBundle中。
例如，如果將兩個不同的對象分配給兩個不同的AssetBundles，但都具有對公共依賴項Object的引用，則該依賴Object將被復制到兩個AssetBundles中。重復的依賴關系也將被實例化，這意味著依賴關系對象的兩個副本將被視為具有不同標識符的不同對象。這將增加應用程序AssetBundles的總大小。如果應用程序加載它的父項，這也會導致Object的兩個不同副本被加載到內存中。
有幾種方法可以解決這個問題：
-
確保構建到不同AssetBundles中的對象不共享依賴關系。任何共享依賴關系的對象都可以放置在同一個AssetBundle中，而不需要重復依賴關系。
- 對于具有許多共享依賴項目的項目，此方法通常不可行。它生產的單片AssetBundles必須經常重建和重新下載，以避免方便或高效。
-
分段AssetBundles，以便不會同時加載共享依賴關系的兩個AssetBundles。
- 此方法可能適用于某些類型的項目，例如基于級別的游戲。但是，它仍然會不必要地增加項目的AssetBundles的大小，并增加構建時間和加載時間。
確保所有依賴項資產都內置到自己的AssetBundles中。這完全消除了重復資產的風險，但也帶來了復雜性。應用程序必須跟蹤AssetBundles之間的依賴關系，并確保在調用任何AssetBundle.LoadAsset API 之前加載了正確的AssetBundles 。
通過位于UnityEditor名稱空間中的AssetDatabase API 跟蹤對象依賴關系。正如命名空間所暗示的，這個API僅在Unity編輯器中可用，而不是在運行時。AssetDatabase.GetDependencies可用于查找特定對象或資產的所有直接依賴關系。請注意，這些依賴關系可能有其自己的依賴關系。此外，AssetImporter API可用于查詢分配有任何特定對象的AssetBundle。
通過組合AssetDatabase和AssetImporter API，可以編寫一個編輯器腳本，以確保將所有AssetBundle的直接或間接依賴關系分配給AssetBundles，或者沒有兩個AssetBundle共享尚未分配給AssetBundle的依賴關系。由于復制資產的內存成本，建議所有項目都有這樣的腳本。
4.5.2。雪碧地圖集重復
任何自動生成的精靈圖集將被分配給包含從其生成精靈圖集的精靈對象的AssetBundle。如果精靈對象被分配給多個AssetBundles，那么精靈圖集將不會被分配給一個AssetBundle并且將被復制。如果Sprite對象未分配給AssetBundle，則精靈地圖集也不會被分配給AssetBundle。
為了確保精靈圖集沒有重復，請檢查標記在同一精靈圖集中的所有精靈是否被分配到同一個AssetBundle。
請注意，在Unity 5.2.2p3及更早版本中，自動生成的精靈地圖將永遠不會分配給AssetBundle。因此，它們將被包含在包含其組成精靈的任何AssetBundles中，以及任何引用其組成精靈的AssetBundles中。由于這個問題，強烈建議所有使用Unity的sprite打包程序的Unity 5項目升級到Unity 5.2.2p4,5.3或任何更新版本的Unity。
4.5.3。Android紋理
由于Android生態系統中的設備碎片較多，通常需要將紋理壓縮為多種不同的格式。雖然所有Android設備都支持ETC1，但ETC1不支持帶alpha通道的紋理。如果應用程序不需要OpenGL ES 2支持，則解決該問題的最簡單方法是使用所有Android OpenGL ES 3設備支持的ETC2。
大多數應用程序需要在ETC2支持不可用的舊設備上發貨。解決此問題的一種方法是使用Unity 5的AssetBundle變體（有關其他選項的詳細信息，請參閱Unity的Android優化指南）。
要使用AssetBundle變體，所有無法使用ETC1進行干凈壓縮的紋理必須分離為僅紋理的AssetBundles。接下來，使用特定于供應商的紋理壓縮格式（如DXT5，PVRTC和ATITC）創建足夠的這些AssetBundles變體以支持Android生態系統的非ETC2功能片。對于每個AssetBundle Variant，將包含的紋理的TextureImporter設置更改為適合Variant的壓縮格式。
在運行時，可以使用SystemInfo.SupportsTextureFormat API 檢測對不同紋理壓縮格式的支持。應該使用此信息來選擇和加載包含以受支持格式壓縮的紋理的AssetBundle Variant。
有關Android紋理壓縮格式的更多信息可以在這里找到。
4.5.4。iOS文件句柄過度使用
Unity的當前版本不受此問題影響。
在Unity 5.3.2p2之前的版本中，Unity會在AssetBundle加載的整個過程中持有一個打開的文件句柄。這在大多數平臺上都不是問題。但是，iOS將進程可能同時打開的文件句柄數限制為255.如果加載AssetBundle會導致超出限制，則加載調用將失敗，并顯示“Too Many Open File Handles”錯誤。
對于嘗試將內容分成數百或數千個AssetBundles的項目，這是一個常見問題。
對于無法升級到補丁版本的Unity的項目，臨時解決方案是：
通過合并相關的AssetBundles來減少使用的AssetBundles的數量
使用AssetBundle.Unload（false）關閉AssetBundle的文件句柄，并手動管理加載的對象的生命周期
4.5。AssetBundle變體
AssetBundle系統的一個關鍵特性是引入了AssetBundle變體。變體的目的是允許應用程序調整其內容以更好地適應其運行時環境。當加載對象和解析實例ID引用時，變體允許不同的AssetBundle文件中的不同UnityEngine.Objects顯示為“相同”對象。從概念上講，它允許兩個UnityEngine.Objects顯示為共享相同的文件GUID和本地ID，并標識實際的UnityEngine.Object以字符串變體ID加載。
這個系統有兩個主要用例：
-
變體簡化了適用于給定平臺的AssetBundles的加載。
- 示例：構建系統可能會創建一個AssetBundle，其中包含適用于獨立DirectX11 Windows版本的高分辨率紋理和復雜著色器，以及適用于Android的具有較低保真度內容的第二個AssetBundle。在運行時，項目的資源加載代碼可以為其平臺加載相應的AssetBundle Variant，并且傳遞到AssetBundle.Load API的對象名稱不需要更改。
-
變體允許應用程序在同一平臺上加載不同的內容，但使用不同的硬件。
這是支持各種移動設備的關鍵。在任何真實世界的應用程序中，iPhone 4都不能像最新的iPhone一樣顯示相同的內容保真度。
在Android上，AssetBundle Variants可用于解決設備間屏幕縱橫比和DPI之間巨大的分割問題。
4.5.1。限制
AssetBundle Variant系統的一個關鍵限制是它需要使用不同的資產來構建變體。即使這些資產之間的唯一差異是其導入設置，也適用此限制。如果內置到變體A和變體B中的紋理之間的唯一區別是在Unity紋理導入器中選擇的特定紋理壓縮算法，則變體A和變體B必須仍然是完全不同的資產。這意味著變體A和變體B必須是磁盤上的單獨文件。
這種限制使大型項目的管理復雜化，因為特定資產的多個副本必須保存在源代碼管理中。當開發人員希望更改資產的內容時，必須更新資產的所有副本。這個問題沒有內置的解決方法。
大多數團隊都實施他們自己的AssetBundle變體形式。這是通過建立AssetBundles來完成的，后者在文件名后面添加了明確的后綴，以便識別給定AssetBundle所代表的特定變體。在構建這些AssetBundles時，自定義代碼以編程方式更改包含的資產的導入器設置。一些開發者已經擴展了他們的定制系統，以便能夠改變附屬于預制件的組件上的參數。
4.6。壓縮還是未壓縮？
是否壓縮AssetBundles需要一些重要的考慮因素，其中包括：
加載時間：從本地存儲或本地緩存加載時，未壓縮的AssetBundles比加載壓縮的AssetBundles要快得多。
構建時間：在壓縮文件時，LZMA和LZ4非常緩慢，Unity Editor按順序處理AssetBundles。具有大量AssetBundles的項目將花費大量的時間壓縮它們。
應用程序大小：如果AssetBundles在應用程序中發貨，則壓縮它們將減少應用程序的總大小。或者，可以在安裝后下載AssetBundles。
內存使用情況：在Unity 5.3之前，所有Unity的解壓縮機制都要求在解壓縮之前將整個壓縮的AssetBundle加載到內存中。如果內存使用率很重要，請使用未壓縮或LZ4壓縮的AssetBundles。
下載時間：如果AssetBundles很大，或者用戶處于帶寬受限的環境中，例如在低速或計量連接上下載，則壓縮可能只需要。如果只有幾兆字節的數據通過高速連接傳送到PC，則可能會忽略壓縮。
4.6.1。緊縮壓縮
主要由使用Crunch壓縮算法的DXT壓縮紋理組成的束應該被構建為未壓縮的。
4.7。AssetBundles和WebGL
Unity強烈建議開發人員不要在WebGL項目上使用壓縮的AssetBundles。
WebGL項目中的所有AssetBundle解壓縮和加載必須在主線程上進行。這是因為Unity的WebGL導出選項當前不支持工作線程。AssetBundles的下載使用XMLHttpRequest委托給瀏覽器，XMLHttpRequest在Unity的主線程上執行。這意味著壓縮的AssetBundles在WebGL上加載非常昂貴。
如果您使用的是Unity 5.5或更高版本，請考慮避免使用LZMA作為您的AssetBundles，并使用LZ4進行壓縮，而不是按需解壓縮。如果您需要較小的壓縮大小，那么LZ4會提供，您可以配置您的Web服務器以在HTTP協議層面（在LZ4壓縮之上）對文件進行gzip壓縮。Unity 5.6將LZMA作為WebGL平臺的壓縮選項進行刪除。
