{"id":7867,"date":"2011-10-20T11:35:54","date_gmt":"2011-10-20T09:35:54","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=7867"},"modified":"2011-10-20T11:35:54","modified_gmt":"2011-10-20T09:35:54","slug":"introduzione-ad-arc-automatic-reference-counting","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/introduzione-ad-arc-automatic-reference-counting\/","title":{"rendered":"Introduzione ad ARC (Automatic Reference Counting)"},"content":{"rendered":"

\"guide-objective-c\"<\/a> Il nuovo compilatore Apple LLVM 3.0, introdotto con Xcode 4.2, introduce una funzionalit\u00e0 chiamata Automatic Reference Counting (ARC) estremamente interessante per noi sviluppatori. Essa ci aiuta a gestire in modo corretto la memoria di un’applicazione, permettendoci di creare applicazioni migliori e pi\u00f9 robuste.<\/p>\n

Prima di ARC, dovevamo chiamare manualmente e nei posti giusti i metodi retain\/release\/autorelease per assicurarci che gli oggetti rimanessero “in vita” esattamente quanto ci serviva. Purtroppo, dimenticare o inserire nel posto errato anche solo una chiamata a questi metodi dava origine a sprechi di memoria (che tipicamente crescono man mano che si usa l’applicazione) o addirittura a crash, cosa assolutamente intollerabile per un’applicazione professionale.<\/p>\n

Grazie ad ARC, gran parte di questo lavoro viene ora fatto in automatico e in modo migliore di quanto potremmo fare noi stessi. Vediamo come e perch\u00e9.<\/p>\n

Introduzione<\/h4>\n

Innanzitutto occorre fare una precisazione: ARC non \u00e8 un garbage collector<\/strong>. Il garbage collector funziona a run-time, cio\u00e8 durante l’esecuzione del programma. ARC, al contrario, lavora a compile-time, cio\u00e8 durante la compilazione. La differenza \u00e8 fondamentale: vediamo perch\u00e9.<\/p>\n

Il garbage collector \u00e8 a tutti gli effetti un “processo” che analizza continuamente la memoria alla ricerca di zone che non vengono pi\u00f9 utilizzate e che dunque possono essere deallocate. Questo ha le seguenti implicazioni:<\/p>\n

    \n
  1. Il garbage collector consuma cicli di CPU.<\/li>\n
  2. L’istante in cui un oggetto verr\u00e0 rilasciato non \u00e8 predicibile.<\/li>\n<\/ol>\n

    ARC, invece, lavora a compile-time. In pratica, va lui stesso ad aggiungere al posto nostro le istruzioni necessarie per la gestione della memoria. D’altronde: chi meglio del compilatore sa dove devono essere inserite?<\/p>\n

    ARC, dunque, per certi versi \u00e8 meglio di un garbage collector, anche se vedremo che ha alcuni limiti (per i pi\u00f9 impazienti: non gestisce i retain cycle).<\/p>\n

    ARC \u00e8 disponile solo a partire da Xcode 4.2 e solo quando si usa il compilatore Apple LLVM 3.0. Inoltre, il deployment target deve essere impostato almeno a iOS 4 o a OS X 10.6, sebbene alcune funzionalit\u00e0 (le weak reference) siano supportate solo a partire da iOS 5 e OS X 10.7. ARC, inoltre, pu\u00f2 gestire solo oggetti e blocchi Objective-C, dunque se per qualche motivo ci trovassimo ad utilizzare le vecchie malloc dovremo continuare a liberarne la memoria manualmente.<\/p>\n

    In dettaglio<\/h4>\n

    Il compilatore, quando ARC \u00e8 abilitato, sintetizza in automatico le chiamate ai metodi retain\/release\/autorelease. Ad esempio questo codice:<\/p>\n

    \r\nFoo *foo = [[Foo alloc] init];\r\n\/\/ do something with foo\r\nreturn;\r\n<\/pre>\n
    viene automaticamente trasformato in:<\/p>\n
    \r\nFoo *foo = [[Foo alloc] init];\r\n\/\/ do something with foo\r\nobjc_release(foo); \/\/ funzionalmente equivalente alla vecchia [foo release];\r\nreturn;\r\n<\/pre>\n
    In pratica non dobbiamo pi\u00f9 ricordarci di mettere la release, perch\u00e9 ci pensa il compilatore. Non solo: abbiamo la garanzia che lui la metta nel punto giusto, ovvero quando la variabile non viene pi\u00f9 utilizzata, non un attimo prima e non un attimo dopo.<\/p>\n
    Un bel vantaggio: ARC riduce la possibilit\u00e0 che si verifichino quei nostri errori che si manifestavano in memory leak<\/strong> (zone di memoria occupate e mai pi\u00f9 rilasciate), dangling pointer<\/strong> (puntatori che si riferiscono ad aree di memoria non pi\u00f9 valide), double free<\/strong> (zone di memoria rilasciate pi\u00f9 volte) e addirittura crash dell’applicazione.<\/p>\n
    Una curiosit\u00e0. Perch\u00e9 il compilatore ha inserito una chiamata a funzione, objc_release(), al posto di una chiamata al metodo release? Semplicemente perch\u00e9, pur essendo funzionalmente equivalente, una chiamata a funzione viene eseguita pi\u00f9 rapidamente rispetto all’invio di un messaggio. Non solo: il compilatore la pu\u00f2 individuare con maggiore semplicit\u00e0 e fare delle ulteriori ottimizzazioni. In questo articolo non ci interessano i dettagli, per\u00f2 \u00e8 interessante osservare che il codice scritto con ARC tipicamente \u00e8 addirittura pi\u00f9 efficiente di quello che potremmo scrivere a mano.<\/p>\n
    Ma torniamo a noi. ARC permette di rimuovere molto codice che prima eravamo obbligati a scrivere. Ad esempio, nella maggior parte dei casi potremo evitare di scrivere i vecchi metodi dealloc, perch\u00e9 il compilatore \u00e8 in grado di sintetizzarli per noi. Addio dunque a queste vecchie istruzioni:<\/p>\n
    \r\n- (void)dealloc {\r\n    [foo release];\r\n    [bar release];\r\n    [baz release];\r\n    [qux release];\r\n\r\n    [super dealloc];\r\n}\r\n<\/pre>\n
    Non si tratta di un vantaggio da poco. Quante volte, ad esempio, ci \u00e8 capitato di dimenticare di rilasciare una variabile di istanza o di chiamare il metodo dealloc su super?<\/p>\n
    In sintesi, usando ARC abbiamo questi vantaggi:<\/p>\n
      \n
    1. Codice pi\u00f9 compatto e meno istruzioni da scrivere.<\/li>\n
    2. Codice pi\u00f9 veloce.<\/li>\n
    3. Codice con meno errori e dunque meno memory leak.<\/li>\n<\/ol>\n
      Prima di concludere il paragrafo, vogliamo evidenziare che con ARC non solo non serve pi\u00f9 chiamare i vecchi metodi retain, release, autorelease e retainCount, ma addirittura diventa vietato. Infatti, se provassimo ad inserirli ci compariranno degli errori di compilazione piuttosto espliciti, come ad esempio “ARC forbids explicit message send of ‘retain'”.<\/p>\n
      Introduzione ai nuovi tipi di ownership<\/h4>\n
      Prima di procedere dobbiamo fare una parentesi pi\u00f9 tecnica, fondamentale per capire il seguito dell’articolo e per padroneggiare davvero ARC.<\/p>\n
      ARC introduce questi nuovi “lifetime qualifier” per gli oggetti:<\/p>\n