![]() ![]() What the game really is left doing during startup is the following: I've been testing without internet connection so there's no additional downloads. If we know the code section is my original screenshots were not tracked, it would come down to 790 - 143 = 647 - 412 = 235MB that's untracked. ![]() So there's still a big chunk of memory unaccounted for. (We're also experimenting with upping the code stripping to medium to lower than even with third party libraries). What kind of allocations are there that would not be tracked at all? Are we guaranteed that everything we allocate in c# will be tracked or are there known classes that we know for sure won't be?Īt the moment I've taken out all third party libraries (ads, facebook, analytics, google play services, etc) and that had an impact in adb on the "code" section, taking it from ~150 MB to ~50MB. Am I right in understanding this matches the "Managed Memory" section of the memory profiler package? Is this allocations we make in c# code which is then potentially freed by us but not returned to the system?Īssuming I'm not mistaken there, and this managed memory is already account for in the memory profiler package snapshot, the main question remains, where is the difference between the 400+MB tracked memory, and the nearly 800MB adb is reporting. One thing however I noticed, is that there's ~100MB of "Total GC Allocated". The assets part I can map to the the memory profiler package easily, and the "other" section in there is mostly the profiler. (We are working on integration of this information into the Memory Profiler package too)Ĭlick to expand.I had a look here, and it's showing even less memory in there (in the detailed view, screenshot below). That would allow to see some Unity internal subsystem in more details - I believe those are responsible for large portion of unknown. In your case the "Other" part is definitely important and I would recommend trying Detailed view of Memory Profiler module. native plugins or gl driver allocations), but we are actively working on improving the tool and our tracking systems at the moment We definitely have gaps and some are quite tricky to cover (e.g. Native Heap + Unknown should correlate with Managed Heap + Audio + Other + Profiler - ~400MB vs 476MB. Graphics and Graphics driver should correlate with GL mtrack - 79.8MB vs 126MB. Native Heap, GL mtrack and Unknown is what memory profiler directly and indirectly tracks. This can explain the discrepancy between 3.6GB and 790MB ![]() We've fixed that in 2020 and use Pss set to build a breakdown. ![]() I believe in 2019.4 the "Total" memory size we've been using meant in fact total system memory usage which included all other app on the device. I would appreciate any advise on tools, techniques, or knowledge on finding out what's up with the memory use, and then thinking about how to reduce it. I am not an expert in native Android development and debugging, so maybe I'm missing something obvious. So it looks like it should be possible to get that lowered, but we might have third party libraries or code that's creating buffers that aren't properly released to the system or something like that. I checked a competitor game that according to logs looks like it's built with a similar 2019.4 version, and their "Private Other" is much much lower. (The value remains high on non development builds as well). Screenshots of both are at the bottom of this post.Īs far as I can tell, it looks like the "Private Other"/"Unknown" category of the adb command might not be tracked by the Unity memory profiler, but there's no easy way to determine what's in there. That's quite a massive gap and I would like to understand why that is, or if I am misunderstanding something. However using adb command adb shell dumpsys meminfo, it is showing memory usage is 772MB. Using the memory profiler package, on one specific point, I am seeing 314MB in use and 412MB reserved. The device being tested on has 4GB ram to make there's enough space to not get influenced by memory pressure. Builds have been built in development mode, but in release mode in Android Studio. Our game is built with Unity version 2019.4.18, but for getting the memory profiler to work better, I've updated to 2019.4.31 for the purpose of making builds for profiling. The first step is obviously trying to understand what exactly is using the memory. I'm trying to get the memory usage down of our game on Android devices, as on "low" memory devices (2GB and below), the game gets killed if the game shells out to a link in the browser. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |