Update bundle contains only changed content, old cache auto replaced

[andrew_pearce_1]

Hello,

I am experimenting with Addressables loaded from server. Everything worked fine until I tried to change a single sprite in a bundle and created an update. Once I provided addressables_content_state.bin file, I got a new asset bundle but its size was almost the same as old one (looks like all content was copied there).I was hoping that newly created asset bundle would contain a single sprite which was changed and that user will later download that update bundle and use it as a patch for existing asset bundle. What I am doing wrong?

Also, I found that when user gets an update from server, the old one remains in cache (I can see it in cache folder, Debug.Log(Caching.GetCacheAt(0).path)) and causes app to increase in size. Temporarily, I use only file name for a bundle name, as a result all version will go to the same folder and since I know that Unity will append “_assets_all” to folder name, I can use this short code to delete the old cache:

    List<Hash128> listOfCachedVersions = new List<Hash128>();
    Caching.GetCachedVersions("sprites_assets_all", listOfCachedVersions);
    if (listOfCachedVersions.Count > 0) {
      Hash128 lastHash = listOfCachedVersions[listOfCachedVersions.Count - 1];
      Caching.ClearOtherCachedVersions("sprites_assets_all", lastHash);
    }

Looks like I am reinventing the wheel… How can I configure addressables to have two possible scenarios:

1. The update bundle contains only changed content?

2. The update bundle contains all content but downloading update should delete previously cached one?

3. How should I use Cache.ClearCache()? If I used 1st scenario, at certain moment, the amount of requests to download asset bundle and its patches may take too long, so I will make a new app release with freshly rebuild addressables? I believe cache from old builds will be kept there by default =(

Thanks in advance

UPD: I just got an idea, may be I overestimated the abilities of Unity to create an update and what they meant in documentation is that if I split content into bundles (for example by label), then only those bundles will be update and the rest will remain unchanged? If my assumption is true then I would like to know, is there any better (intended) way to delete old version of cached bundles than the solution above? At least, is there any way to get a bundle name from AssetReference or AssetKey without assuming that it will be group name + “asset” and then either “all” or “group label”? Thanks

[Thermos]

This is a bug of Scriptable Build Pipeline, which Addressable Team said it relates to the internal engine code and they are working actively on this. The old way of building asset bundle can already handle these cases, there is no reason SBP does not support it.

[andrew_pearce_1]

@Thermos Thanks for your reply! I have couple of more questions:

1. I like this bug and how can I tell Addressable that every time I create update, I want all assets to be copied to update bundle? That will increase download size but I can easily delete old cached bundles as they are no longer in use

2. Is there any way to tell Addressable to skip checking for an update and instead load from local bundle? I think checking once per hour or even per day is more than enough and will save server for unnecessary load.

3. Why Caching.cacheCount is always 1? Even when I have couple of different bundles cached.

4. Could you please tell me a bit more about “old way of building asset bundle”? I am still using local AssetBundles to load assets async.

Thanks in advance for your help

p.s. I did some tests and confirm that even when you build new app with new asset bundles, the old ones are still there and increase app size. I cannot find any intended way to get bundle name from asset key but the one I mentioned in my question works fine.

[Thermos]

After switch to addressable, I always clean cache before build, after click build button, just go to sleep…

Asset bundles build from SBP(which addressable system is using) are different, for example there is no more manifest file.

Before Addressable, I use Asset Bundle Browser to build bundles, the system can finds out which bundles are changed, which are not. So if you change one sprite, the build process won’t take you more than 2 minutes because it only build one bundle instead of rebuild all of them.

SBP should be able to do it since it’s an upgrade. Those opening bug reports can confirm it.

[andrew_pearce_1]

@Thermos Thanks, that’s exactly what I am using too “Asset Bundle Browser” (ABB) and only recently found that it is able to skip bundle generation if nothing changed.

BTW I just did couple of tests with Addressable and they are extremely slow. I understand that with remote bundles you need to make a request to a server. At first, it seemed like they cache the request time and if you restart the app, they load local bundle instead of making a request to a server again. I got 2.8 sec instead of 5.5sec to load a single sprite after app was restarted on an Android, which is still not fast enough.

Then I switch Addressable to local build to check will that speed up the process (as no request to server should be made). The result was that loading a single sprite was taking the same 2.8sec. Then I tried my old code which was loading data from Asset Bundles via UnityWebRequestAssetBundle, which also caches bundle in Cache folder and it was much faster, just 1.5 sec.

The question is, what I am doing wrong or is it really worth to switch to Addressable? I am very frustrated that I cannot load Asset Bundles in Task to implement proper multi threading =( I am forced to use Coroutines which I are hard to control (detect when they finished) and hard to get a result (only via passing lambdas).

[Thermos]

Disable CRC check on group settings, that’s very slow.

[andrew_pearce_1]

That sound logical… do you mean this one?

I tried but it did not help

[Thermos]

Sorry, I missed the line you mentioned you are testing this on android. Actually, there is another opening bug report said loading on android is slower than before… Link

[andrew_pearce_1]

Thanks @Thermos , then I think it’s too early to use Addressable. I thought since last year, when I tried it for the first time, they fixed major issues but I was wrong =) I will try to add caching to my existing code which works fine. BTW since you also use Asset Bundles in your projects, do you use caching or only local bundles?

[Thermos]

I use only local bundles and our game targets PC so currently addressable works for me, although the build time is long but it’s OK for me since we only build once per day.

[andrew_pearce_1]

Thanks again @Thermos , you save my time! For loading local bundles do you use
AssetBundle.LoadFromFileAsync or UnityWebRequestAssetBundle.GetAssetBundle? Also, which compression method do you prefer? I found that LZMA requires bundle to be decompressed and saved in cache before it can be loaded. So basically we double the size of assets.