Addressable: download from remote

Posted by alex57 on Sun, 20 Feb 2022 17:01:32 +0100

Difference between Local and Rmote

As mentioned in the first article, click the grouping tab to see where the AB package will be hit and loaded from in the Inspector. If it is local, the packaged AB will be in the APK package, not remote. Loading remote from APK will be downloaded from the server.

Open Remote: find the Addressable Asset Settings file and select Remote for build & load paths
In addition, we checked Disable Catalog Update On Startup here, mainly because we control the files to be updated by our later code.

The remote data will be cached after being downloaded locally, and will be read from the cache every time in the future. If the cache is deleted, it will be read from the server again.
Note: if the Remote type turns off the option shown in the figure below, it will not be cached locally, but downloaded from the server every time.

Difference between Can Change Post Release and Cannot Change Post

You can see that there is also an update restriction option in the Content Update Restriction above. You can select the following two options:
Can Change Post Release:
If the resources are updated subsequently, they will be updated in full (directly replacing the old resources)
Cannot Change Post Release:
If the resources are updated subsequently, they will be updated incrementally (the old resource package will not be changed, and the changed content will be loaded with the new resource package)

The difference between the two can be seen in the following steps of updating AB package.

Update AB package

If we have already sent an APK package, the type of AB package includes both Local and Remote; There are both Can Chage and Cannot Change types. Where will APK load these AB packages? As mentioned earlier, Local will enter APK, so it will be placed locally, and Remote will be placed on the Remote server. When in use, it will be downloaded from the Remote server, and the option of whether to cache or not will be provided.

So now update AB package, what will we do?

  1. Select tool check for content update restrictions

After clicking, a dialog box will pop up asking you to select the package generated before bin file Then the following interface will appear

Note: here, you will change the Asset and the grouping option is the package of Cannot Change Post Release (the package to be updated incrementally). Select it, and then click apply change in the lower right corner, and a new grouping ContentUpdate will appear. The grouping package will be printed in Remote and then placed on the server to update the original, whether in Local or not, Or Remote's Cannot Change package.

The package of Can Change will directly generate a new Bundle. When the Catalog is updated by the old APK, resources can be read from the new Bundle.

  1. Select build clean build, clear the old local resource package, then clear the server resource package of ServerData, and then select Update a Previous Build. Similarly, select the package generated before bin file. At this time, it becomes a new AB package.

Load AB package

Here, go directly to the code and check what needs to be updated first.

 private List<object> _updateKeys = new List<object>();
 
 private async void UpdateCatalog()
    {
        //Initialize Addressable
        var init = Addressables.InitializeAsync();
        await init.Task;
        
        //Start connecting to the server to check for updates
        var handle = Addressables.CheckForCatalogUpdates(false);
        await handle.Task;
        Debug.Log("check catalog status " + handle.Status);
        if (handle.Status == AsyncOperationStatus.Succeeded)
        {
            List<string> catalogs = handle.Result;
            if (catalogs != null && catalogs.Count > 0)
            {
                foreach (var catalog in catalogs)
                {
                    Debug.Log("catalog  " + catalog);
                }
                Debug.Log("download catalog start ");
                var updateHandle = Addressables.UpdateCatalogs(catalogs, false);
                await updateHandle.Task;
                foreach (var item in updateHandle.Result)
                {
                    Debug.Log("catalog result " + item.LocatorId);
                    foreach (var key in item.Keys)
                    {
                        Debug.Log("catalog key " + key);
                    }
                    _updateKeys.AddRange(item.Keys);
                }
                Debug.Log("download catalog finish " + updateHandle.Status);
            }
            else
            {
                Debug.Log("dont need update catalogs");
            }
        }
        Addressables.Release(handle);
    }

Then download the new AB package:

 public void DownLoad()
    {
        StartCoroutine(DownAssetImpl());
    }
    
    public IEnumerator DownAssetImpl()
    {
        var downloadsize = Addressables.GetDownloadSizeAsync(_updateKeys);
        yield return downloadsize;
        Debug.Log("start download size :" + downloadsize.Result);

        if (downloadsize.Result > 0)
        {
            var download = Addressables.DownloadDependenciesAsync(_updateKeys, Addressables.MergeMode.Union);
            yield return download;
            //await download.Task;
            Debug.Log("download result type " + download.Result.GetType());
            foreach (var item in download.Result as List<UnityEngine.ResourceManagement.ResourceProviders.IAssetBundleResource>)
            {
                var ab = item.GetAssetBundle();
                Debug.Log("ab name " + ab.name);
                foreach (var name in ab.GetAllAssetNames())
                {
                    Debug.Log("asset name " + name);
                }
            }
            Addressables.Release(download);
        }
        Addressables.Release(downloadsize);
    }

The original AB package can be updated normally in Remote, and the original Local and cannot change can also be seen in the packaging process. The newly generated ContentUpdate package is placed in Remote. Can be updated.
Only Local and Can Chage old packages cannot be updated, and only new packages can be loaded normally.

Examples

Four prefabricated bodies are newly built and placed in four groups:
LocalStatic: local, Cannot Change Post Release
LocalNoStatic: local, Can Change Post Release
RemoteStatic: remote, Cannot Change Post Release
RemoteStatic: remote, Can Change Post Release

Click AB to see the local AB:

Remote AB:
There will be a catalog's hash and json files

Then put a NetBox2 directly in ServerData, start the application, and we can directly access localhost on the local machine.
Here, for convenience, you can directly print an application on the Window platform. You can see that all four prefabs have been loaded.

To prove that the Remote packet is loaded and downloaded from the server, turn off NexBox2 and clear the cache (download it for the first time and cache it locally). It was found that the Prefab of Remote could not be loaded.

Update AB:
Here, I reduce the height of the four Prefab in general, and then update the AB package according to the above method of updating the AB package.

Then operate on the old package just now, first UpdateCatalog, and then DownLoad AB
Load four prefabs again:

You can see that all four prefabs have changed, and only LocalNoStatic has not changed. As explained earlier, the update AB of Local type Can Change Post Release is not generated in the contentupdate group, but the old path becomes the path in the new catalog, so the Prefab is lost.

The local non static Group cannot be updated by the AA system. If you accidentally change to this Group and use Update a Previous Build, the client will be inexplicably unable to load resources, so you are strongly opposed to using this Group This Group is also ignored in official documents

If a new package is played out, all four prefabs are loaded normally.

Example project:

reference resources:
https://blog.csdn.net/qq_14903317/article/details/108529590#comments_20052993

Topics: Unity Addressable