{"id":4010,"date":"2010-07-14T14:42:54","date_gmt":"2010-07-14T12:42:54","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=4010"},"modified":"2010-07-14T14:42:54","modified_gmt":"2010-07-14T12:42:54","slug":"l012-gestione-della-memoria-durante-lo-sviluppo-di-applicazioni-iphone-e-ipad","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/l012-gestione-della-memoria-durante-lo-sviluppo-di-applicazioni-iphone-e-ipad\/","title":{"rendered":"L#012 – Gestione della memoria durante lo sviluppo di applicazioni iPhone e iPad"},"content":{"rendered":"

\"Logo<\/a> Oggi parliamo di gestione della memoria nelle applicazioni iPhone (e iPad). Dopo un primo ottimo articolo<\/a> sull’argomento, creato dal nostro Ignazio Cal\u00f2, abbiamo pensato fosse meglio, viste le numerose richieste, spendere ancora un paio di parole su questo tema di vitale importanza per lo sviluppo di applicazioni per dispositivi mobili come appunto iPhone, iPod Touch e iPad.<\/p>\n

Perch\u00e8 \u00e8 cos\u00ec importante la gestione della memoria?<\/h4>\n

Gestire la memoria significa prima di tutto evitare di sprecare inutilmente risorse (in questo caso di memoria), che, soprattutto nel caso dei dispositivi mobili, ritroviamo in quantit\u00e0 limitata e non espandibile. Ovviamente gestire la memoria non \u00e8 solo importante per questo tipo di device, ma anche per le applicazioni desktop, le cui funzionalit\u00e0 potrebbero portare ad occupare enormi quantit\u00e0 di memoria (pensate ad esempio ad applicazioni di tipo scientifico). Quanto mostreremo in questo articolo sar\u00e0 utile quindi non solo per lo sviluppo di applicazioni iPhone e iPad, ma anche per quello di applicazioni MacOS.<\/p>\n

Come saprete (o comunque intuirete) ogni variabile, puntatore, oggetto o altro elemento del nostro programma occupa memoria e anche se potrebbero sembrarvi quantit\u00e0 minime, sappiate che l’apparenza, spesso, inganna. Perch\u00e8 dico questo? Objective-C (il linguaggio principale con cui lavoriamo) \u00e8 un linguaggio orientato agli oggetti, e questa potente tecnica di programmazione, come sapete, ci offre funzionalit\u00e0 potentissime, ma allo stesso tempo molto pericolose se non capiamo a fondo il loro principio di funzionamento. Una di queste potenti (e pericolose) caratteristiche \u00e8 l’ereditariet\u00e0, ovvero la caratteristica che ci permette di creare nuovi oggetti personalizzati, partendo da altri esistenti mantenendo tutte le carattaristiche (propriet\u00e0 e metodi) dell’oggetto di partenza.<\/p>\n

Ora, come ben saprete la maggior parte del nostro lavoro su iPhone e iPad si basa sul framework Cocoa Touche in particolare dall’UIKit, offerto da Apple, (maggiori informazioni qui<\/a>) e come potete vedere dal seguente schema esiste una gerarchia specifica per gli oggetti di questo utile kit, in particolare notate come tutti gli oggetti siano derivati di un unico “super” oggetto: NSObject.<\/p>\n


\n\"UIKit\"<\/a>
\n<\/center><\/p>\n

Ora immaginiamo un semplice caso, dobbiamo creare una nuova classe con metodi ed eventi personalizzati, che eredita direttamente da NSObject. Analizzando il file di interfaccia della nostra nuova classe, potremmo trovarci di fronte a qualcosa di simile:<\/p>\n

\r\n@interface MyClass: NSObject {\r\n    IBOutlet UITextField *myTextField;\r\n}\r\n\/\/ Eventuali metodi\r\n@end\r\n<\/pre>\n
Istanziato un oggetto di questa classe, come minimo dovremo aver sufficiente spazio in memoria da allocare per contenere un oggetto UITextField, ma non solo. Dato che questa classe eredita da NSObject, dobbiamo aver spazio sufficiente per contenere anche tutti gli elementi di questo oggetto!<\/p>\n
Immaginate ora di creare un nuovo oggetto partendo invece da UITextField, in questo caso dovrete prevedere di aver spazio in memoria per i nuovi elementi e, secondo lo schema sopra, anche per gli elementi di UITextField (da cui ereditate direttamente), ma anche quelli di UIControl (da cui eredita UITextField), UIView (da cui eredita UIControl), UIResponder (da cui eredita UIView) e infine NSObject. Insomma, come potrete intuire le cose si complicano un pochino e di fatto, se pensavate di cavarvela con poca memoria, in realt\u00e0 ci rendiamo conto che ne serve pi\u00f9 del previsto e dovremo allocare la quantit\u00e0 di memoria necessaria a contenere sia i nuovi elemente da noi creati che tutti quelli ereditati. Oltre ad allocare la quantit\u00e0 corretta di memoria, capirete quindi che sar\u00e0 il caso, inoltre, di liberare appena possibile la memoria utilizzata, ovvero quando l’oggetto residente in memoria non serve pi\u00f9.  <\/p>\n
Insomma, un attenta pianificazione e gestione della memoria pu\u00f2 essere decisiva per il successo della vostra applicazione iPhone!<\/p>\n
Allocare la giusta quantit\u00e0 di memoria per un oggetto in Objective-C (alloc, init)<\/h4>\n
Allocare la corretta quantit\u00e0 di memoria (ricordate ne che abbiamo una quantit\u00e0 limitata da usare), sembrerebbe quindi un processo lungo e complesso, ma non \u00e8 cos\u00ec. Il framework, e in particolare proprio il “super” oggetto NSObject, ci offre infatti un metodo di classe molto utile: Alloc<\/strong>!<\/p>\n
Grazie a questo metodo (che potremo usare nei nostri oggetti che ereditano direttamente o indirettamente da NSObject) saremo in grado di allocare la giusta quantit\u00e0 di memoria sia per tutti i nostri nuovi elementi. che per quelli ereditati. A livello di codice \u00e8 molto semplice, se dovessimo creare nel nostro programma un’istanza di MyClass, questo potrebbe essere il codice da scrivere:<\/p>\n
\r\n    MyClass *myNewClass = [MyClass alloc];\r\n<\/pre>\n
L’istruzione \u00e8 ancora incompleta, infatti dobbiamo ancora inizializzare il nostro oggetto perch\u00e8 sia pronto per essere utilizzato all’interno del nostro programma. Per farlo possiamo sfruttare un altro metodo offerto da NSObject: init<\/strong>!
\nGrazie ad “init” potremo appunto inizializzare i nostri oggetti, ovvero dotarlo della configurazione di default che servir\u00e0 all’avvio dell’applicazione (o meglio al momento della creazione dell’oggeto). Anche qui il codice \u00e8 molto semplice:<\/p>\n
\r\n    MyClass *myNewClass = [[MyClass alloc] init];\r\n<\/pre>\n
Unica cosa che dobbiamo ricordare \u00e8 che come lo spazio da allocare deve essere calcolato anche per gli elementi degli oggetti da cui si eredita, anche l’inizializzazione deve essere fatta per questi stessi elementi. Niente paura, anche per questo ci baster\u00e0 un’unica riga di codice all’interno del metodo init nell’implementazione della nostra classe:<\/p>\n
\r\n- (id)init {\r\n    [super init];\r\n    \/\/ Codice per inizializzazione\r\n   return self;\r\n}\r\n<\/pre>\n
Grazie all’istruzione [super init] non ci dovremo preoccupare di inizializzate tutto manualmente.
\nA questo punto il nostro oggetto “myNewClass ” \u00e8 pronto per essere utilizzato.<\/p>\n
Liberare la memoria al momento giusto (retain, release, dealloc)<\/h4>\n
Per la creazione del nostro oggetto nel programma \u00e8 tutto, \u00e8 infatti stata creata un’istanza della nostra classe, la abbiamo allocata in memoria (considerando lo spazio necessario) e infine la abbiamo inizializzata a dovere per poterla utilizzare come meglio crediamo. Ovviamente la gestione della memoria non si limita a questo, dovremo infatti prevedere, ad un certo punto, di liberare lo spazio di memoria occupato dalla stessa. NSObject offre un metodo che compie questo lavoro: dealloc<\/strong>, questo, per\u00f2, non dovr\u00e0 mai essere chiamato esplicitamente, ma dovr\u00e0 essere chiamato indirettamente dal metodo di protocollo release. Non preoccupatevi se non capite a fondo cosa sto dicendo, ora vedr\u00f2 di spiegarvi il meccanismo che sta dietro questa frase.<\/p>\n
Perch\u00e8 non possiamo invocare direttamente dealloc? Semplicemente perch\u00e8 deallocando l’oggetto sparirebbe dall’intero programma e potrebbe capitare che in realt\u00e0, questo, serva ancora da qualche parte. Infatti oltre a servire nel metodo in cui \u00e8 chiamato, un oggetto potrebbe essere passato come argomento ad altro oggetto e avere ancora uno scopo che necessiti la sua esistenza. Deallocandolo in un caso come questo il programma restituirebbe un errore o comunque si comporterebbe in modo anomalo e imprevisto. <\/p>\n
Da qui nasce l’esigenza avere un contatore che indichi al nostro programma se esiste ancora qualcuno interessato ad sfruttare il nostro oggetto. Questo contatore dovr\u00e0 avere valore 1 non appena l’oggetto verr\u00e0 allocato in memoria, dovr\u00e0 quindi essere incrementato di 1 ogni volta che un altro oggetto ha interesse a mantenerlo in memoria, e diminuito di 1 quando un oggetto decide che non gli serve pi\u00f9. <\/p>\n
Anche in questo caso non dovremmo inventarci nulla in quanto in nostro aiuto arriva il nostro caro NSObject, che offre ad ogni oggetto da esso ereditato una propriet\u00e0 chiamata retainCount<\/strong>. Quando retainCount varr\u00e0 0, dealloc<\/em> verr\u00e0 richiamato in automatico e la memoria sar\u00e0 liberata.<\/p>\n
Come detto allocando un oggetto in memoria verr\u00e0 impostato il suo retainCount<\/em> a 1, noi dovremo semplicemente dire al programma di sottrargli un 1 quando non ci servir\u00e0 pi\u00f9, per farlo useremo il metodo release<\/em>:<\/p>\n
\r\nMyClass *myNewClass = [[MyClass alloc] init];\r\n\r\n\/\/ Facciamo qualcosa con la nostra myNewClass\r\n\r\n[myNewClass release];\r\n<\/pre>\n
In particolare riportiamo i momenti in cui retainCount<\/em> pu\u00f2 variare (tratti dal nostro precedente articolo<\/a> su questo tema a cura di Ignazio Cal\u00f2):<\/p>\n