koobas.hobune.stream
Does XCode Instruments -> Leaks give correct information with Unity iPhone?
I'm pretty new to Unity iPhone, however I've spent about a year and a half developing in Unity, so I've been spending some time familiarising myself with the production line and testing of a few thing before going into full production on a project, and have found that anything I build from Unity iPhone 1.7 reports memory leaks through the XCode Instruments Leaks tool. I first tried it on a test app I had put together, and after seeing the leaks appear in that, I decided to make a plain app with one scene, and one camera in it. This also produced leaks, in just about every build configuration I could try, on both a 1st Gen iPod Touch and a 3rd Gen iPod Touch, in ARM 6 and ARM 7 build configurations.
I started doing some searches to determine if this was a major issue, and from what I've found there were some leaks in earlier versions of Unity iPhone, however I haven't seen anything reported specifically for Unity iPhone 1.7. I did come across one post on the forums stating that the reports from Leaks was inaccurate because it interpreted the Mono runtime's handling of memory incorrectly, however it was a unique post, and didn't really explain why.
So are the memory leaks being reported from Instruments Leaks real leaks, or is there a different way I should be profiling my apps to make sure there aren't any memory leaks?
Edit: I really need to know this, and I'm pretty sure that due to Apple's stringent approval process, that everyone does, so a bounty has been placed.
Edit 2: As I haven't received a response from Unity Support, I'm selecting the answer that gave the most useful response. I will post any further findings here once Unity get back to me.
The best way to make sure your app doesn't have leaks will be to watch your memory usage over time, to see if it steadily goes up.
There are many ways to create leaks with unity, most of them being to do with creating certain types of objects (e.g. Texture2D) which actually reside in native memory.
If those are leaking, you probably won't see them in leaks either - they're still in use by unity internally, you're just not using them for something. You will however see the memory steadily creep up over time.
If your app stays stable memory wise, and the only leaks are the false positives from Unity, Apple won't fail your app for memory reasons
Wouldn't depend on how you test the game? If your play-testing coverage isn't exhaustive (and whose is? :) - you could miss any special cases that leak memory. In general, I like the idea of static code checkers (although I know nothing about XCode specifically, or the iPhone).
Indeed - I wasn't implying that he should stop using Leaks, just to do a lot of playtesting on top of that to make sure
Thanks, I understand how $$anonymous$$ono/.NET handles memory, and I'm aware of the fact $$anonymous$$ono's garbage collector isn't up to par, but my concern is mainly if Leaks is useless for tracking memory. If so, what other methods people are using to monitor memory leaks. I'll be posting Unity Support response once it comes through so may have some more info then.
you will not have any problems for your app to being aproved because there are many many unity based games there in ITunes. Mono's garbage collector is not a great multi generation one like what you see in .NET framework or java. the main unity engine has no leaks i think but i can not be sure. so the leaks are not real leaks and mono will collect them soon after they appear. you can call GC.Collect at any time to collect garbages.
$$anonymous$$any great Unity games have been approved under the OLD T.O.S. and this is a perfect example of why middleware shouldn't be used, as the developers aren't aware of what is happening on the device. I can't be sure on if they're real leaks, and as a result I can't be sure that Unity will remain a usable platform.
If there is a major lockdown on apps under the new T.O.S. I don't want to give Apple any reason to stop our app from being released. This is a major issue in my eyes
email UT suport and they will provide you with the most accurate info about it or even email the iphone developers of UT directly. they are friendly enough to answer.
I've emailed Unity Support, so I'll post the result of that once it's up.
"middleware shouldn't be used" - @$$anonymous$$urcho, if I could downvote comments, I would that one - Unity is middleware, so you're basically saying Unity shouldn't be used. Everyone should just code in the C language. Which would mean 10X the effort expended to do any kind of complex game.
This is the argument of TOS 3.3.1, that middleware can't be used, and this is a perfect example of why Apple have 3.3.1, because people are releasing software on the device that can be detrimental to the device, and they have no idea why it is detrimental because they spend little to no time in XCode/Obj C, don't understand the SD$$anonymous$$, the Human Interface Guidelines, or how the underlying hardware works. I'm not saying the Unity shouldn't be used, but there is an expectation that the developer understand the SD$$anonymous$$, this is an example of people not understanding the SD$$anonymous$$.
