Cela ne sonne pas comme ça, mais juste au cas où ... si vous envisagez d'utiliser Conserver le nombre directement, ne .

En ce qui concerne les détails de la mise en œuvre, les sessions à la WWDC 2011 ont mentionné que, sous ARC, la majeure partie de la mise en œuvre du comptage de référence s'est déplacée dans l'OBJC Runtime. source pour cela est disponible , afin que vous puissiez découvrir vous-même Comment ça fonctionne. Pour le comptage de référence manuelle, une grande partie des comportements de l'OBJC sont reproduits dans la base de la fondation et de la libdispatch, qui sont également open source - si vous souhaitez mettre en œuvre un système similaire vous-même, ceux-ci pourraient s'avérer éducatif.

En général, il s'agit d'un détail de mise en œuvre pour la même raison que beaucoup de choses sont les suivantes: l'encapsulation est une bonne politique, en particulier pour les fournisseurs-cadres. Vous ne voulez pas les utilisateurs d'un cadre en fonction des détails de la mise en œuvre, car vous ne pouvez pas modifier votre implémentation sans casser leur code.

Nous ne savons pas exactement comment les données sont stockées, mais nous pouvons exclure quelques options:

Variables de mise en œuvre privées H1>

Nous pouvons l'exclure, simplement parce que lorsque nous iTertons à travers les ivars de la classe NsObject code>, nous ne voyons qu'un seul: isa code>, comme indiqué dans ce programme: p> xxx pré>

et note que Même des propriétés de mise en œuvre privées existent dans la classe METDATA. P>

propriétés privées h1>

Nous pouvons également l'exclure, car même les propriétés privées sont exposées dans les métadonnées de classes, comme indiqué par l'exemple suivant. , il n'y a pas de propriétés pour la classe NsObject code> Classe: p> xxx pré>

objets associés h1>

Celui-ci est très difficile à exclure, Comme il n'y a pas de façons directes d'obtenir une liste de tous les objets associés. Cependant, étant donné que le concept d'objets associés est très nouveau et que le comptage de référence existe depuis toujours, je dis que cela n'est pas très probable. P>

CoreFoundation structure-mangling h1>

c'est mon meilleure estimation. Lorsque vous créez un NsObject, il s'agit d'une structure dans les coulisses. Que dire que la représentation de données NsObject réelle est quelque chose comme ceci: p> xxx pré>

puis, lorsqu'un objet est créé: p>

id object_createInstance(...)
{
    CFObjectRef object = malloc(sizeof(struct CFObject));

    ...

    return (id) (object + sizeof(object->retainCount));
}

int object_retainCount(id self)
{
    CFObjectRef asObject = (CFObjectRef) (self - sizeof(asObject->retainCount));
    return asObject->retainCount;
}

L'emplacement de stockage du comptage de retenue dépend à la fois du temps d'exécution utilisé et de la mise en œuvre de la classe.

Pour l'exécution de l'objectif-C Apple, vous pouvez comprendre beaucoup en creuser dans Le code source de l'exécution de l'objectif-C .

Par exemple, si vous utilisez ARC (et je pense même si vous n'êtes pas), le nombre de références pour la plupart des objets sont stockés dans des tables de hachage. Regardez la fonction _OBJC_ROOTETAIN dans Runtime / objc-arr.mm . Je ne sais pas exactement pourquoi ils l'ont fait. Peut-être que c'est un moyen de conserver des comptes pour un meilleur comportement de cache (qui est important sous ARC, car l'ARC ajuste de retenir les comptes plus souvent que le code non arc ne le fait généralement pas).

Cependant, certaines classes remplacent conservent et des méthodes associées et stockent le nombre de retenons ailleurs. Par exemple, lors du débogage d'une fuite de mémoire, j'ai découvert que Calayer le fait. Au lieu d'utiliser le mécanisme de comptage normal de retenue normal de l'exécution, un Calayer stocke son compte de retenue dans un objet de mise en œuvre privé C ++. Ceci est plutôt frustrant car cela signifie que l'instrument d'allocations d'instruments ne se connecte pas conserve et des versions de calayer .