我有一个奇怪的记忆问题,我遇到了解决问题,并希望得到一些关于其他地方的建议。
我拥有的程序(iPhone App)具有以下功能:基本上下载大量文件,处理JSON文件,并将其余文件存储到磁盘。 JSON处理是CPU密集型的,每个文件可能需要几秒钟,所以我有一个NSOperationQueue,maxConcurrency限制为1,可以处理所有繁重的工作,还有一个队列管理要下载的多个文件。
自从iOS5问世以来,应用程序在完成下载序列时遇到了问题而没有崩溃,到目前为止我所尝试的是;
1)更改performSelectorOnBackgroundThread JSON处理以使用单个NSOperationQueue,以限制使用大对象的后台线程数。
2)在创建多个大型瞬态对象的循环中添加了NSAutoReleasePools。
3)刷新sharedURLCache以确保文件不会在系统缓存中闲置。
4)使用NSKeyedArchiver将JSON对象存储到磁盘并在线程之间传递文件名而不是实际对象,以再次尝试减轻当前使用的保留对象的数量和大小。
所有这些起初似乎都有所不同,当我查看内存分配时,我现在已将峰值使用率从刚刚超过20MB(因此难怪它崩溃)降至10MB以下,该应用程序仍然像以前一样以低内存崩溃。
我正在试图追踪正在吃东西导致应用程序崩溃的内容,在这种情况下,我遇到了真正的问题,说服仪器告诉我任何有用的东西。
这是一个典型的跟踪(在运行iOS 4.3.5的iPhone 3GS上)
你可以看到PEAK使用量超过7MB,但不久之后,你可以看到2个与低内存相关的标志,然后是低内存紧急,然后应用程序很快就会终止。
如果我使用内存监视器,崩溃的原因似乎很清楚 - 物理内存耗尽 - 请查看下面的浅绿色轨迹。低内存警告(不足为奇)与物理内存不足相关。
也没有泄漏显示FWIW(我在其他运行中已经这样做了。)
这不是图像缓存或NSURLConnection缓存,我唯一能想到的是可能存在一些未被检测到的漏洞......但是我遇到了识别它们的问题,因为如果我点击所有分配要查看实时对象,然后执行命令-A全部选择它们(为了将它们粘贴到电子表格中以查看内存的位置),在命中C命令C复制它们时,仪器沙滩球,永远不会恢复。
我真的无法弄清楚发生了什么。有没有人对如何说服乐器向我展示一些有关使用这种记忆的有用信息有一些建议?
抱歉,我无法发布任何有意义的代码片段...希望这些乐器截图至少可以让您了解我来自哪里。
答案 0 :(得分:6)
Leaks仪器对于找出除应用程序中明显泄漏之外的任何内容并不十分有用。
您所描述的是快照分析的理想候选者。
tl; dr Heapshot analysis允许您准确了解应用程序堆在任何两个时间点(确定点数)之间的增长情况。