AssetBundles and Caching

Hello everyone,

I have some questions about asset bundles and how they're cached.
Maybe I just missed the point and one of you will be able to enlighten me.

Isn't a previous versions of an asset bundle supposed to be deleted from the cache when a new one is downloaded ?
After a rapid test in the editor, it seems that when I download and cache a new version of an asset bundle (same url, different hash), the previous version is kept in the cache. This seems useless and will fill the cache with outdated data.
On mobile where disk space can quickly become an issue, this is very unpractical.

What's the point of BuildAssetBundleOptions.AppendHashToAssetBundleName ?
At first I thought it was nice because the bundle filename included automatically a sort of versioning info.
But then, I realized that because the bundle filename changed everytime, each update of a bundle would just sit next to the previous version in the cache.
Because there is no way of deleting a single bundle from the cache, you're left with only two options :
- Clean the whole cache every time a single bundle is updated, which is kinda stupid.
- Wait for the cache to be full so that the oldest bundles are removed, which also sucks.

Why can't you delete a cached AssetBundle from the cache ?
All those problems could be easily fixed if we could delete an assetbundle from the cache ourselves. Now that Caching.DeleteFromCache is deprecated and doesn't do anything, there is no way to do that anymore.
What if you had an asset bundle that it not used anymore ?
It's gonna sit in the cache for as short a time as the Caching.expirationDelay value you're willing to set or as long as the cache is not full.
Is there a reason this was deprecated and not replaced by anything ?

 

You are right, I had the same issue with the cache filling up.

Here's my current workaround:

Download asset bundles and save them on the file system manually. Set cache maximum size so it won't grow indefinitely. Load the bundles from the file system into unity's cache system. Whenever you update bundles (or whenever you want to), you can clear the entire cache and reload the bundles from the local file system. This lets you skip the download time. If you are wondering why you don't just load the bundle directly from the file system, it's because the bundle is compressed, so it's much faster to load from the cache because the cached version is uncompressed.

You can load directly from file system if you build the bundles without compression. This lets you skip the caching system, keep the reading performance, but then the download time will increase. You can implement your own compression and use it just for the download to fix the download time.

5.3 has new features, so here's a procedure for 5.3:

Download LZ4 compressed asset bundles and save them on the file system manually. Load bundles directly from file system. Bypass caching system entirely. You don't need the caching system with LZ4 compressed bundles because there is no decompressing performance overhead.

(I am not using 5.3 yet due to this issue: http://forum.unity3d.com/threads/unity-5-3-bundles-unable-to-open-archive-file.372799/ )

 

Thank you for your answer, I was afraid I would have to do something like that in the end.
And I was unaware of that bug, it would be nice to know if that was fixed in the version 5.3.1p4 that was just released.

Anyway, it would be nice to have an answer from an Unity staff member about the intended behaviour before resolving to managing the cache by ourselves.

 

Just as an update, I am now using asset bundles in 5.3 with no issues, and without using the caching system at all.

 

Hi koyoki -

To what platform are you deploying? When you say "no issues" do you mean within the Editor, or on your target platform?

Thanks.