Anyone else have an issue with an Addressable bundle being say 50mb and shows as 50mb in the editor but showing as 100mb when being loaded on an android device?
It actually isnt coming from the download it is coming from:
AsyncOperationHandle<IList> handle = Addressables.LoadResourceLocationsAsync(key, typeof(GameObject));
I have 11 addressables and it is returning the list as 22?
Could this be because I am loading them in one scene and then loading the next scene where they are being instantiate?
I was using 1.16.15 and had this issue. I tried the 1.17.2-preview and this issue was resolved.
Nevermind. Built new ones and it went back to double. Weird that the old build worked until I rebuilt it again.
How curious! Let me flag this with the team.
Just a couple questions, some I think I know but just want to double check:
- Does the result of your LoadResourceLocations look like some of the entries are purely duplicates or are there multiple results that point to the same asset but differ in the key or something?
- Just to double check, you’re saying you only get 22 results from LoadResourceLocations on Android? On other platforms you’re only getting 11 results?
Not sure if I have any great insights at the moment but those answers might help point me to some idea.
That’s the weird part and I’m not sure why. They are exact duplicates when I do a debug on the entries. But when I’m creating a list of IResourceLocations and I try to not Include others if it’s already in the list, but it still adds it like it’s unique.
This also happens in the editor. That’s how I am able to show a count of entries. And it returns 22 when there are only 11 addressable’s in the group.
I was reading in another post similar issues and wonder if it has to do with the fact that I am loading in 1 scene and using in the next scene (which that scene is also an Addressable) could that be the case? If 2 scenes use addressable’s should it be looking at it as double the addressable’s?
I will take some screenshots of the group and the output and the part of the script I am using.
Having the same issue. iOS adressables are 130MB and android 260MB
I think there a lot of issues with accurate file sizes with addrssables. I just changed to mobile service to download the same addressables only this time not on WiFi. WiFi it tells me the size is 54.9mb and on mobile service it is telling me that it is 82.3mb. Nothing different about the addressables other then WiFi vs Mobile Service.
Is there a reason why addressable file size would be different just because its not WiFi and Mobile Service?
When building the addressables for iOS the same addressables build as 164.4mb. 
Ok, this is super interesting. Sounds like there’s definitely a bug in Android build. Hopefully hopefully it’s something on our end that we can fix pretty easily. Otherwise there may be something on the platform side (ie engine side) that needs to be dealt with. Probably something on our end though.
I’ll make a ticket but it might help if some bugs get filed from you all as well. I have limited context and no repro project so it might be difficult for us to track down.
@mrekuc Um, not to my knowledge. We build that info as part of some meta data regarding the AssetBundle build and store it in AssetBundleRequestOptions which we serialize out (I think as part of the catalog). That’s pretty weird you’re seeing straight up different numbers. Not sure what’s going on there honestly.
I can’t get you the actual project but I will get some assets and use the same scripts I am using. Hopefully that helps.
1 Like
Hey all, I’m posting this around in a couple different threads but I thought it might help some (probably not all) that are experiencing significantly larger Android builds. So, a big difference I noticed in some test builds was in regards to shaders. Any bundle where a shader was included, either explicitly or implicitly, were quite a bit larger than the exact same build on Standalone. This is because Android includes multiple graphics APIs in the build by default where as Windows standalone includes only one.
Default Android Graphics APIs: OpenGLES 2, OpenGLES 3
Default Windows Graphics APIs: DX11
This definitely affects the size of those AssetBundles which impacts your overall build size. If you want to remove one of these graphics APIs or change one/both of them out for Vulkan you can do so in the Player Settings under the Other Settings area.
Just as an example, for me an AssetBundle that had 5 shaders in it was 193kb by default on Android but shrunk to 77kb after removing OpenGLES 2. So, this can be significant.
Note: There is a bug right now in Scriptable Build Pipeline where changing the graphics APIs won’t affect the AssetBundle build size. You can work around this by clearing the build cache prior to building (Build → Clean Build → All OR Build Pipeline Cache). Then when doing a build the AssetBundle build size should change.
SBP already has a fix for this and they’re working to release it soon. Addressables will get updated to use the new SBP when it’s available.
If this doesn’t appear to fix your issue know we’re still looking into potential issues but it really helps if you can file a bug with a good repro project.
@mrekuc I don’t imagine my post above fixes your issue (I mean I hope it helps but it sounds like you’re seeing something totally different). I’ve been trying to reproduce your issue where you’re seeing double the Resource locations in Android as opposed to other platforms but haven’t had any luck. If you’re still having that issue feel free to file a bug with your project if you haven’t already so we can get a good repro going. Sorry we weren’t able to reproduce it on our end.
I also have this. Upgrading my app from 2020.2 to 2020.3 sometimes doubles size, sometimes doesnt
@davidla_unity i’m having the same or similar issue. Would you be able to help please?
-
Build addressables (iOS or Android).
-
Upload to S3.
-
Use
GetDownloadSizeAsyncon remote file and the size is doubled what it actually is.
Additional info
-
Unity 2020.3.11f1
-
Addressables Package - Currently 1.18.19 but have tried several from latest to verified.
-
Remote server is Amazon S3.
-
Size response is always double on all targets (Editor, iOS, Android).
-
Have a few different addressable groups, all become doubled.
And…
- If I change the name of the addressable file and rebuild locally and manually upload, the size is correct temporarily. But once the cloud build runs, it’s back to being doubled unless I want to rename again.
Thank you!
Hey all,
So, this is something we’ve looked into and I’m not sure we have a good solution at the moment. I’ll go into a bit of detail so it might makes a little more sense.
What I suspect is the culprit for all these issues where “the result of GetDownloadSize is different from the size of the the file downloaded” comes down to one key point: compression.
Currently there are 3 options for bundle compression on an Asset Group, LZ4, LZMA, and Uncompressed. What it doesn’t say (and I actually only recently found out myself) is that there are two different types of LZ4 compression. There’s LZ4HC which is LZ4 High Compression and LZ4Runtime. LZ4HC is what the AssetBundles actually get built to when you select LZ4 as your compression type. This results in smaller file sizes than LZ4Runtime.
Where I think this is becoming a problem is during the download and recompression. When AssetBundles are downloaded into the Cache, they are recompressed into LZ4Runtime. This compression allows for faster decompression times so loading assets won’t take as long, however, the file size on disk is larger than LZ4HC.
The problem, I think, is worse if you compress with LZMA compression. LZMA is actually a smaller file size than LZ4HC. Yet, on download, the AssetBundles are recompressed to LZ4Runtime (and I think on some platforms is actually might stay on disk as Uncompressed, I’d have to double check that though).
So, why don’t we just have GetDownloadSizeAsync return the file size of the LZ4Runtime files since that’s what ultimately ends up on disk? I asked that myself. The issue is that there’s no way to know the LZ4Runtime size without actually building the AssetBundles with that compression mode. So to get that data we’d have to do 2 completely separate builds, one of which would be to just get a little piece of data to store. Not ideal, for sure.
One option is a solution in two parts:
- We document this better, and not just in the manual, but the API docs for GetDownloadSizeAsync. We inform you that we can only provide the size of the file at build time and that the recompressed bundle is likely going to be a different size.
- AND if possible, we add LZ4Runtime as a build compression option. Then, if you really want a 1:1 download size to size on disk, you can do that with this compression mode. It would result in larger file sizes than the LZ4HC, but if you have logic that depends heavily on the use of this API maybe that’s alright.
I’m curious to hear opinions on this.
2 Likes
Thank you for this response, I will do a proper read through tomorrow. In the meantime, I need to know the size of the file on the server to inform the user how much they have to download (app is used outdoors on a mobile network). In the meantime I’m going to look at doing a web request to get this size. Do you know if there a way to get the actual bundle group file name from the catalog? This file name begins with the group name and then generated values for each time it’s built. Thanks!
You want the name of the AssetBundle? Yes… I think I can cook something up…
var loadLocations = Addressables.LoadResourceLocationsAsync("Cube");
yield return loadLocations;
foreach (var loc in loadLocations.Result)
{
foreach (var dep in loc.Dependencies)
if(dep.InternalId.EndsWith(".bundle"))
{
//Do something
}
}
this should give you all the bundle names associated with a give key (in this case the key is “Cube”). There’s no way to directly get the AssetBundle names since Addressables is meant to obscure those files from the user and mange them itself. I hope this helps!
1 Like
@davidla_unity thank you, that’s exactly what I need. Although I see the response here is also doubled. The remote bundle appears twice, perhaps this is why the size is doubled? Do you know why and does this mean Addressables is downloading 2x the data? Thanks!