My assets size in bundles is bigger than assets in app build

Hi, I try to use Addressables in my game, and noticed that my original game was smaller without them.

A small introduction in problem: most of the size of my game is Levels (one Scene represents one Level) - and all of them utilise the same list of assets (Textures, Prefabs, etc.). Levels are divided by Seasons (each Season contains 15 Levels). I decided to create one Addressable Group (one Bundle) per one Season.

So, I created 2 Addressable Groups for 2 Seasons and moved related Scenes to them.
After Build I checked "Library/com.unity.addressables/StreamingAssetsCopy/aa/iOS/iOS" folder and found, that each of my 2 bundles are around 30Mb. Then I use Analyse Tool and fixed all duplicated dependencies (moved them to separate shared bundle), after re-building my bundles were around 25Mb each (50Mb both bundles)

Then I returned to my original project without Addressables, disabled this 30 Scenes from Build Settings, created build and noticed, that this 30 Scenes in build weight 30Mb. Other words my Addressable Bundles contains +20Mb of something I don't know.

So the question is why my Scenes in App Build were less weight than same Scenes in Bundles? It looks like they contains some another Assets, or Unity compresses App Build stronger than separate Bundles?

The problem is I don't know how to check what is inside bundle (Analyse Tool says "no issues found" but it would be helpful to see what is inside the bundle). Is it possible to see bundle content? Is it possible to see bundle's tree or list of assets, included in it?

 

Have you given the "Check Scene to Addressable Duplicate Dependencies" Tool a go? If you have scenes in your build settings that share assets with addressable scenes, those assets will be duplicated.

 

Yeah, looks like "Check Duplicate Bundle Dependencies" was only a top of iceberg

After that I did "Check Resources to Addressable Duplicate Dependencies", found few problems there and fix them.

After that I did "Check Scene to Addressable Duplicate Dependencies" and found 22465 issues! And here I'm absolutely confused: first of all, most of this issues related to *.cs files - I was absolutely sure Unity doesn't put source codes into the Bundles (I thought all source codes persist in Main Build of the App) - if to believe this Analyzer - all my source codes duplicated to almost all my Bundles. Do I need to make my Scripts folder addressable as well?

My second concern is: I though if I create separate Group for Music, separate for Sounds and separate for Scenes - Unity will create dependencies between them and when I try to load scene from Scenes Bundle it automatically load Music and Sounds Bundles as Scene dependents on assets from them. But, as I see from Analyzer every Scene has duplicated sounds and music assets related to it:

 

About the .cs files: Thats a bug in the tool, it should be ignoring these.

About the second concern: I have not yet found a solution for handling groups of specific assets (like sound).

I have a similar scene structure in my project and what I did is assign every map scene a label. Then I wrote a custom tool that goes through the group of shared map assets and gives them the labels of the scenes that use them. That group is set to pack by label so when I load a map scene the addressable system will not load all the shared map assets but only those that are needed.

 

By "load" you mean loading addressable from bundle in Play Mode, or creating bundles?

My main concern now is my 15 Scenes in build were 12.5Mb, and with Addressables they turns into 21.1Mb in the bundle. I fix everything I could fix with help of Analyse Tool, but still have 21.1 - 12.5 = 8.6Mb of duplicated assets in the bundle.

And the question is how to say to Addressable System which Groups should depend on which? Because I suppose my Scenes Group depends on Models Group + Music Group + Sounds Group, but in reality Scenes Group just duplicates assets from Models, Music and Sounds Groups.

 

Ok, I made another test: I measured sizes of all builded bundles, then I put all Scenes in one Addressable Group and built one big bundle: the size of big bundle is equal to sum of separate bundles - this gives me idea that my bundles actually don't have any duplicated assets.
But, I noticed another strange thing: when I change Compression in Advanced Options to LZ4, LZMA or even Uncompressed - I always get the same size of a bundle - is it a bug? I start thinking my bundles don't compressed at all and this is why their sizes are almost twice bigger that when I use Build-In Scenes approach.

 

I was wrong about compression: messed up with Android / iOS builds and measured wrong platform haha.
Here Compression Tests:
Uncompressed: 288.9Mb
LZ4: 81.6Mb
LZMA: 23.2Mb

I finished up with LZMA compression: it gives amazing results for bundles with scenes!

 

By "load" I meant "load at runtime".

I do not know your project so I cannot really help finding out why the build size increased. I can just tell from my own experience that the scenes in build settings are packed by a different system than the asset bundle system and that the two do not talk to each other which means any asset needed by both systems will be duplicated in the build.

You should know that with LZMA compression it takes longer to decompress bundles when they are being loaded at runtime.

 

I see, thank you for clarification. I finished with Addressable Groups and satisfied with results: now my game has only few built-in scenes like loader and game lobby, all level scenes were separated by groups and their common assets moved to separate group as well. The built-in scenes and levels have some in common and (as you said) have some duplicated assets I think, but not too much. With LZMA compression overall size of the game was reduced from 100Mb to 70Mb - now it is 30Mb smaller than was without Addressables, but I didn't know LZ4 and LZMA have different decompression time at runtime and thank you that you mention this - I will pay attention to this too.

 

If you're building for WebGL, it seems to be best to build bundles uncompressed, then compress them using gzip or brotli and let the browser decompress (will need to set file headers on the content server).

I'm not sure if that also works on other platforms.