我正在开发一个浏览器应用程序，在该应用程序中我使用 UIWebView 打开网页.我使用内存监视器运行 Instruments 工具.我对 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 对于检查内存优化或内存消耗很重要吗?为什么?
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"表示所有已分配的内存，包括已释放的内存."这不太有用，但可以让您了解堆搅动".流失会导致碎片化，而堆碎片化可能是一个问题(尽管如今这个问题相当模糊.)
"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.)
"Real Memory" 试图区分有多少物理 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 Instrument:内存术语 Live Bytes 和 Total Bytes (Real Memory) 混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！