xcode 如何摆脱Objective-C中的常驻脏内存？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5430718/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How can I get rid of resident dirty memory in Objective-C?
提问by Josh Brown
I watched Apple's WWDC 2010 video on Advanced Memory Analysis with Instruments and from that, I was able to find a lot of resident dirty memory. I realize that having so much resident dirty memory is a bad thing (and probably the explanation for my app crashing so much...), but I'm not sure how to fix it. Where should I look?
我观看了 Apple 的 WWDC 2010 上关于使用仪器进行高级内存分析的视频，从中我能够找到很多常驻脏内存。我意识到拥有如此多的常驻脏内存是一件坏事（可能是我的应用程序崩溃的原因......），但我不知道如何解决它。我应该在哪里看？
Instruments shows me a lot of potentially useful information that looks like gibberish to me, such as:
Instruments 向我展示了许多对我来说看起来像是胡言乱语的潜在有用信息，例如：
% of Res Type Resident Size
18% VM_ALLOCATE (8192 pages) 32.00 MB
This is in the "Dirty" category - 32 MB of resident dirty memory is a lot on a device that only has 256 MB, right? :) There are several more large chunks like this. How do I trace this back to my code from Instruments? Or should I just forget Instruments and look for specific issues in my code?
这属于“脏”类别 - 32 MB 的常驻脏内存在只有 256 MB 的设备上很多，对吗？:) 还有几个像这样的大块。我如何从 Instruments 追溯到我的代码？或者我应该忘记 Instruments 并在我的代码中查找特定问题？
回答by Steve Madsen
Do you see this 32 MB chunk of VM_ALLOCATE when running on the device or in the simulator?
在设备或模拟器中运行时，您是否看到了这个 32 MB 的 VM_ALLOCATE 块？
I ask because when I played around with the allocations instrument on the OS X app I'm working on, I also noticed a 32 MB chunk of VM_ALLOCATE and I'm wondering if this is a by-product of running in the OS X environment. Running on the device may give you a different data set.
我问是因为当我在我正在开发的 OS X 应用程序上使用分配工具时，我还注意到一个 32 MB 的 VM_ALLOCATE 块，我想知道这是否是在 OS X 环境中运行的副产品. 在设备上运行可能会为您提供不同的数据集。
In general, though, resident memory is the memory that your app is using that is not swapped out to disk. On iOS, there is no swap, so resident memory should equal your virtual memory footprint.
但是，一般而言，常驻内存是您的应用程序正在使用的未换出到磁盘的内存。在 iOS 上，没有交换，所以常驻内存应该等于你的虚拟内存占用。
Dirty memory is memory you've allocated and used. Dirty memory should be less than resident memory because the latter includes code (yours and frameworks).
脏内存是您分配和使用的内存。脏内存应该少于常驻内存，因为后者包括代码（你的和框架）。
I'm not sure exactly what you're doing in your app, but I'll guess that you've loaded some large assets from your bundle and are keeping them around. Don't do this, when possible.
我不确定你在你的应用程序中到底在做什么，但我猜你已经从你的包中加载了一些大的资产并把它们留在身边。尽可能不要这样做。
There are also APIs you can use when loading NSData objects that use a memory-mapping technique instead of brute-force reading the bytes. These can be better because it allows the OS to read the pages from disk lazily. With NSData (since it's non-mutable), it might also be smart enough to mark the pages as read-only. Theoretically, this is a valuable hint to the OS that it can purge those pages when under pressure, since it knows they can't change. Read the docs for +[NSData dataWithContentsOfMappedFile:].
在加载使用内存映射技术而不是蛮力读取字节的 NSData 对象时，您还可以使用一些 API。这些可能会更好，因为它允许操作系统懒惰地从磁盘读取页面。使用 NSData（因为它是不可变的），它也可能足够聪明，可以将页面标记为只读。从理论上讲，这对操作系统来说是一个有价值的提示，它可以在压力下清除这些页面，因为它知道它们无法更改。阅读文档+[NSData dataWithContentsOfMappedFile:]。
For images, I recall reading something that suggested avoiding imageNamed:except for images that you regularly used through your app (i.e. UI elements). For large images especially, they can remain in a cache that you don't have control over. (imageNamed:had a leak in the 2.x days, but it was fixed in 3.x and is perfectly safe to use today.) Use imageWithContentsOfFile:for larger images and images that aren't a recurring part of your UI.
对于图像，我记得读过一些建议避免的内容，imageNamed:除了您经常通过应用程序使用的图像（即 UI 元素）。特别是对于大图像，它们可以保留在您无法控制的缓存中。（imageNamed:在 2.x 天有一个泄漏，但它在 3.x 中被修复，今天使用是完全安全的。）imageWithContentsOfFile:用于较大的图像和不是 UI 重复出现的部分的图像。
If you're loading images from the network, cache them on disk and free the raw bytes after you create the UIImage. If the image views are unloaded due to memory pressure, you don't want to hit the network to load the data again, but you also don't want to keep two copies (an NSDataand the UIImage) loaded.
如果您从网络加载图像，请将它们缓存在磁盘上并在创建UIImage. 如果图像视图由于内存压力而卸载，您不想再次访问网络加载数据，但您也不想保留两个副本（anNSData和 the UIImage）已加载。
回答by Al Pascual
With the new xCode 4 the tools coming from xCode 3 still there with a better user interface to profile your application including leaks and memory usage. I would recommend you to look at those tools and run one by one to see what are they providing you. You can access to those tools in xCode 4 on the main menu Product and then -> Profile
使用新的 xCode 4，来自 xCode 3 的工具仍然存在，具有更好的用户界面来分析您的应用程序，包括泄漏和内存使用情况。我建议您查看这些工具并一一运行，看看它们为您提供了什么。您可以在 xCode 4 的主菜单 Product 中访问这些工具，然后 -> Profile
Hope this helps
希望这可以帮助
回答by Alex
In instruments click enable snapshots automatically Change view mode to regions map. Find in path names of files, which u r using while u application living in vmpages And after when u clear it. In video wwdc example they was using encryption for file and this was push it to vmpages, without u code too hard to suggest something more than [library flush] :-)
在仪器中单击自动启用快照将视图模式更改为区域映射。在文件的路径名中查找，当你的应用程序存在于 vmpages 中时你正在使用它，并在你清除它之后。在视频 wwdc 示例中，他们对文件使用加密，这将它推送到 vmpages，没有你的代码太难建议比 [library flush] 更重要的东西:-)
回答by Nick Staresinic
"This is in the "Dirty" category - 32 MB of resident dirty memory..." "I also noticed a 32 MB chunk of VM_ALLOCATE and I'm wondering..."
“这属于“脏”类别 - 32 MB 的常驻脏内存……” “我还注意到一个 32 MB 的 VM_ALLOCATE 块，我想知道……”
I see the same "VM_ALLOCATE (8192 pages) 32 MB" for resident, dirty, and virtual columns in the VM Tracker when I profile my apps in the Simulator.
当我在模拟器中分析我的应用程序时，我在 VM Tracker 中看到相同的“VM_ALLOCATE（8192 页）32 MB”用于常驻、脏和虚拟列。
For comparison, I've profiled the (smaller) demo apps built from Paul Hegarty's veryinformative iTunes U Stanford course -- e.g., Psychologist and the Graphing Calculator -- and see the same entry in each.
为了便于比较，我异形（小）演示应用程序是从保罗·赫加蒂内置非常翔实的iTunes U斯坦福课程-例如，心理学家和图形计算器-看看在每个相同的条目。
I'm a 'domain guy' and don't yet have a strong grasp of the details of memory management, so I can't offer an authoritative explanation, but it seems reasonable to conclude that this allocation is owed to elements of the Framework common to all apps run on the Simulator. (I haven't run them on a device.)
我是一个“领域专家”，对内存管理的细节还没有很强的把握，所以我不能提供权威的解释，但得出这种分配是由于框架的元素而得出的结论似乎是合理的在模拟器上运行的所有应用程序都是通用的。（我没有在设备上运行它们。）
(FYI: Xcode 4.3 on a MacBook Pro running 10.7.3)
（仅供参考：运行 10.7.3 的 MacBook Pro 上的 Xcode 4.3）
