我的应用程序中存在内存泄漏
我正在开发一个 IOS 应用程序。在 Xcode 中我会分析应用程序 Run->analyze 它显示了 47 个潜在的内存泄漏，我检查了所有情况，在大多数情况下不可能释放内存，在应用程序商店中启动应用程序时会出现任何问题吗？ 我已经彻底检查了该应用程序，它没有在任何地方崩溃，也没有在任何地方显示内存不足警告。 由于我是 IOS 开发的新手，请建议我对此能做什么？
在 viewDidUnload 方法中释放内存是否足以避免内存泄漏？
i am working on an IOS application.In Xcode I'd analyze the application Run->analyze
It showed 47 potential memory leaks I checked out all the cases in most of the cases it is not possible to dealloc the memory,will there be any problem while launching the application in appstore?
I have thoroughly checked the application it is not crashing anywhere neither it is showing low memory warning anywhere.
As i am new in IOS development kindly suggest me what i can do about this
Will it be enough to dealloc the memory in viewDidUnload method to avoid memory leaks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果它不显示任何内存警告，则可能不会被拒绝。但构建存在泄漏的应用程序通常不是好的编程。为什么不解决这些泄漏问题？在任何情况下您都无法释放您的分配。在需要的地方使用自动释放或将释放消息传递给元素。
此外，为了更好地分析您的应用程序，请使用 INSTRUMENTS 运行应用程序，它会让您更好地了解泄漏来自何处。
编辑：如何使用仪器运行应用程序。
当您在 Xcode 中时，单击顶部菜单栏中的“运行”。在此部分中，进入使用性能工具运行，然后选择泄漏。
要了解如何使用 Instruments，请访问 这里。
It may not be rejected if it doesnt show any memory warnings. But building apps with leaks is generally not good programming. Why arent you solving those leaks? There is not a single situation where you wont be able to release your allocations. Use autorelease or pass the release message to the elements wherever needed.
Also, for better analysis of your app, run the app with INSTRUMENTS, it'll give you a better idea where the leaks are coming from.
EDIT : How to run app with Instruments.
When you are in Xcode, Click on Run in the Top Menu Bar. In this section, go into the Run with Performance Tools and then select Leaks.
To know, how to use Instruments, go here.
注意：我还没有机会使用 ARC 等一些最新功能，因此现在可能会或可能不会过时。
是的，这可能是一个问题。据苹果公司称，这是他们确实检查的一件事。然而，似乎没有什么能保证苹果审核团队会拒绝（或接受）。然而，也许更重要的是，您希望自己作为应用程序开发人员享有良好的声誉，您希望从事让人们的手机更好地工作的业务。
如果做得好，您将始终释放使用 new 或 alloc 创建的任何对象。
然而，为了防止、追踪和消除内存泄漏，您需要使用：
1.分析
2. 仪器泄漏
3.您自己的分析，并在需要时进行同行评审
4. 干净的编码、最佳实践和模式
在使用 Instruments Leaks 分析工具时，使用您的应用程序并尝试访问所有不同的执行路径。查看对象是否显示为泄漏。我通常按泄漏的总大小（对象大小 * 泄漏数量）确定优先级，然后逐步降低，直到没有泄漏出现。单击该对象将向您显示该对象最初分配的位置附近的某个位置。
我发现即使是 Instruments 也可能无法明确捕获所有内存泄漏。
在这方面可能会有所帮助的另一个技巧是推理出您可以在应用程序中进行的一些不同的“循环”，其中，一旦您返回“主页”，您的应用程序应该具有与上次访问时相同的内存占用量。例如，从主屏幕开始，执行活动 X，然后执行活动 Y，然后返回主屏幕。假设您期望在第一个周期之后，第二次和第三次返回主屏幕时，内存占用应该相同。然后，您可以使用连接的仪器和分配数量进行练习。这可以为您提供一些有价值的信息。
保留周期可能会发生一些有趣的事情，当类之间存在循环依赖时，就会发生这种情况，并且在尝试使用块执行某些操作时很容易发生这种情况。
当对象在应用程序的生命周期中持续存在时（如单例），您可能会想忽略有关内存泄漏的警告。我的意见是消除警告并将对象重新分配到某个地方，以保持清洁。
当您构建时，您还会对零编译器和零分析器警告感到非常高兴！
Note : I have not had an opportunity to play with some of the newest features like ARC so this may or may not be out of date now.
Yes this could be an issue. According to Apple, this is one thing that they do check for. Nothing seems to guarantee rejection (or acceptance) by apple's review team, however. Perhaps more importantly, however, you want your reputation as an app developer to be good, you want to be in the business of making people's phones work better for them.
Done right, you will always be to release any objects you have created with new or alloc.
However to prevent, track down and eliminate memory leaks you need to use :
1. analysis
2. Instruments Leaks
3. Your own analysis, and peer review when needed
4. Clean coding, best practices and patterns
While using Instruments Leaks profiling tool, use your app and try to hit all the different execution paths. See if objects appear as being leaked. I usually prioritize by total size of leak (object size * number of leaks), then work my way down until no leaks are showing up. Clicking on the object will show you somewhere near where the object originally gets allocated.
I found that even Instruments might not catch all of the memory leaks explicitly.
One more trick, that might help in this regard, is to reason out some different "loops" you can make in your app where, once you return "home" your app should have the same memory footprint as the last time you were there. For example, start at the home screen, carries out activity X, then activity Y, then return to the home screen. Lets say that you expect, after the first cycle, the 2nd and 3rd time you get back to the home screen, the memory foot print should be the same. You can then practice this with Instruments connected and the number of allocations. This can give you some valuable information.
There are some interesting things that can happen with retention cycles, which can happen when you have a circular dependency between classes, and is easy to have happen when trying to do certain things with blocks.
You might be tempted to ignore a warning about a memory leak, when the object persists for the lifetime of the app (like a singleton). My opinion is to eliminate the warnings and deallocate the object somewhere, as a matter of cleanliness.
You will also feel very good about having zero compiler and zero analyser warnings when you build!
如果您在模拟器上进行测试，您很可能永远不会看到内存不足的警告。但无论如何，除了 Apple 框架中存在的内存泄漏（可能数量不多）之外，所有内存泄漏都应该是可以修复的。
分析返回什么类型的信息？
If you're testing on the simulator, chances are you'd never see a low memory warning anyway. But regardless, all memory leaks should be fixable except those which exist in Apple frameworks (of which there likely aren't many).
What kind of information is being returned by Analyze?