I’m not in a rush for the project recently, and I plan to take some time to continue writing some summaries of Unity, so I want to finish summarizing Addressables first. The previous two articles roughly explained an operation process of Addressables hot update. I believe everyone already knows how to use Addressables. This article is mainly for supplementary purposes. If there are changes in the future, it will continue to be updated.
1. Let’s talk about the size of the package first, which can be roughly classified as follows, that is, some projects may provide a complete package for channel review, including all resources in the package body, commonly known as a large package.
Going back to point 7 of the Addressables summary (1), I mentioned the use of Cannot Change Post Release. How does it work?
Here we take the Group of Prefabs as an example, change all the Groups in your Addressables to the above settings, and the typed AB package will be typed into the package body. It should be noted that in the setting interface, we still use the Remote address, because we will continue to do resource updates in the future:
Next, we randomly modify the resources in one or N groups, and then perform the operation Tools->Check for Content Update Restrictions, and you can see that it will generate a new Group, as shown in the figure below (here I directly take the previous picture as a schematic):
This is generated by Addressables by default for us, but there will be some problems. Every time we have a new hot update resource, it will not use the generated Group, but generate a new Group. We know that the large package mode will put all resources into the package body. However, the newly generated Group defaults to Remote instead of Local addresses. If you use the large package mode later, you cannot enter the package body unless you modify them one by one... In addition, there is a fatal problem. Here is another very troublesome thing. For this reason, I have optimized the problem of generating groups for hot update of large packages. The following is the code:
public static void CheckAddressablesLocalAndUpdate()
{
updateContents = new Dictionary<string, HashSet<AddressableAssetEntry>>();
var path = ContentUpdateScript.GetContentStateDataPath(true);
if (string.IsNullOrEmpty(path))
Debug.LogWarning("No path specified for Content State Data file.");
else if (!File.Exists(path))
Debug.LogWarningFormat("No Content State Data file exists at path: {0}");
else
{
var settings = AddressableAssetSettingsDefaultObject.Settings;
var modifiedEntries = ContentUpdateScript.GatherModifiedEntriesWithDependencies(settings, path);
foreach (var k in modifiedEntries.Keys)
{
Debug.Log("modified key:" + k.address+" and parentGroup:"+ k.parentGroup.Name);
if (!updateContents.ContainsKey(k.parentGroup.Name))
updateContents[k.parentGroup.Name] = new HashSet<AddressableAssetEntry>();
updateContents[k.parentGroup.Name].Add(k);
foreach (var child in modifiedEntries[k])
updateContents[k.parentGroup.Name].Add(child);
}
foreach (var groupName in updateContents.Keys)
{
var newGroupName = "HotUpdate" + groupName;
var group = settings.FindGroup(newGroupName);
if (group == null)
{
group = settings.CreateGroup(newGroupName, false, false, true, null);
var schema = group.AddSchema<BundledAssetGroupSchema>();
schema.BuildPath.SetVariableByName(settings, AddressableAssetSettings.kRemoteBuildPath);
schema.LoadPath.SetVariableByName(settings, AddressableAssetSettings.kRemoteLoadPath);
schema.BundleMode = BundledAssetGroupSchema.BundlePackingMode.PackSeparately;
schema.AssetBundledCacheClearBehavior = BundledAssetGroupSchema.CacheClearBehavior.ClearWhenWhenNewVersionLoaded;
schema.UseUnityWebRequestForLocalBundles = true;
schema.RetryCount = 5;
group.AddSchema<ContentUpdateGroupSchema>().StaticContent = false;
}
Debug.Log("from:" + groupName + " move to:" + group.Name);
settings.MoveEntries(updateContents[groupName].ToList(), group);
}
//ContentUpdateScript.BuildContentUpdate(settings, path);
}
}To put it simply, according to the change of resources, I added a HotUpdate prefix to the name of the original Group as the name of the new Group. Finally, I commented out the code for automatically packaging the AB package. I personally think that it is safer to manually operate the AB package after confirming it. After this operation, the packaged package will probably look like the following picture:
Is this much clearer? Then, if our project progresses to the next version and we need to re-package it for review, we can move the resources back to the original position with one click and then re-package the AB package. The code moved back is relatively simple, so I won’t post it here, which basically solves the problem of the big package mode.
2. The problem of resource redundancy. Regarding the problem of resource dependence, I think everyone may know more or less, so I won’t go into details here. In short, when we use AB packages, there will definitely be some resources that are repeatedly packaged. The total amount of the entire AB package is too large. What I am mainly talking about here is the solution. First, open the Analyze resource analysis tool in Tools, and you can see that there are four Rules:
<1> Check Duplicate Bundle Dependencies: Check the repeatedly dependent resources in the AB package. This is the most useful when doing resource optimization at the beginning. You can clearly see a lot of repeatedly dependent resources, and then plan the resources yourself
<2> Check Resources to Addressable Duplicate Dependencies: Check whether there are duplicate dependencies in the resources in the AB package and the Resources folder
<3> Check Scene to Addressable Duplicate Dependencies: Check whether there are duplicate dependencies in the scenes in the AB package and the scene list of the Unity editor
<4> Bundle Layout Preview: Ontology and dependencies of the AB package
I guess the usual method for projects is to package each resource separately, because it is simple and trouble-free and can maximize redundancy, but this will also have some problems: 1. Too many scattered resources affect the download speed, 2. The metadata overhead of too many AB packages will take up a lot of memory.
It can be seen that it is also necessary to control the number of AB packages. If there are not many project resources, they can be packaged separately. If there are many, you may need to plan the resources yourself. If you want to achieve the ultimate memory optimization effect, you have to find a way to combine packages. This will be a little troublesome, but the effect will be immediate.
Here is an article officially explained by Unity. If you are interested, you can read it. It is estimated that it can deepen your understanding: Memory is in a hurry? You Need This Addressables System Memory Savings Guide