Xcode仪器：内存术语实时字节和总字节数（真实内存）混淆 [英] Xcode Instrument : Memory Terms Live Bytes and Overall Bytes (Real Memory) confusion
问题描述
我正在开发一个浏览器应用程序，我在其中使用UIWebView打开网页。我使用Memory Monitor运行Instruments工具。我对仪器中使用的术语以及为什么它们很重要感到困惑。请以正当理由解释我的一些问题：
I am working on a Browser application in which I use a UIWebView for opening web pages. I run the Instruments tool with Memory Monitor. I am totally confused by the terms which are used in Instruments and why they're important. Please explain some of my questions with proper reasons:
-
实时字节对于检查内存优化或内存消耗很重要？为什么？
Live Bytes is important for checking memory optimization or memory consumption? Why ?
为什么我会关心整体字节/实内存，如果它还包含已发布的对象？
Why would I care about the Overall Bytes/ Real Memory, if it contains also released objects?
何时以及为何使用这些术语（实时字节数/总字节数/实内存量）？
When and why are these terms used (Live Bytes/ Overall Bytes/Real Memory)?
谢谢
推荐答案
Live Bytes 表示已分配的内存，但尚未分配重新分配的。这很重要，因为它是应用程序使用多少内存的最容易掌握的衡量标准。
"Live Bytes" means "memory which has been allocated, but not yet deallocated." It's important because it's the most easily graspable measure of "how much memory your app is using."
总字节数表示所有内存已被分配的内容，包括已被解除分配的内存。这不太有用，但可以让你对堆乱有所了解。流失导致碎片化，堆碎片可能是一个问题（虽然这些日子是一个相当模糊的。）
"Overall Bytes" means "all memory which has ever been allocated including memory that has been deallocated." This is less useful, but gives you some idea of "heap churn." Churn leads to fragmentation, and heap fragmentation can be a problem (albeit a pretty obscure one these days.)
真实记忆是一个尝试区分使用了多少物理RAM（而不是有多少字节的地址空间有效）。这与Live Bytes不同，因为Live Bytes可能包括与当前未被分页到物理RAM的内存映射文件（或共享内存或窗口后备存储或其他）相对应的内存范围。即使您不使用内存映射文件或其他奇特的VM分配方法，系统框架也可以使用它们，因此这种区别对每个进程都有一定的重要性。
"Real Memory" is an attempt to distinguish how much physical RAM is in use (as opposed to how many bytes of address space are valid). This is different from "Live Bytes" because "Live Bytes" could include ranges of memory that correspond to memory-mapped files (or shared memory, or window backing stores, or whatever) that are not currently paged into physical RAM. Even if you don't use memory-mapped files or other exotic VM allocation methods, the system frameworks do, and you use them, so this distinction will always have some importance to every process.
编辑：由于您显然担心使用UIWebView会导致内存使用，让我看看是否可以了解一下：
Since you're clearly concerned about memory use incurred by using UIWebView, let me see if I can shed some light on that:
使用UIWebView（即全局缓存等）存在一定的内存价格。这些包括各种全局字体缓存，JavaScript JIT缓存以及类似的东西。其中大多数都会表现得像单身人士：第一次使用时分配（通过使用UIWebView间接分配），并且在流程结束之前永远不会释放。还有一些可变大小的全局缓存（比如那些缓存Web响应; CFURL通常会管理这些缓存），但预计这些缓存将由系统管理。正如你所见，关于UIWebView的这些东西的集体重量是非平凡的。
There is a certain memory "price" to using UIWebView at all (i.e. global caches and the like). These include various global font caches, JavaScript JIT caches, and stuff like that. Most of these are going to behave like singletons: allocated the first time you use them (indirectly by using UIWebView) and never deallocated until the process ends. There are also some variable size global caches (like those that cache web responses; CFURL typically manages these) but those are expected to be managed by the system. The collective "weight" of these things with respect to UIWebView is, as you've seen, non-trivial.
我对UIKit或WebKit一无所知内部，但我希望如果你与某人做过讨论，他们对为什么我使用UIWebView导致如此多的内存使用？这一问题的回答。将是双管齐下：第一个分支是这是使用UIWebView的入场价格 - 它基本上就像在你的过程中运行整个网络浏览器。第二个分支是系统框架缓存由系统自动管理，这意味着，例如，CFURL缓存（这是使用UIWebView导致创建的东西之一）由系统管理，因此，如果出现内存警告，系统框架将负责从这些缓存中驱逐事物以减少它们消耗的内存;你无法控制那些，你只需要相信系统框架将会做你需要做的事情。 （在系统缓存管理器执行的操作不够激进的情况下，这对您没有帮助，但是您不会再对它们进行任何控制，因此您需要从另一个角度解决问题，无论哪种方式。）如果您想知道为什么在取消分配UIWebView后内存使用不会失效，这就是您的答案。它背后有很多东西，你无法控制。
I don't have any knowledge of UIKit or WebKit internals, but I would expect that if you had a discussion with someone who did, their response to the question of "Why is my use of UIWebView causing so much memory use?" would be two pronged: The first prong would be "this is the price of admission for using UIWebView -- it's basically like running a whole web browser in your process." The second prong would be "system framework caches are automatically managed by the system" by which they would mean that, for instance, the CFURL caches (which is one of the things that using UIWebView causes to be created) are managed by the system, so if a memory warning came in, the system frameworks would be responsible for evicting things from those caches to reduce the memory consumed by them; you have no control over those, and you just have to trust that the system frameworks will do what needs to be done. (That doesn't help you in the case where whatever the system cache managers do isn't aggressive enough for you, but you're not going to get any more control over them, so you need to attack the issue from another angle, either way.) If you're wondering why the memory use doesn't go down once you deallocate your UIWebView, this is your answer. There's a bunch of stuff it's doing behind the scenes, that you can't control.
分配，使用然后取消分配UIWebView的预期是净零操作，忽略了一些非平凡的，固有的和不可避免的副作用。这种副作用的存在不是（本身）指示UIWebView中的错误。到处都有像这样的副作用。如果你要创建一个简单的应用程序，除了启动之外什么都不做，然后在一次旋转运行循环后终止，并在 exit（）上设置一个断点，并查看已分配但从未释放的内存，将有数千个分配。这是在整个系统框架和几乎每个应用程序中使用的一种非常常见的模式。
The expectation that allocating, using, and then deallocating a UIWebView is a net-zero operation ignores some non-trivial, inherent and unavoidable side-effects. The existence of such side-effects is not (in and of itself) indicative of a bug in UIWebView. There are side effects like this all over the place. If you were to create a trivial application that did nothing but launch and then terminate after one spin of the run loop, and you set a breakpoint on exit(), and looked at the memory that had been allocated and never freed, there would be thousands of allocations. This is a very common pattern used throughout the system frameworks and in virtually every application.
这对您意味着什么？这意味着您实际上有两个选择：使用UIWebView并在内存消耗中支付入场费，或者不使用UIWebView。
What does this mean for you? It means that you effectively have two choices: Use UIWebView and pay the "price of admission" in memory consumption, or don't use UIWebView.
这篇关于Xcode仪器：内存术语实时字节和总字节数（真实内存）混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
