【发布时间】：2013-03-10 07:34:09
【问题描述】：
由于我难以理解的原因，我的应用程序经常崩溃。它并没有崩溃——它被外部“未知”进程杀死：
Processes
Name <UUID> rpages recent_max [reason] (state)
test-app <....> 167111 167111 [per-process-limit] (frontmost) (resume)
我可以理解，如果我分配的是一个巨大的内存块，或者是无数个更小的内存块，但我并没有做任何令人发指的事情。使用 Instruments 进行分析告诉我，该应用程序仅使用大约 8 MB，当我加载一些大型内容时，偶尔会飙升至 13 MB 左右。没有严重的泄漏，应用程序通常很快就会被杀死。
一位同事开始使用 Activity Monitory 来检查应用程序在模拟器中运行时的内存使用情况，并注意到当我们开始使用时内存从大约 70 MB（我猜模拟器中的情况有点不同）飙升至 800 MB 以上某个图书馆。所以，我开始在模拟器而不是设备上进行分析。 Allocations 工具继续报告应用程序使用了 8-ish MB，但 VM Tracker 讲述了另一个故事：
所以...看起来 VM Tracker 能够看到分配没有的一些重要内存使用情况。
为什么分配工具会丢失此应用使用的 99% 的内存？
更新：针对 nielsbot 的问题，我仔细查看了 VM Tracker 的信息，发现我在 Allocations 中没有看到的最大部分内存归因于 Core Animation ：
【问题讨论】：
-
我认为虚拟机空间包括共享框架和映射内存之类的东西，而分配可能不...
-
您在区域显示中看到了什么？ （点击Summary，切换到Regions，按Virtual Size排序，从大到小）
-
事实上 - 我注意到您在答案中粘贴的输出中特别提到了“rpages”（常驻页面）。我想您将不得不尝试限制框架的“高水位”常驻页面...
-
很好的问题，@nielsbot——事实证明，大部分内存是由于核心动画。在内存峰值发生期间，我们确实会显示一些大图像，但我认为不足以解释这种内存跳跃。
-
分配不会显示图形缓冲区中图像和视图使用的内存。这通常是两种工具之间最大差异的根源。这是对映射内存等的补充。
标签： ios debugging instruments