The resource version management we expect includes several aspects: Can be updated across versions,Can be rolled back to versions, and can dynamically modify the update address< /strong>.
Version definition:
The version number should be upgraded every time the game is updated. The client should theoretically have two version numbers: Frame Version (FrameVersion) and Resource Version (BundleVersion).
Framework version represents the version of resources that cannot be changed, such as game engines and game C# codes.
Resource version represents the version of movable resources, such as game models and Lua codes. Due to the existence of the update mechanism, it can be divided into base resource version (resources included with the game) and cached resource version (resources downloaded through update).
Therefore, we define the framework version in the C# code, and the resource version in the Lua code.
Every time you update the framework, you need to increase the framework version number. Every time you update the resources, you need to increase the resource version number.
In addition, every time it is updated, the latest updated resource version number is stored locally as CachedBundleVersion.
Cross-version update:
According to our usual update process, when a version C is printed, the differences between all previous versions A and B will be compared, and then multiple update directories A-C and B-C will be generated for incremental updates of different versions.
AAS itself has no version concept in its design, and all resources are uniformly recorded and managed by Catalog. When updating, you must first download the latest Catalog, then traverse the resources in the latest Catalog to determine which resources are not the latest, and you need to download them again. Therefore, AAS is not updated from the version level, but from the resource level.
Therefore, AAS itself can support cross-version updates, and the server only needs to save a copy of the latest resources.
Version rollback:
Same as cross-version update, because it is an update at the resource level, you only need to replace the resources with the resources of the old version to achieve version rollback. (Since the resource version is defined in the Lua file, simple resource replacement cannot implement the rollback operation, and the version rollback function is not provided yet)
Dynamic modification update address (redirect):
According to our general practice, after entering the game, check for updates, obtain the latest version and resource address, and then download the resources. The update address of AAS is currently hard-coded in the configuration. Even if AAS provides runtime address configuration, it must be called before AAS is initialized to be effective, which is quite demanding.
Therefore, it is impossible to update the address through configuration, and currently we have found other solutions to dynamically modify the address. The method is also the InternalIdTransformFunc function mentioned above by Hook, because all address positioning must go to this function. , including the updated address of the Catalog.
In addition, each group is also configured with its own remote download address in the Catalog, so the bundle update address also needs to be redirected.
Sample code:
private static string InternalIdTransformFunc(UnityEngine.ResourceManagement.ResourceLocations.IResourceLocation location)
{
if (location.Data is AssetBundleRequestOptions)
{
//bundle update address redirection
if (CustomRemoteUrl.Length != 0 & amp; & amp; location.InternalId.StartsWith("http://"))
{
return string.Format("{0}{1}", CustomRemoteUrl, location.PrimaryKey);
}
}
else if (location.InternalId.Contains("/catalog")) // catalog address redirection
{
if (location.InternalId.StartsWith("http://")) // catalog update address redirection
{
if (location.InternalId.EndsWith(".json"))
{
return string.Format("{0}catalog_{1}.json", CustomRemoteUrl, CachedBundleVersion);
}
else if (location.InternalId.EndsWith(".hash"))
{
string.Format("{0}catalog_{1}.hash", CustomRemoteUrl, CachedBundleVersion);
}
}
}
return location.InternalId;
}
In this case, we get the update address CustomRemoteUrl and Catalog version number CachedBundleVersion (cached resource version number) from the server, and then we can update the resource from the specified address.
When AAS is packaged, various addresses of the Catalog are automatically configured (the default configuration file is in “{Addressables.RuntimePath}}/setting.json”, and the path in Windows is “Library/com.unity.addressables/aa/Android/settting.json” ), including catalog’s remote request address, original catalog address (printed with the package), catalog’s local cache address, as shown below:
We specify a version number for the catalog, so the name of the catalog (catalog_x.x.x.x.json) will change each time it is packaged. If you only implement the above remote download redirection, when the game is updated from version 1.0.0.0 to version 1.0.0.1, the latest version of catalog_1.0.0.1.json has been downloaded to the cache directory, but if you run it directly at this time, due to AAS records the cache address of the catalog as “{UnityEngine.Application.persistentDataPath}/com.unity.addressables/catalog_1.0.0.0.hash”, so if no processing is done, the resource of version 1.0.0.0 will be loaded directly. Rather than version 1.0.0.1 resources, we need to redirect the local cache address of the catalog.
The sample code is as follows:
private static string InternalIdTransformFunc(UnityEngine.ResourceManagement.ResourceLocations.IResourceLocation location)
{
if (location.Data is AssetBundleRequestOptions)
{
//bundle update address redirection
if (CustomRemoteUrl.Length != 0 & amp; & amp; location.InternalId.StartsWith("http://"))
{
return string.Format("{0}{1}", CustomRemoteUrl, location.PrimaryKey);
}
}
if (location.InternalId.Contains("/catalog")) // catalog address redirection
{
if (location.InternalId.StartsWith("http://")) // catalog update address redirection
{
if (location.InternalId.EndsWith(".json"))
{
return string.Format("{0}catalog_{1}.json", CustomRemoteUrl, CachedBundleVersion);
}
else if (location.InternalId.EndsWith(".hash"))
{
return string.Format("{0}catalog_{1}.hash", CustomRemoteUrl, CachedBundleVersion);
}
}
else if (location.InternalId.EndsWith(".hash")) // Local cache catalog path redirection
{
return Regex.Replace(location.InternalId, @"/catalog_.*\.hash", string.Format("/catalog_{0}.hash", CachedBundleVersion));;
}
}
return location.InternalId;
}
Covering installation issues:
Consider the case of an overlay installation:
The player first installed an initial package (framework version: 1.0.0.0, bottom package resource version 1.0.0.0), and then updated the resources of version 1.0.0.1 through dynamic updates, so the current version information is: framework version 1.0.0.0, bottom package resource version 1.0.0.0 Package resource version 1.0.0.0, cache resource version 1.0.0.1. At this time, if the player downloads a latest version package from the app store (framework version: 1.0.0.2, bottom package resource version 1.0.0.2), so the current game version information is: framework version 1.0.0.2, bottom package resource version 1.0.0.2 , cache resource version 1.0.0.1. The current CachedBundleVersion=1.0.0.1, so if no processing is done, the resources will use the cache resources of 1.0.0.1 when the game starts. At this time, although the game has downloaded the latest game package, But the old game resources are still used.
Therefore, when we start the game (before initializing AAS), we need to compare the base resource version number and cache resource version number. If the base package resource version number > the cache resource version number You need to clear the Catalog cache to avoid using old cache files.
The bottom package resource version number can be identified by reading the catalog version number in the “Addressables.RuntimePath/setting.json” file inside the package.
The cached resource version number is stored locally every time it is changed.