在系留（至Xcode 3）iPod Touch上运行长时间运行的声音处理应用程序。现在两次，第一次1小时40分钟，第二次2小时20分钟后，应用程序以信号0结束。在这里和其他论坛上有多个关于信号0的讨论，它们似乎都归咎于内存耗尽
但是我会间歇地使用内存，而且在最后一次测试中，它从运行初期到结束前只增加了大约3.3mb。如果我收到内存警告（在模拟器上测试它）并且没有触发，我在我的app委托中有一个钩子来记录。
简而言之，没有任何关于内存不足的建议。
在这两种情况下，应用程序都在程序中的一个点结束，文件被写入并传输到服务器。 （每20分钟发生一次。）传输的文件相对较小（在故障点传输的文件为86kb）。根据日志，似乎在读取文件以准备传输时可能发生了故障。这将涉及创建包含要传输的数据的NSString。 （可能这里的逻辑可能更清晰 - 它使用NSString stringByAppendingFormat，我承认，这是怀疑。）
有关如何调试此问题的任何建议？铃响了吗？我可以在没有任何警告的情况下退出存储吗？有什么东西可以在手机上“睡觉”吗？您可以在Xcode 3上运行连线测试的时间有一些限制吗？
答案 0 :(得分：0)
我只能建议您使用NSAutoreleasePools包装所有使用循环中创建的自动释放对象的代码。您创建的每个自动释放的对象都会添加到主自动释放池中，因此整个内存分配越来越大，直到系统给您内存警告并关闭您的应用程序。
以下是有关NSAutoreleasepool的更多信息：
http://www.cocoadev.com/index.pl?NSAutoreleasePool
或者来自docs：
您可以在循环内创建一个自动释放池，以便在下一次迭代之前处理这些对象。在循环中使用自动释放池有助于减少应用程序的最大内存占用量。
这只是猜测，但根据我的经验，添加自定义池让您有效地最小化内存分配。希望能帮助到你。
答案 1 :(得分：0)
我不确定这是最终的答案，但是我已经“按摩”了过去几天的代码并解决了几个与存储相关的问题。修复了几个小泄漏（“Leaks”是一个非常宝贵的，但接口有点sux），但是，更重要的是，我修复了代码中的一个地方（在我原来的帖子中提到），可能在一个中分配了100mb左右方法。存储全部自动释放，但这仍然意味着它在分配曲线中创造了一个巨大的驼峰。 （而且这一切都发生在发生碰撞的地方非常接近。）
经过这些修复后，应用程序运行了3个多小时 - 还没准备好宣布胜利，但看起来很不错。
（丑陋的代码（不是我的！）反复使用stringByAppendingFormat来构建一个相对较长的字符串用于网络传输。如果你有N个长度为M的字符串连接在一起，你使用{{1}反复这样做，结果大约是N * M，但是你通过大约N * N * M / 2存储来构建它。如果N大约是2000，那么它就是一个很大的数字。虽然它是所有自动释放它仍然累积，直到池耗尽。使用stringByAppendingFormat的追加函数效率更高。）