8

当我尝试使用 Instruments 检查我的 iPhone 应用程序的泄漏时，一切都很好。实际真实设备上的同一应用程序在应用程序启动期间多次显示此泄漏。这是非常不确定的，它发生在系统库中。我试图在没有运气的情况下用谷歌搜索解决方案。有人遇到同样的问题吗？有人知道解决方案吗？

我发现有趣的是，我的每一次代码泄漏迟早都会使应用程序崩溃。这些 GeneralBlock-3584 泄漏使应用程序完全稳定。这可能是 AppStore 拒绝的原因吗？

感谢有关此未记录问题的任何答案（不幸的是，Apple 保持沉默）。

4

4 回答 4

8

您无需担心，这是 Instruments 的误报。
它与释放已终止线程的资源有关。他们只是闲逛直到下一个线程完成并在先前终止的线程之后清理资源。仪器将此视为“泄漏”，但它是 iOS 上 pthreads 实现的一个功能，在完美的世界中，它的处理方式会有所不同。在此处和此处的 Apple 开发论坛上了解更多信息。

于 2009-09-10T07:44:18.390 回答
7

泄漏检测工具通常会产生误报，尤其是在底层系统库中。

我熟悉这些“泄露”的 GeneralBlock，根据我的经验，它们并没有导致 App Store 拒绝。

IANAASRW **，但我认为你很好。

** 我不是 App Store 评论向导

于 2009-01-30T23:07:54.553 回答
0

Apple 框架存在漏洞。特别是 HTTP 类。您应该提出雷达缺陷报告。

于 2009-06-01T06:50:59.973 回答
0

在运行应用程序的“最初几次”期间，您是否有未进入设置进行初始化的 UserDefaults？

我看到了同样的问题——应用程序在最新的 Xcode/Simulator 上（相对）干净（通常的一对 128 字节 malloc 在那里——但这纯粹是 UIViews 的模拟器问题）。在 iPod Touch 上运行它后，我看到了 GB3584。

但是，在进入设置并更改设置（强制保存*）后，问题就消失了。

  • 我正在使用 Apple 的 UserDefaults 示例代码来正确读取这些设置，而无需先进行更改。

所以，它很可能什么都不是。如果您可以确认访问设置清除了它，那么我们就会知道从哪里开始寻找泄漏（或引导 Apple 去哪里寻找）。

于 2009-10-22T20:22:30.277 回答