为什么我在设备上使用 Instruments 时出现内存泄漏，但在模拟器上却没有
我即将完成应用程序的发布，并尝试使用 Instruments 来修复任何内存泄漏。
为什么我在使用 Instruments 和我的设备时可以发现内存泄漏，但在使用 iPhone 模拟器时却不能？我知道这是一个高级问题，但我认为发布任何代码无论如何都不会有所帮助（相当多的代码......）。
是否有可能让仪器指向它认为泄漏的源代码？我在使用模拟器时可以做到这一点，但在将其用于设备时似乎不起作用（对象由地址表示（我假设），而在为模拟器运行它时它会看到它是什么对象，设置问题？）
提前致谢！
问候， Niklas
更新：这是否与 OSX 有自动垃圾收集而 iOS 没有有关？
I am getting close to finishing the release of my application and are trying to use Instruments to fix any memory leaks.
How come that I can spot one memory leak when using Instruments and my device but not when I am using the iPhone simulator? I understand that this is a high-level question, but I don't think posting any code would help anyways (quite a bit of code...).
And is it possible to get instruments to point to the source code where it think the leak is? I can do it when using the simulator, but it seems like it doesn't work when using it for the device (objects are represented by the address (I assume) while running it for the simulator it sees what object it is, setup issues?)
Thanks in advance!
Regards,
Niklas
Update: Could it have something to do with that OSX is having automatic garbage collection but iOS doesn't?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仅信任设备。这就是您的用户将用来运行您的应用程序的设备。
不要相信模拟器。
为了证明这一点，我只是故意向项目添加了泄漏。在模拟器中未检测到泄漏，但在设备上按预期显示。
模拟器就是这样：一个模拟器。它可以提高工作速度，但永远不能替代设备。
一旦 Instruments 向您显示了泄漏的对象，您就可以双击它。它将显示导致泄漏的代码部分。这适用于模拟器和设备。
当您为设备进行编译时，请确保您处于调试模式（并且此模式的设置保留了所有符号）。
您可能会发现一些有用的提示：
为了获得更流畅的会话，请禁用“自动泄漏检查”，并在适当的时候手动按“立即检查泄漏”按钮。
“构建和分析”命令将非常出色地帮助您查找泄漏。它并不（完全）神奇，所以它不会发现所有泄漏。例如，泄露的 iVar 不会被识别。但对于方法的范围来说，它真是太棒了。
我强烈建议在构建设置中激活“运行静态分析器”标志（或者如果您的编译机器速度较慢，则仅在发布模式下激活）。
如果您想了解有关如何使用 Instruments 查找泄漏的更多信息，请阅读此 Apple 文档：仪器用户指南：内置仪器 和 仪器用户指南：查看和分析跟踪数据>寻找内存泄漏
您还可以观看WWDC相关会议的视频。
如果您仍然不明白泄漏来自何处，那么是时候（重新）阅读 内存管理编程指南。
感谢您想要发布无泄漏的应用程序。有了 iOS 4，它现在比以往任何时候都更加重要。
Trust only the device. That's what your user will use to run your application.
Don't trust the simulator.
As a demonstration of this, I just intentionally added a leak to a project. The leak was not detected while in the simulator, but showed up as expected on the device.
The simulator is just that: a simulator. It can be useful to work faster, but is never a replacement of the device.
Once Instruments showed you a leaked object, you can double click on it. It will show the part of your code responsible for the leak. This works for the simulator and the device.
When you compile for the device, make sure you are in debug mode (and that the settings for this mode kept all your symbols).
Some more tip that you might find useful:
For a more fluid session, disable the "Automatic Leaks Checking", and manually press the "Check for Leaks Now" button when appropriate.
The "Build and Analyse" command will do a fantastic job to help you find leaks. It's not (totally) magical, so it won't find all leaks. For example, iVars leaked won't be identified. But for the scope of a method, it's just awesome.
I highly recommend to activate the "Run Static Analyser" flag in your build settings (or only for the Release mode if you have a slow to compile machine).
If you want more info about how to use Instruments to find leaks, read this Apple doc: Instruments User Guide: Built-in Instruments and Instruments User Guide: Viewing and Analysing Trace Data > Looking for Memory Leaks
You can also watch the video of the WWDC related sessions.
If you still don't understand where your leak come from, it's time to (re)read the Memory Management Programming Guide.
Thank you for wanting to ship a leak-free application. With iOS 4, it's now more important than ever.
如果您还没有查看构建菜单中方便的“构建和分析”选项。它将运行静态分析器，通常效果很好。如果没有任何结果，您应该花一些时间在 Instruments 上查看 WWDC 会议视频。
硬件上的分析是无可替代的，通过连接调试器和仪器，您可以获得模拟器环境中的所有内容。
If you haven't already take a look at the handy "Build and Analyze" option in the build menu. It will run the static analyzer which generally does a great job. If nothing turns up with that you should could some time reviewing the WWDC session videos on Instruments.
There is no substitute for profiling on hardware and with the debugger and instruments connected you can get everything you would in a simulator context.