Well, the other threads on here by myself and others with similar/same issues are not getting loving attention so I thought to consolidate and ask with a new more precision oriented title. Seems a number of us are getting leaks in our Xcode builds which are show stoppers. My app would have been at the appstore on wednesday for approval if I wasn’t fighting this “shutdown after 3-4 minutes” of gameplay. Now its Sunday and I have it partially figured out from reams and reams of reading but am baffled at what the next step is and how to implement it. The Unity build is fine, as are many others having the issue. When played on the device and watching the Instruments window I get a pile up of memory from one or two leaks. Looks like four blocks of 16 bytes. Seems if I can reclaim or get rid of those then I have the issue solved and can apply this to two other games as well that I noticed having a shutdown after several minutes of perfectly good gameplay. The games throw no errors, nullexceptions and all vars are typed. Stacktraces show no errors I can spot (not that I know 100% of what I am doing there).
OK. I blitherfested the above to get to the point of asking how to deal with the “applicationDidReceiveMemoryWarning” prompt. After much digging I saw that there is a way to clear the unused and/or leaking memory but it made not much sense to me as they were not in the realm of the Unity app and mentioned no scripts where I should attempt to place any solution. Mind you I am new to Xcode and got maybe 25 hours of experience in the app. This should be simple for the more experienced. Outline of presumed codepath to follow is below.
I get the applicationDidReceiveMemoryWarning call from iOS (from where is that received?)
I run the line of code that removes the unused blocks leaking (which is what and where do I place that?)
Can I handle this inside a Unity script or is this an item for AppController.mm.
Can the Unity team not just add something to the build process that automatically deals with the memory warning and removes unused blocks? If so it would solve umpteen headaches.
There is no silver bullet solution. If your game is running on the edge of available memory then it might crash at any time.
The solutions are:
a) decrease app binary size by enabling .NET stripping
b) decrease asset size - use smaller res textures, enable texture compression. Load assets on demand - Resources.Load.
c) decrease .NET allocations in your scripts
This is not an issue with assets nor sizes. .NET stripping fails with errors. It is simply a buildup of 16 bytes per frame that does not get dumped from allocation. After approximately 3 minutes and 30 seconds it has built up enough unallocated memory blocks that the game fails. My guess is it is from string manipulation and after the string is gotten from an int the string never gets tossed. I may be wrong but regardless, is there not a line of code that can be placed that cleans up unallocated blocks? Whether from destroyed instantiations, unused blocks formerly allocated to a one frame loop sequence, or no longer used bitmaps…whatever.
Currently we are not aware about such every frame issues.
Please submit your project for investigation. You can do it from Unity Editor : “Help”->“Report a bug”.
Thanks!
I will do so when I reopen those two projects for compile later this week. I also have made a score and timing system that does not seem to pile up the byte blocks as i am using EZ GUI and an array of number grfx and not doing any back and forth manipulations between string and int. Whether that does the trick in the other two games I do not know yet.
Resources.UnloadUnusedAssets can do some cleanup (similar to the cleanup on changing levels), however anything contained within the Mono framework should be cleaned up on Garbage Collects which will automatically happen before running out of memory. The Garbage Collector tracks references, and when an object is no longer referenced by anything it will get cleaned up. This means however that if you somewhere store an array of ints or strings or whatnot then they cannot be cleaned up until they get removed from that list(unless that list itself gets removed).
The other compounding issue is that things like GameObjects and MonoBehaviours override the == operation to equal null when they are not. If you have a static array of GameObjects and change levels, all the GameObjects will == null, however they are not actually nulled, and should be set to null or else the Garbage Collector cannot cleanup those references (even though Unity seems to have cleaned up most of the C++ side of the Object). They will not take up much space, but they can eventually add up.
@Ntero … I believe what you have described with the == is a part of the string to int/int to string manipulations and a few other nested if else if statements. So if i follow you correctly once I dispose of an instantiation with a destroy, I should also set it to == null as well or the reference remains stored and the destroyed object won’t be cleaned up?
For strings and ints, I don’t know if it’s an issue.
What I was talking about is with Unity’s objects specifically.
I can check if myGameObject == null, after a destroy, and it say it is. For all intents and purposes it is unusable. However it’s not actually null. It still contains the reference to that destroyed GameObject. Since it is still being referenced, it can’t be cleaned up with the Garbage Collector. The reason it says it’s null is because GameObject overrides the == operator, to let you know you can no longer use it. For the most part these will get cleaned up anyway on a scene change or when the reference is overriden with a new one, but it can create issues when you keep around the null references somewhere in a static list, as they may say they are null, but they are still referencing the unsuable gameobject, and can’t clean up that GameObjects memory.
As far as the string to int manipulations I’m unsure of any issues it could have. Also if you use the WWW class extensively you may want to call WWW.Dispose() once you have loaded each object.