问题
I'm nearly finished with my app and I'm using Instruments to optimize performance before I submit to the app store. I noticed that whenever I execute a particular action (updating the information in my app from an external server) my heap grows by about 350 KB. The research I found here on stackoverflow and Apple's documentation suggests executing Heap shots to find the offending code. However, instead of taking me to the offending code it shows me memory addresses.
Is there a way to use this information? Or should I be using another tool? I'm pretty new with Instruments, so I appreciate any help.
I would show a screenshot, but my reputation here isn't high enough yet.
回答1:
A couple of thoughts:
In the heap shot, don't forget to show the extended detail (⌘+E or select "Extended Detail" from the "View" menu) in the rightmost panel of Instruments.
When viewing extended detail, it will show you a stack trace, and you can double-click on your method name there (which will be in black rather than light gray) and you'll be taken to the line that generated the allocation (which obviously isn't necessary the root problem, but it will show you where the object was originally allocated, which is a place to start).
Having said that, I generally focus on the standard Allocations tool first. I'll option-drag in the allocations instrument timeline at the top to highlight allocations within this time window of execution, I'll then select "Call Tree", and to focus on just my code, I'll check the "Invert Call Tree" and "Hide System Libraries" boxes:
For me, I find that's a more efficient way of identifying my allocations that took place within that window of time, without sifting through system allocations.
Do not forget to run your code through the static analyzer in Xcode (shift+⌘+B or choose "Analyze" on the "Product" menu). You should get a clean bill of health there before you even start running your app through Instruments.
回答2:
Start with bbum's tutorial: When is a Leak not a Leak?
The short answer is that there is no tool that is going to tell you the exact line of code that causes a leak. The system does not know where you made your mistake. It knows when you allocated memory, and it knows that memory hasn't been released, but it has no way to know whether you meant to release the memory or not. It especially does not know when you should have released the memory because it has no way to know why you allocated it in the first place.
Using heap shots, you can discover what the extra objects are, and from there you can audit how you use those objects.
来源：https://stackoverflow.com/questions/18021734/using-heap-shot-analysis-shows-memory-addresses-but-not-lines-of-code-how-do-i