Different behaviour for allocations instruments (with and without zombie-mode)

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 i开发者_如何学Cn Zombies->Allocations which is not regarded in the normal allocations-window?

Note: There are no zombies and leaks in my program.

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).