I’m encountering this issue:
I haven’t been in the profiler in a while but there is a way to list what is taking the memory… I think it might be under deep memory profiling?? It might just be lightmap data too…
I’m reading this as though @Bungno already did take a memory snapshot via the Memory Profiler Module’s detailed view. It’s a bit tricky to tell what might be going on without details as there’s a bunch of different Objects that could be related to this. My first guess would be something around serialized file sizes or something but that’s just a stab in the dark. Screenshots of the memory Profiler could help shed some light on this. Also, maybe the Memory Profiler package might make things clearer (but could also hide this memory usage a bit more if it’s coming from an odd place and the memory usage is more abstractly allocated than via actual UnityEngine.Objects )
Thanks for the reply. I’ve tried Memory Profiler package like you said, but my Unity can’t handle capturing snapshot, so I screenshotted the loading scene process on my 2 builds stated above. For more information, the app is built on Redmi Note 10, Android 11 OS, with default build settings and it has 14 scenes in total.
2. App with only one scene
Which Unity version are you using and have you tried updating to the latest supported version on the mayor unity version you are using? Capturing should always work but there were some occasional bugs that we fixed along the way.
And Others > Objects is a memory root accounting bug, i.e. something in our backend is reporting memory as rooted under the Object label incorrectly. Could you please report a bug on this?
As it stands, this is gonna be tricky to nail down until that bug is fixed but we need a repro project as there’s too many places where something might’ve gone awry and we’ll need to investigate what exactly went wrong here, to make it more actionable.
There is a chance that this particular instance of “Others > Objects is reporting memory” is fixed in later versions so upgrading might be worth a try.
Also, another stab in the dark besides Serialized File size: are you using the Resources Folder?
The version I’m currently using is Unity v2019.4.8f, and I’m sorry I can’t share repo project as it is confidential. For the time being, I’ll try upgrading to the latest version to see if this bug still continue.
Do you mind me asking another few questions regarding Unity memory management on Android/iOS? How does Unity manage memory during LoadSceneAsync? Does Resources.UnloadUnusedAssets contribute to memory spikes? And correct if I’m wrong but I notice Unity render meshes during the last frames of scene loading, so does that process cause memory spike, because these problems is causing my app to crash mainly due to memory overload.
I don’t mind, these usually also point me into good directions for where we need to clarify Documentation, Tooling and where I may need to dig a bit deeper to further my own understanding of these, I just can’t guarantee that I’ll have any good answers to these 
E.g. I only know very broad strokes of the points you mentioned, and not enough to give any guidance on the specific issues here. I’d have to (memory) profile the situation to bits too, maybe read/debug the source code along side that to figure it out myself.
The Profiler Timeline View can help in figuring out the order of events and when compared to the memory charts per frame, may be the better tool to answer this one, also version specific, as there can be changes to details of this process between versions. So besides the “exactly what it says on the tin” answer of: it loads the memory of assets needed by the scene and other contents of the scene into memory alongside existing memory, I’d only guess at the logical steps needed for that process: Read the scene file, gather all assets needed, figure out which one of these are already in memory, load them in, load in the scene hierarchy and structure, then initialize all of this (Awake(), upload needed resources (Textures, Meshes, Shaders …) to the GPU… really not sure where in the process this happens but afaik as late and as close to where it is needed as possible? So maybe that’s the rendering bits that you are seeing? Then there are questions like: does the phone you are testing on have dedicated VRAM or unified RAM (Android is a scattershot on this, iOS unified)?
Unity’s scene loading and Asset Garbage Collection logic is this:
Unless explicitly specified in your scene load API calls, only destructive (i.e. non Additive) scene loads will trigger Asset GC (aka Resources.UnloadUnusedAssets).
The Asset GC will trigger AFTER the previous scene was unloaded and the next one loaded.
This ensures that Assets that are needed in both scenes aren’t unloaded and immediately loaded again
This also means the Memory Pools may need to grow, only for the one frame where both scene’s assets are still in memory, and after that you are left with a higher memory usage watermark than needed (or, worst case scenario, crashes Out Of Memmory).
Long way to say: you may want to trigger Asset GC between scene loads/ load an empty scene in between, but you are then balancing loading time vs the high memory watermark (or not crashing OOM). Asset GC does also include Scripting GC (aka GC.Collect) (because why hold on to Asset Memory when the managed memory that was holding it isn’t needed anymore), but it doesn’t trigger automatically on high memory usage like the Scripting GC does. So, no memory spikes are caused by you calling it and no automatic CPU Usage spikes are caused down the line by you manually calling Resources.UnloadUnusedAssets, but there will likely be a CPU spike to process the Asset GC logic, and you may need to load assets back in later as needed, by e.g. subsequent scene loads.
If memory serves me right, that would be in range for one of our Memory Snapshot Capture bugs, so an upgrade to latest 2019.4.x should at least fix the memory capture logic. It’ll also give you some more data for the Memory Profiler to visualize for you, and corrected Reference reporting between native objects in those snapshots.
Side note: the Reference tracking in the later LTS versions is now using the exact same code path as the Asset GC. ensuring correctness of the data, and the Asset GC performance was improved while fixing this.
I noticed the load time between my all scenes app and my one scene app is significantly different. The one scene app load scene much faster than the other one, taking about 5 seconds, while the all scene app takes about 20-30 seconds. So I don’t think a memory root accounting bug can affect load time, but some objects from other scenes using the same meshes, textures, materials, etc. are also loaded during that scene loading, which IMO answer for objects high memory usage. Do you have any other idea regarding this problem? Thank you.
Well, there is a good chance that memory is actually used somewhere but due to the accounting bug, we don’t have any clue as to where. And no, nothing comes to mind right now 
Some updates on this issue:
If you’re still following this thread, I can provide some snaps taken during testing process. Thanks
I am currently running into this issue, was a solution ever found?
If we have just 2 scenes (Start Scene, and the 1st level scene) and it loads the 1st level scene taking up 1.06gb of 2.0gb ram usage limit.
if we i checkbox a 2nd level scene in the build settings, it loads up that same 1st level but it now takes up 1.45gb of 2.0gb of ram usage limit. even though its the same 1st level scene that im loading.
If i checkbox a 3rd level scene in the build settings, it loads up the same 1st level but now takes up 1.9gb of 2.0gb of ram usage limit. even though im loading the same 1st level scene.
we have 4 level scenes now, and it goes over 2.0gb of ram usage, even though we are only loading the 1st level scene each time we test.
What is the solution?