Search Unity

Question Which memory stat is the one that influences when my mobile app will crash?

Discussion in 'Editor & General Support' started by Xarbrough, Jun 11, 2021.

  1. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    On Android and iOS, app will be closed or "crash" if they allocate too much memory. The limit is defined by the platform and there are some rough approximations what values these are. Let's just say for an example I know that my app will be killed if it uses more than 500 MB RAM.

    Which of the profiler stats is the one I need to look at to check if I stay below the limit when profiling on device?

    upload_2021-6-11_11-11-45.png

    upload_2021-6-11_11-12-7.png

    Looking at the details I can see that we only use 30 MB textures and 20 MB other stuff in memory. Another 30 MB is listed as profiler overhead.

    But then in the simple overview it says 174 MB Total Used Memory. That's much larger than the sum of all details. It also seems like I can't really control much of this, because I can only delete 30 MB worth of textures and then my game would have no assets at all.

    Additionally, the Total Reserved Memory and System Used Memory stats are even higher. My intuition tells me that the OS would look at the highest of these numbers and say something like "if this is above 500 MB, the app will be closed". But maybe I'm wrong and the reserved blocks are not counted for this limit.

    I'm also confused about how these stats can be reproduced using the Profiler API. I use
    Profiler.GetTotalAllocatedMemoryLong() to display the memory usage on device even when not attached to a profiler. I thought this should match the "Total Used Memory" from the profiler, but it doesn't, since it tells me 144 MB in my shown example (with the profiler attached), and less if not attached.
     
    Xarbrough, Jun 11, 2021
    #1

  2. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,456
    System Used Memory. It's the closest number to what the OS looks at, as it's actually reported back from the OS. On e.g. Android its not 100% the closest, as getting that number comes at a cost of about 500ms per query, but pretty darn close.

    Also, the question of what number to look at and how they add up is part of why we updated the simple view UI in 2021.2.

    I believe Gfx and GC (aka Mono/IL2CPP) are not included in GetTotalAllocatedMemoryLong but is part of "Total Used/Reserved Memory". But also from 2020.2, you can just get "Total Used Memory" and other counters directly from the profiler data stream using ProfilerRecorders so, that should be an exact 1-to-1 mapping there. The Memory Profiler manual page lists the relevant counters, if they are available in release builds and has some code samples for how to use these.
     
    MartinTilo, Jun 14, 2021
    #2
    Xarbrough likes this.

  3. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    Thanks for the clarification, I managed to use this to setup some nice debugging displays for release builds. :)

    Still wondering how to optimize my game though since the total used system memory is 500 MB, but I can only associated less than 100 MB with any specific assets or scripts that I actually control. Both the Profiler's and Memory Profiler's snapshots only show around 30 MB assets, but not much else. Does this mean Unity's overhead is 400 MB of things I don't control?
     
    Xarbrough, Jun 14, 2021
    #3

  4. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,456
    The unknown/untracked memory parts include stuff like IL2CPP/Mono type metadata (influenced by your code e.g. through the use of generics, but really tough to analyze and action upon right now), native plug-ins or drivers (a native platform specific profiler might help spot those) and Executable and DLL sizes (which is shown in the detailed Memory Profiler module snapshot or in the Allocs by Roots table in the Memory Profiler module and mostly influenced by code size and referenced assempblies). So, it's tough to analyze and tricky to action upon, but somewhat under your control and somewhat not. We want to make this part clearer and more actionable though.
     
    MartinTilo, Jun 15, 2021
    #4
    Xarbrough likes this.