分配工具的不同行为（有和没有僵尸模式）
我确实在 iOS 中的内存管理方面遇到了困难，或者更准确地说是在监视复杂的内存使用情况。
所以实际上我想知道僵尸模式中提供的分配工具（当我寻找僵尸时）以及一般的“正常”分配工具（可从内存->分配中选择）。
如果我正在搜索僵尸，分配工具会向我显示当前分配的完全不同的存储数量（实时字节）。每次点击我的用户界面，活动字节都会增加很多。
但在正常的分配窗口（内存->分配）中，一切似乎（几乎绝对）都很好。因此，分配了 1,13 MB 的活动字节，但这是分配的最大字节数，与上面的描述相反，在上面的描述中，我可以通过在 UI 上单击一些来达到 4-5 MB。所以这对我来说真的很奇怪。
僵尸->分配中是否有一些在正常分配窗口中未考虑的更重要的内容？
注意：我的程序中没有僵尸和泄漏。
I'm really struggling with memory management in iOS or more precisely monitoring complex memory usages.
So actually I'm wondering about the allocations instrument provided once in Zombie-Mode (when I'm looking for zombies) and in general the "normal" allocations instrument (chosable from Memory->Allocations).
If I'm searching for Zombies the allocations instrument shows me completely different numbers of storage allocated at the moment (live Bytes). With every click on my UI the live bytes are increasing a lot.
But in the normal allocations window (Memory->allocations) everything seems to be (almost absolutely) fine. So, 1,13 MB of live bytes are allocated, but this is the maximum of allocated bytes in contrast to the description above where I can reach 4-5 MB with some clicks on my UI. So it seems really weird for me.
Is there something more count in Zombies->Allocations which is not regarded in the normal allocations-window?
Note: There are no zombies and leaks in my program.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我了解，Zombies 功能被视为与 Instruments 中的泄漏和对象分配是相互排斥的。
事实上，当您启用僵尸（Instruments 或 NSZombies 指令）时，会发生的情况是对象的“正常”保留周期被欺骗，以便您可以检测到使用已被释放的对象的尝试。从某种意义上说，我不知道有关它的详细信息，但就像保留计数增加一一样，当保留计数变为 1 时，您会收到有关尝试使用已释放实例的错误事实上，如果保留计数可能变为零，则该对象将被释放，并且在大多数情况下不可能检测到重用尝试，因为它可能会在释放后很长时间内发生，并且该内存块可能已被释放。重新分配给其他对象。因此，人为增加保留计数将有助于使对象能够在其“将要”的释放中幸存下来；当保留计数变为 1 时，会在对象中设置一个标志，以便运行时知道它正在尝试向“将要”释放的对象发送消息，并且您会收到完整的错误消息。
这只是我的心理模型，但它允许我解释为什么启用僵尸时内存分配要高得多（即，因为对象不会像正常情况下那样被释放）。
As far as I understand the Zombies feature, it is to be seen as mutually exclusive to leaks and object allocation in Instruments.
In fact, when you enable zombies (Instruments or NSZombies directive), what happens is that the "normal" retain cycle of objects is tricked so that you can detect the attempt at using an object that has already been deallocated. In some sense, I don't know the details about it, but it is like if the retain count is incremented by one, and that you get the error about the attempt at using an already deallocated instance, when the retain count goes to 1. Indeed, if the retain count could go to zero, the object would be deallocated and it would be in most cases impossible to detect the attempt at reuse, since it can happen a long time after the deallocation and that chunk of memory could have been reallocated to some other object. So the artificial increment of the retain count would serve to allow the object to survive its "would be" deallocation; when the retain count goes to 1, a flag is set in the object so that the runtime knows it is attempting to send a message to a "would be" deallocated object, and you get a full error message.
This is just my mental model of it, but it allows me to explain why memory allocation is much higher when zombies are enabled (i.e., because objects are not deallocated as they would be in normal case).