【发布时间】:2011-01-12 13:06:35
【问题描述】:
我正在测试特定用例的泄漏情况。有时,我会得到泄漏,而有时即使我经历了相同的用例,我也不会。你能建议是因为系统框架还是我的代码?
我检查了我的代码,一切看起来都很完美,没有任何未发布的对象。您能提出解决方案吗?
谢谢
【问题讨论】:
-
没有您的代码,我们无法提出任何建议。
我正在测试特定用例的泄漏情况。有时,我会得到泄漏,而有时即使我经历了相同的用例,我也不会。你能建议是因为系统框架还是我的代码?
我检查了我的代码,一切看起来都很完美,没有任何未发布的对象。您能提出解决方案吗?
谢谢
【问题讨论】:
极不可能是框架。不要忘记,有数百(数千?)开发人员在使用它,因此与仅由您自己审查的代码相比,有人没有注意到错误的机会要小得多。
【讨论】:
间歇性内存泄漏的最可能来源是自动关联的对象。自动释放的对象会一直徘徊,直到它们所属的自动释放池被耗尽。根据内存条件,它们可能看起来像是在一次运行期间泄漏,但在下一次运行时却没有。
请参阅Avoiding, finding and removing memory leaks in Cocoa 了解如何追踪内存泄漏。
Edit01:
您可能会侥幸成功,但我不建议您这样做。如果它在 Apple 测试时泄漏,你很有可能被拒绝。
作为质量问题,它取决于泄漏的严重程度以及在实际使用过程中泄漏的持续时间。每个应用程序都可能在这里和那里泄漏几个字节。 (例如,某些框架中存在已知的泄漏。)如果泄漏非常小,它们不会引起问题,尤其是在仅运行很短时间的应用程序上。但是,如果泄漏较大或应用程序被设计为长时间运行,那么泄漏最终会使应用程序崩溃。
例如,假设您有一个类似天气应用的程序。作为一个质量问题,如果它泄漏一点真的没关系,因为天气应用程序使用很快。人们打开它,看看天气,然后关闭它。泄漏没有时间积累。另一方面,如果你有一个像网络浏览器或电子阅读器这样的应用程序,人们长时间保持打开状态,泄漏可能会累积并导致应用程序崩溃。
简而言之,与所有其他编程任务一样,追踪漏洞是感知质量与开发之间的权衡。花费更多的资源来追踪一个微不足道但常见的错误比追踪一个严重但非常罕见的错误是很常见的。
我要重申的是,上面泄漏中的内存泄漏检测方法最终将定位泄漏。如果你花时间在它上面,你最终会找到它。
【讨论】: