为什么活动监视器和分配工具报告的应用程序内存使用情况存在差异
我面临着很奇怪的问题。
应用程序 ~80.Mb
使用 Allocations Instrument 在模拟器上进行测试，显示当前正在使用大约 30 Mb，但使用活动监视器在 iPod 4g 上进行测试时，显示“已使用物理内存 ~ 133Mb”和“可用物理内存 ~ 77Mb”，这
是由于内存原因警告我的应用程序不断崩溃。
ActivityMonitor 和分配工具中使用的物理内存有什么区别？
早些时候，我信任分配工具，因为当我释放对象时，使用的内存量减少了，但在 ActivityMonitor 中，使用的内存量以一种奇怪的方式增加和减少，这与我正在做什么无关。 那么，帮助我理解，因为我认为分配的内存与使用的内存相同，还是我错了？
编辑： 似乎我了解数据在 ActivityMonitor 中显示的方式。但问题仍然存在。在 ActivityMonitor 中，图表下方有一列。在那里我找到了我的申请。而且内存只会增加。
100%无泄漏
I am facing quite strange problem.
Application ~80.Mb
Testing on simulator using Allocations Instrument, shows me that currently is using about 30 Mb but when testing on iPod 4g using Activity Monitor shows "Physical Memory Used ~ 133Mb" and "Physical Memory Free ~ 77Mb"
Due to the memory warnings my app constantly crashes.
What is the difference between Physical Memory Used in ActivityMonitor and Allocations Instrument?
Earlier I have trusted Allocations Instrument because when I released objects the amount of memory used decreased, but in ActivityMonitor the amount of USED memory is increasing and decreasing in a strange way that does not depend on what I am doing.
So, help me to understand, because I think the memory allocated is the same as memory used, or I am wrong?
Edit:
Seems I understood the way the data is shown in activitymonitor. But the problem persists. In ActivityMonitor there is column below the graph. There I found my application. And there memory is only increasing.
There are no leaks 100%
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
活动监视器对于开发/调试目的毫无用处。仅当您还没有运行仪器且尚未运行仪器时，AM 才有用。您会看到 RPRVT 随着时间的推移显着增长。即便如此，这也只是一个症状，可能并不表明真正的问题。
AM 是对一组不同内存相关数字的总结。这是一个非常粗略的数字。分配工具准确地总结了应用程序中的一组分配（在 Mac OS X 下，可能包括 GC 和非 GC 分配）。减少分配，总体内存使用量通常会下降。
请注意，没有内存压力的系统通常不会请求应用程序归还内存。也就是说，您可能不会看到活动监视器数量下降。
另请注意，“100% 没有泄漏”仅占减少内存使用总体工作的 10% 左右。您的应用程序因内存消耗过大而被抛弃。这要么是因为应用程序的算法使用大量内存的架构问题，要么是因为您的应用程序正在分配和放弃内存。废弃的内存可能不会显示为泄漏；例如，如果您有一个只写缓存，其中一个项目的重复项被一遍又一遍地放入缓存中，但从未被检索到，那么您的内存使用将逐渐失败，但泄漏将显示没有泄漏。
泄漏只是一个没有可行引用的对象。有效引用的对象仍然可能实际上是泄漏！
Heapshot 分析 对于解决这类问题非常有效。
Activity Monitor is useless for development/debugging purposes. AM is only useful if when you don't have Instruments running already & you see the RPRVT growing over time significantly. Even then, it is just a symptom and may not indicate a real problem.
AM is sort of summarizing a set of different memory related numbers. It is a very rough number. The Allocations instrument is summarizing exactly the set of allocations in your application (which, under Mac OS X, could include both GC and non-GC allocations). Reduce the allocations and the overall memory use will generally go down.
Note that a system not under memory pressure will often not request that applications give back memory. That is, you may not see a drop in Activity Monitors numbers.
Note also that "there are no leaks 100%" is only about 10% of the overall effort to reduce memory use. Your app is being jettisoned because of egregious memory consumption. That is either because of an architectural issue where your app's algorithms use way to much memory or because your app is allocating and abandoning memory. Abandoned memory may not show up as a leak; if you have, say, a write only cache where duplicates of an item are put into the cache over and over, but never retrieved, your memory use will grow to failure yet leaks will show no leaks.
A leak is merely an object for which there are no viable references. A viably referenced object may still effectively be a leak!
Heapshot analysis is brutally effective at sussing out this kind of problem.