2010-03-16 4 views
0

J'ai une question dans la gestion de la mémoire (objectif C). Il y a deux scénarios idéaux.Gestion de la mémoire dans ObjC/iPhone

scénario ============================= 1 =============== =========================

(void) funcA 
{ 
    MyObj *c = [otherObj getMyObject]; 
    [c release]; 
} 

-(MyObj *) getMyObject //(this method is available in other OtherObj.m file) 
{ 
    MyObj *temp = [[MyObj alloc] init]; 
    // do smothing here 
    return temp; 
} 

================== =========== scénario 2 ================================== ===

(void) funcA 
{ 
    MyObj *c = [otherObj getMyObject]; 
} 

-(MyObj *) getMyObject //(this method is available in other OtherObj.m file) 
{ 
    MyObj *temp = [[myObj alloc] init]; 
    // do smothing here 
    return [temp autorelease]; 
} 

myObj contient d'énormes quantités de données.

Dans le premier scénario, je reçois myObj (alloué) à partir d'un autre fichier, donc je dois libérer dans ma propre méthode. (comme dans n'importe quelle bibliothèque de langage C/C++, comme strdup retournera la chaîne de caractères dupliquée qui se réalisera plus tard par le développeur et non par la méthode strdup).

Dans le second scénario, myObj (alloué) provient du fichier otherObj.m, donc le fichier otherObj.m est chargé de libérer la mémoire allouée (Autorelease moyenne). Est ce bien?

Faites-moi savoir quel scénario est le plus efficace et valide selon les directives de la mémoire Apple. S'il vous plaît ne me montrer aucun lien de document.

Merci Manu

+0

Vous pourriez vouloir cliquer sur la petite icône dans la barre d'outils avec tous les nombres binaires, il formate stuff comme code :). –

Répondre

1

Puis-je suggérer the documentation sur la gestion de la mémoire pour l'iPhone?

+0

Ici, la méthode getter vous donne un objet alloué. Identique à la méthode alloc ... mais pourquoi devrions-nous l'envoyer au pool autorelease. Nous pouvons distroy ceci après la méthode de gettter appelée. Je suis la personne responsable pour obtenir l'objet de sorte que je suis propriétaire de cette méthode ... pourquoi Apple n'est pas autorisé à libérer après la méthode getter .. il suggère que nous l'avons gardé en autorelease pool parce que la méthode gettter est propriétaire de cet objet. C'est la piscine autorelease moyenne va augmenter .. il va créer un problème si j'appelle cette méthode plusieurs fois? – Manoj

2

La deuxième approche est préférable. La convention est que seules les méthodes "alloc" et "copy" devraient renvoyer un objet dont la libération incombe à l'appelant. Cette convention est pour faciliter la maintenance et n'a rien à voir avec l'efficacité.

L'efficacité (du type mémoire) ne joue vraiment que si vous envisagez d'appeler getMyObject dans une boucle avec de nombreuses itérations. Dans ce cas, les objets MyObj auto-libérés s'accumuleront en mémoire car ils ne sont pas libérés avant la fin de l'itération de la boucle d'exécution. Si c'est un problème, déplacez alloc/init en dehors de l'appel de méthode afin de pouvoir libérer l'objet vous-même à la fin de chaque itération de votre boucle.

+0

Si chaque objet retourné par la méthode getter ira à la liste de libération automatique .. que le pool autoreleas augmentera et pourrait être ce qui peut créer une pénurie de mémoire? c'est possible? – Manoj

+0

En outre, les noms commençant par 'get' impliquent que vous allez le stocker dans une variable, comme' [obj getName: & someDestination] '. –

+0

@Manu: C'est correct. C'est pourquoi vous pouvez déplacer [[MyObj alloc] init] 'hors de' getMyObject' et dans 'funcA'. Ensuite, vous pouvez libérer l'objet dans 'funcA' comme vous le faites dans" scénario 1 ". – Tom