Différences entre Objective-C 2.0 et CLR en ce qui concerne la gestion de la mémoire

Question

J'ai appris à développer des applications sur la plateforme Cocoa Touch. J'ai parcouru un long chemin, mais la gestion de la mémoire est un élément qui me rend mal à l'aise.

Je pensais que je choisirais une voie de comparaison plutôt que d’essayer de partir de zéro. Je ne trouve pas grand chose sur la différence entre le CLR (.net) et Objective-C 2.0. Je me demande donc si la communauté de débordement de pile peut m'aider à résoudre ce problème.

Quelles sont les différences clés / importantes dans la gestion de la mémoire entre Objective-C 2.0 et le CLR? En ce qui concerne Objective-C 2.0, je développe sur le système d'exploitation iPhone et la fonctionnalité de libération automatique est déconseillée.

Je suppose que je suis à la recherche d'une comparaison des deux ... Puisque je viens d'un environnement .NET, quelles sont les choses que je dois savoir sur la gestion de la mémoire Objective-C 2.0?

Merci à tous!

Answer 1

Le CLR s'exécute sur une machine virtuelle; toute la désallocation d'objets est gérée par le système de récupération de place. En règle générale, la mémoire Objective-C doit être gérée manuellement via l'ancien malloc / free de style C ou via le système de comptage de références de retenue / libération. Si vous venez d’un standard " C " arrière-plan, la technique ne semblera pas trop étrangère.

Avec le comptage de références, le système compte le nombre de fois qu'un objet spécifique est utilisé - il s'agit en gros du paramètre "conserver". mentionné ci-dessus. Lorsque quelque chose est fait en utilisant un objet, l’objet est envoyé manuellement par un "communiqué". message décrivant le nombre de retenues de l'objet de 1. Lorsque le nombre atteint 0, le système libère automatiquement l'objet. Cela semble extrêmement lourd par rapport au CLR / .NET, mais ce mécanisme offre de meilleures performances et davantage de contrôle.

Si vous codez en Objective-C 2.0 sur Macintosh, vous avez de la chance car la récupération de place peut être activée via une option dans XCode. Ce sera plus proche de ce que le CLR fournit. Si vous développez sur l'iPhone, la récupération de place coûte trop cher en termes de mémoire et de processeur, de sorte que ce n'est pas une option. La mémoire doit être gérée manuellement.

Heureusement, il existe une option intermédiaire utilisée couramment par l'envoi et "autorelease". message à un objet. Ce mécanisme, inclus à la fois dans Macintosh et dans l’iPhone, regroupe essentiellement les objets alloués dans un dictionnaire global (il s’appelle en réalité un pool autorelease). Lorsque l’application existe ou lorsque le pool est vidé, les objets sont alors désaffectés. Cependant, tout ne va pas dans la liste de libération automatique et vous ne voulez pas tout mettre là. Je recommande la lecture sobre mais importante du langage de programmation Objective-C 2.0 du site Apple, qui donne plus de détails.

http://developer.apple.com/documentation /Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html

Bonne chance et patience. Objective-C n’est pas un petit nouveau sur le bloc comme .Net (il a plus de 25 ans), mais il possède des fonctionnalités incroyables que .Net commence tout juste à intégrer.

Answer 2

Sur l’iPhone, c’est manuel. Si vous allouez ou conservez de la mémoire, vous devez la libérer.

Dans le .NET CLR, vous ne vous souciez pas de la mémoire ni de ce que l’objet en fait pour la plupart.

Pour l'iPhone, vous devez équilibrer chaque allocation d'objet, initialiser ou conserver avec une version. Comme l'iPhone utilise un mécanisme de comptage de références simple, une fois que le compte est tombé à 0, l'objet est nettoyé.

Une chose à laquelle je devais m'habituer est que vous pouvez avoir une propriété qui effectue automatiquement une rétention. Ainsi, si vous créez un objet, assignez-le à la propriété. Il aura alors un nombre de 2. Ce qui fonctionne mieux est de créer le objet à une variable temp assignée à la propriété, puis relâchez la variable temp pour obtenir le compte à 1.