\nProprio per le ridotte capacit\u00e0 di elaborazione \u00e8 stato necessario privare i nostri iphone di una vera e propria Garbage Collection, utilizzando in sua vece un pi\u00f9 complesso Autorelease Pool<\/strong>.
\nMa quali sono le differenze? La GC monitora costantemente i nostri oggetti, i quali vengono eliminati solo su nostra richiesta o quando non esistono pi\u00f9 riferimenti per accedere a quell’oggetto. Questo\u00a0 implica che se esiste un riferimento ad un oggetto, questo \u00e8 sicuramente valido.
\nL’autorelease pool invece \u00e8 l’esatto contrario, elimina tutti gli oggetti, tranne quelli per i quali abbiamo fatta esplicita richiesta che vengano mantenuti. Il motivo di tale approccio \u00e8 facilmente intuibile, ed \u00e8 da ricercare nel fatto che nei device attuali la memoria \u00e8 un bene prezioso e ci non possiamo permettere che i nostri programmi la sprechino.<\/p>\n
L’autorelase viene istanziato nel main delle nostre applicazioni, con questa istruzione:<\/p>\n
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];<\/pre>\ne lo possiamo considerare quindi alla stessa stregua del tristo mietitore pronto ad eliminare tutti gli oggetti ritenuti inutili, compito che svolge analizzando una particolare propriet\u00e0 di ogni oggetto chiamata retainCount. <\/em>In particolare vengono eliminati tutti quegli oggetti che hanno un valore di retainCount<\/em> pari a zero.
\nPer far funzionare il nostro programma secondo le nostre aspettative dovremo quindi fare in modo che gli oggetti necessari\u00a0 abbiamo retainCount<\/em> maggiore o uguale a 1.<\/p>\nSe per qualche ragione siamo interessati a sapere quando l’autorelease elimina i nostri oggetti, possiamo sfruttare il fatto che viene invocato in maniera trasparente il metodo dealloc <\/em>sull’oggetto da eliminare, quindi eseguendo un opportuno override di questo metodo possiamo ottenere tutte le informazioni di cui abbiamo bisogno.<\/p>\nQuali sono quindi i momenti in cui retainCount <\/em>varia?<\/p>\n\n- Quando una variabile viene inizializzata il suo retainCount<\/em> viene incrementato di 1.<\/li>\n
- I metodi alloc, copy, allocWithZone <\/em>incrementano retainCount <\/em>di 1.<\/li>\n
- I metodi release, autorelease <\/em>decrementano retainCount <\/em>di 1. (autorelease lo fa in un momento non deterministico)<\/li>\n
- Se non diversamente specificato il metodo autorelease <\/em>viene invocato di default.<\/li>\n<\/ul>\n
Vediamo qualche esempio:<\/p>\n
TheClass *newObject = [[TheClass alloc] init];<\/pre>\nIn questo caso il retainCount <\/em>di newObject sar\u00e0 1\u00a0 per via del metodo alloc. <\/em>(in realt\u00e0 riceve anche un +1 per l’inizializzazione e un -1 per l’autorelease implicito)
\nL’area di memoria assegnata a questo oggetto quindi non potr\u00e0 essere liberata, neanche quando usciremo dallo scope della variabile newObject. In questo caso avremo perso ogni riferimento a questo oggetto e avremo creato quello che viene chiamato leak<\/strong>.<\/p>\nNSString *myString = @\"Hello World\";<\/pre>\nIn questo caso il retainCount <\/em>di myString <\/em>sar\u00e0 pari a zero, perch\u00e8 +1 lo ricever\u00e0 per via della inizializzazione e -1 per via dell’ autorelease <\/em>implicito. Questo significa che la zona di memoria assegnata a myString <\/em>verr\u00e0 liberata dall’autoreleasePool <\/em>nonappena questi lo riterr\u00e0 opportuno, non prima del termine dell’esecuzione del metodo corrente per\u00f2!<\/p>\nNSString *myString = [NSString stringWithFormat:@\"HELLO WORLD\"] autorelease];<\/pre>\nStesso caso del precedente ma con la chiamata esplicita di autorelease.<\/em><\/p>\nFacciamo un piccolo esempio per comprendere quando sia indispensabile la far propri questi meccanismi. Dichiariamo in una nostra classe una variabile (variabile di istanza)<\/p>\n
NSString *myString<\/pre>\nLa inizializziamo in un metodo, e vi accediamo da un secondo.<\/p>\n
- (void)viewDidLoad {\r\n myString = [[NSString stringWithFormat:@\"ciao\"] autorelease];\r\n [super viewDidLoad];\r\n}\r\n\/\/..altro codice...\r\n- (IBAction)otherMethod:(id)sender{\r\n NSLog(myString);\r\n}<\/pre>\nQuesto codice per quanto sembri corretto invece andr\u00e0 in errore, perch\u00e8 avendo chiamato il metodo autorelease <\/em>sull’oggetto myString ne abbiamo portato il retainCount <\/em>a zero, quindi viene eliminata dall’autorelease pool.<\/em><\/p>\nUn caso ancora pi\u00f9 significativo avviene quando gli oggetti diventano parametri dei nostri metodi, vediamo questo codice:<\/p>\n
\/\/CLASSE 1\r\n- (void)metodo1{\r\n\tNSString *saluto = [NSString stringWithFormat:@\"Ciao mondo\"];\r\n\t[classe2 metodo2:saluto]\r\n}\r\n\/\/CLASSE2\r\nNSString *newString;\r\n- (void)metodo2:(NSString *)str{\r\n newString = str;\r\n}\r\n- (void)metodo3{\r\n NSLog(newString);\r\n}<\/pre>\nL’invocazione del metodo3 causer\u00e0 un crash della nostra applicazione perch\u00e8 l’oggetto stringa saluto<\/em> definita nel metodo1, \u00e8 di tipo autorelease<\/em> e quindi verr\u00e0 rimosso dall’autorelease pool. <\/em>All’interno del metodo2 l’operazione newString=str non fa altro che assegnare al puntatore newString<\/em> lo stesso indirizzo di\u00a0 str<\/em> che era lo stesso di saluto<\/em> (ricordiamoci che in fondo parliamo sempre di puntatori C ) quindi quando l’oggetto saluto <\/em>verr\u00e0 eliminato i riferimenti all’interno di newString <\/em>non saranno pi\u00f9 validi ed ogni tentativo di accesso produrr\u00e0 il famoso errore EXC_BAD_ACCESS.<\/p>\nAlla prossima.<\/p>\n
\n![\"\"](\"http:\/\/www.devapp.it\/wordpress\/wp-content\/uploads\/2010\/02\/bannerIgnazioc.png\")
<\/a>
\n<\/center><\/p>\n","protected":false},"excerpt":{"rendered":"In questo articolo analizzeremo un aspetto della programmazione per iphone che spesso \u00e8 responsabile di lunghe ore…<\/p>\n","protected":false},"author":53,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[6,55,5,18,4,17],"class_list":["post-1069","post","type-post","status-publish","format-standard","hentry","category-guide-teoriche","tag-iphone","tag-memoria","tag-objective-c","tag-oop","tag-programmazione","tag-teoria"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/1069","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/comments?post=1069"}],"version-history":[{"count":21,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/1069\/revisions"}],"predecessor-version":[{"id":5014,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/posts\/1069\/revisions\/5014"}],"wp:attachment":[{"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/media?parent=1069"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/categories?post=1069"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devapp.it\/wordpress\/wp-json\/wp\/v2\/tags?post=1069"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}