Le principal problème lié à la mémoire dont vous devez toujours être conscient est la conservation des cycles. Cela se produit lorsqu'un objet a un pointeur fort vers un autre, mais l'objet cible a un pointeur fort vers l'original. Même lorsque toutes les autres références à ces objets sont supprimées, elles se maintiennent les unes aux autres et ne sont pas publiées. Cela peut également se produire indirectement, par une chaîne d'objets qui pourrait avoir le dernier de la chaîne renvoyant à un objet antérieur.
C'est pour cette raison que les qualificatifs __unsafe_unretainedet __weakpropriétaires existent. Le premier ne conservera aucun objet sur lequel il pointe, mais laisse ouverte la possibilité que cet objet s'éloigne et qu'il pointe vers une mauvaise mémoire, tandis que le second ne conserve pas l'objet et se met automatiquement à zéro lorsque sa cible est désallouée. Des deux, __weakest généralement préféré sur les plates-formes qui le prennent en charge.
Vous utiliseriez ces qualificatifs pour des choses comme les délégués, où vous ne voulez pas que l'objet conserve son délégué et mène potentiellement à un cycle.
Un autre couple de problèmes importants liés à la mémoire est la gestion des objets Core Foundation et de la mémoire allouée à l'aide malloc()de types comme char*. ARC ne gère pas ces types, uniquement les objets Objective-C, vous devrez donc toujours les gérer vous-même. Les types de Core Foundation peuvent être particulièrement délicats, car ils doivent parfois être reliés à des objets Objective-C correspondants, et vice versa. Cela signifie que le contrôle doit être transféré dans les deux sens depuis l'ARC lors du pontage entre les types CF et Objective-C. Certains mots clés liés à ce pont ont été ajoutés, et Mike Ash a une excellente description de divers cas de pontage dans sa longue rédaction ARC .
En plus de cela, il existe plusieurs autres cas moins fréquents, mais toujours potentiellement problématiques, que la spécification publiée détaille.
Une grande partie du nouveau comportement, basé sur la conservation des objets tant qu'il y a un pointeur fort vers eux, est très similaire à la récupération de place sur Mac. Cependant, les fondements techniques sont très différents. Plutôt que d'avoir un processus de ramasse-miettes qui s'exécute à intervalles réguliers pour nettoyer les objets qui ne sont plus pointés, ce style de gestion de la mémoire repose sur les règles rigides de conservation / libération que nous devons tous respecter dans Objective-C.
ARC prend simplement les tâches de gestion de mémoire répétitives que nous avons dû faire pendant des années et les décharge sur le compilateur afin que nous n'ayons plus jamais à nous en soucier. De cette façon, vous n'avez pas les problèmes d'arrêt ou les profils de mémoire en dents de scie rencontrés sur les plateformes de récupération de place. J'ai connu ces deux problèmes dans mes applications Mac récupérées et je suis impatient de voir comment ils se comportent sous ARC.
Pour en savoir plus sur la collecte des ordures par rapport à ARC, consultez cette réponse très intéressante de Chris Lattner sur la liste de diffusion Objective-C , où il énumère de nombreux avantages d'ARC par rapport à la collecte des ordures Objective-C 2.0. J'ai rencontré plusieurs des problèmes du GC qu'il décrit.