Hi,
We're also experiencing memory crashes on mobile due to using extremely long UILabels (for Ts&Cs, Privacy Policy, FAQ, etc.).
Profiling, we find the memory leak is in the Not Saved - Mesh category as noted above. I call it a leak because we have found no way to clear this memory once it increases, even after the user navigates away from the screen and we:
Destroy ( view ); delay 1 frame; Resources.UnloadUnusedAssets (); GC.Collect ();
I tried adding UIDrawCall.ClearAll () and UIDrawCall.ReleaseAll (), but those don't appear to release the memory either. Rather they appear to make the situation slightly worse.
So our primary questions are: how do we release this memory? How to we kill the meshes?
Our secondary question is: does a long UILabel really have to cause a 35MB mesh memory spike?
Additional notes: looking at the profiler, we actually see several entries under the mesh category, but apparently using the same texture and font. Each entry is taking its own memory, and contributing towards the category total. Individuals entries range in size from 300k to 6Mb at peak. Most go up together, but some sit lower for awhile as others rise. None of the entries ever goes down in size or gets removed.
To repro this, just put a few UILabels in a scrollview, then dynamically fill the text in via code at runtime. They text should be very long, say about 20 mobile screens worth. Split that amount across the labels if using a single label fails to display or causes a crash. We test with iPod touches since their memory characteristics are relatively weak. Get device and editor on same Wifi and autoconnect profiler to see (hopefully) what we see in the profiler. Profiler in-editor produces strange results and we question their accuracy / relevance.
Many thanks, let us know if you would like further details.
Nicholas Bellerophon
Senior Developer
Yummi Media