Est-ce que j'ai besoin de libérer les ressources xib ?

Question

Si j'ai quelque chose comme un UILabel lié à un fichier xib, dois-je le libérer dans dealloc de ma vue ? La raison pour laquelle je demande est que je ne l'alloue pas, ce qui me fait penser que je n'ai pas besoin de le libérer non plus ? par exemple (dans l'en-tête) :

IBOutlet UILabel *lblExample;

dans l'implémentation :

....
[lblExample setText:@"quelquechose"];
....

-(void)dealloc{
    [lblExample release];//?????????
}

Answer 1

Si vous suivez ce qui est désormais considéré comme la meilleure pratique, vous devriez libérer les propriétés de sortie, car vous auriez dû les conserver dans le mutateur de définition :

@interface MyController : MySuperclass {
    Control *uiElement;
}
@property (nonatomic, retain) IBOutlet Control *uiElement;
@end

@implementation MyController

@synthesize uiElement;

- (void)dealloc {
    [uiElement release];
    [super dealloc];
}
@end

L'avantage de cette approche est qu'elle rend les sémantiques de gestion de mémoire explicites et claires, et elle fonctionne de manière cohérente sur toutes les plateformes pour tous les fichiers nib.

Remarque : Les commentaires suivants s'appliquent uniquement à iOS antérieur à la version 3.0. À partir de la version 3.0, vous devez simplement annuler les valeurs des propriétés dans viewDidUnload.

Une considération ici, cependant, concerne le moment où votre contrôleur peut se débarrasser de son interface utilisateur et la recharger dynamiquement à la demande (par exemple, si vous avez un contrôleur de vue qui charge une vue à partir d'un fichier nib, mais sur demande -- disons en cas de pression sur la mémoire -- la libère, en espérant qu'elle puisse être rechargée si la vue est à nouveau nécessaire). Dans cette situation, vous voulez vous assurer que lorsque la vue principale est détruite, vous abandonnez également la propriété de toute autre connexion afin qu'elles puissent également être désallouées. Pour UIViewController, vous pouvez gérer ce problème en remplaçant setView: comme suit :

- (void)setView:(UIView *)newView {
    if (newView == nil) {
        self.uiElement = nil;
    }
    [super setView:aView];
}

Malheureusement, cela donne lieu à un autre problème. Parce que UIViewController implémente actuellement sa méthode dealloc en utilisant la méthode d'accès setView: (plutôt que de simplement libérer directement la variable), self.anOutlet = nil sera appelé dans dealloc ainsi qu'en réponse à un avertissement de mémoire... Cela entraînera un plantage dans dealloc.

Le remède est de s'assurer que les variables de sortie sont également définies sur nil dans dealloc:

- (void)dealloc {
    // libérer les sorties et définir les variables sur nil
    [anOutlet release], anOutlet = nil;
    [super dealloc];
}

Answer 2

J'ai trouvé ce que je cherchais dans la documentation d'Apple. En bref, vous pouvez configurer vos objets en tant que propriétés que vous libérez et gardez en mémoire (ou simplement @property, @synthesize), mais ce n'est pas nécessaire pour des choses comme les UILabels :

http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_4.html#//apple_ref/doc/uid/10000051i-CH4-SW18

Answer 3

La

[unOutlet release], unOutlet = nil;

Partie est complètement superflue si vous avez correctement écrit setView:.

Answer 4

Si vous ne le libérez pas lors de la libération, il augmentera l'empreinte mémoire.

Voir plus de détails ici avec le graphique ObjectAlloc de l'instrument

Answer 5

Tout IBOutlet qui est une sous-vue de la vue principale de votre Nib n'a pas besoin d'être libéré, car ils recevront le message autorelease lors de la création de l'objet. Les seuls IBOutlet que vous devez libérer dans votre dealloc sont les objets de niveau supérieur comme les contrôleurs ou d'autres NSObject. Tout cela est mentionné dans le document Apple lié ci-dessus.