My game is getting heavier as I play , each level I load the game keeps getting heavier and heavier until it crashes or just becoming unplayable.
I am trying to isolate the problem using the Activity Monitor Instrument but it feels like I am shooting in the dark.
After my game loads and I see the main menu scene, I can see that the physical memory used is 26mb (which is already high but oh well…), when I load the first level the memory soars to 32mb , if I return to load the main menu , the physical memory stays at 32mb , loading another level makes it even higher (although not loading the same level again). I call Application.GarbageCollect occasionally but with no apparent effect.
I am not creating textures on runtime (although I assign some on runtime).
I feel kind of helpless an frustrated with this issue.
What could be the source of it?
Thats the idea, at least unless I missunderstood something.
Handling that is pretty simple.
Create a new List where you put all selfgenerated stuff in and hold that list on a “common object” on the scene. When leaving just iterate through the list and destroy all objects in there.
I am not sure I understand what you mean by “live in scene”.
I only instantiate prefabs from the library , never from the scene. some of the instances - instantiate other prefabs from the library.
It’s always done using a reference variable - I reference the item I want to instantiate into a prefab variable , then I instantiate it when I need to .
So in this case do I need to release the items myself?
I gave it a try , now I destroy all the prefabs that I instantiate before leaving the sceme but I got no significant impact.
Still when I load a scene from the main menu and then return to the main menu the scene dosen’t free almost any memory even when I release all instantiated prefabs and call GarbageCollectUnusedAssets.
This bug is a show stopper for me, after so much time waiting for the release and then waiting for the fix I am starting to lose hope.
What kind of tools do I have to address this issue with Unity?
None if it is an engine issue.
Engine issues can only be corrected by the developers, as you don’t have any access to the source to fix them yourself or workaround them.
If I recall correctly there is a known memory problem with leaving levels, don’t know if it was adressed with Unity iPhone 1.0.1 or was mentioned for the next minor / hotfix
hm… not sure I understand what you’re saying… If I create a new texture using Texture2D.SetPixels, I need to destroy it before I leave the level or it will live on somewhere in memory?
Also make sure you have all your textures a power of 2 and compress them. I tried to load 15 320x240 textures at the start of just a menu scene and loading the menu worked for a sec then crashed (exited the app). I just changed the import settings to 256x256 and the images are compressed and now it works like a charm.
I used it and the game is most definitely leaking , When I enter the main menu the first time , I get :
All 297
Textures 46
AudioClips 0
Meshes 48
GameObjects 40
Component 105
Then I load a level and return to the main menu , I get :
All 479
Textures 49
AudioClips 19
Meshes 69
GameObjects 52
Component 161
so what I understand from it is that there are 70 objects which are not gameObjects,Components,Textures,Meshes or AudioClips loose in my scene and they are supposingly the cause of 3mb unreleased memory?
am I right about this speculation?
and when I load the next scene - I am missing all sorts of meshes , so it’s not really a solution…
EDIT -
When I only release gameObjects and Components most stuff work but I still have a problem f.e with the main character , which will not instantiate the next scene I load, if it was not present in the scene to begin with.
Also the memory keeps rising higher and higher as I load more scenes and the “all object” count does not.
I have two scenes, in the first one I use 7 sounds, in the second scene I use 7 different sounds.
Using your script in the second scene I can read 13 AudioClip !!!
I have tried to destroy the sounds manually with the same result.