Non c'è nessun aspetto negativo. Usalo. Fallo oggi. È più veloce del tuo vecchio codice. È più sicuro del tuo vecchio codice. È più facile del tuo vecchio codice. Non è una raccolta di rifiuti. Non ha sovraccarico di runtime di GC. Gli inserimenti del compilatore conservano e rilasciano in tutti i luoghi che dovresti avere comunque. Ma è più intelligente di te e può ottimizzare quelli che non sono realmente necessari (proprio come può srotolare loop, eliminare variabili temporanee, funzioni inline, ecc.)
OK, ora ti parlerò dei piccoli inconvenienti :
Se sei un lungo tempo objC sviluppatore, si contrazione per circa una settimana quando si vede il codice ARC. Lo supererai molto rapidamente.
Ci sono alcune (molto) piccole complicazioni nel collegarsi al codice della Fondazione Core. Ci sono leggermente più complicazioni nell'affrontare qualcosa che tratta uno id come void*. Cose come i C-array di id possono richiedere un po 'di più di pensare a fare correttamente. Anche la gestione elaborata di ObjC va_args può causare problemi. La maggior parte delle cose che riguardano la matematica su un puntatore ObjC è più complicata. Non dovresti avere molto di questo in ogni caso.
Non è possibile inserire id in un struct. Questo è abbastanza raro, ma a volte è usato per impacchettare i dati.
Se non è stata eseguita la corretta denominazione KVC e si intermex ARC e codice non ARC, si avranno problemi di memoria. ARC utilizza la denominazione KVC per prendere decisioni sulla gestione della memoria. Se è tutto il codice ARC, allora non importa perché lo farà lo stesso "sbagliato" su entrambi i lati. Ma se è misto ARC/non-ARC, allora c'è una discrepanza.
ARC perde memoria durante i lanci di eccezioni ObjC. Un'eccezione ObjC dovrebbe essere molto vicina alla conclusione del programma. Se stai rilevando un numero significativo di eccezioni ObjC, le stai utilizzando in modo errato. Questo è risolvibile mediante -fobjc-arc-exceptions, ma assume le sanzioni discussi di seguito:
ARC non perderà la memoria durante objC o C++ eccezione getta nel codice objC++, ma questo è a costo di tempo e spazio prestazioni. Questo è ancora un altro in un lungo elenco di motivi per ridurre al minimo l'utilizzo di ObjC++.
ARC non funziona affatto su iPhoneOS 3 o Mac OS X 10.5 o precedente. (Questo mi impedisce di usare ARC in molti progetti.)
__weak I puntatori non funzionano correttamente su iOS 4 o Mac OS X 10.6, il che è un peccato, ma è abbastanza facile da aggirare. I puntatori __weak sono ottimi, ma non sono il punto vendita di ARC.
Per il 95% + di codice là fuori, ARC è brillante e non c'è ragione al mondo per evitarlo (fornito è possibile gestire le restrizioni versione del sistema operativo). Per codice non ARC, è possibile passare -fno-objc-arc in base al file. Purtroppo Xcode rende molto più difficile di quanto dovrebbe essere nella pratica. Probabilmente dovresti spostare il codice non ARC in un xcodeproj separato per semplificarlo.
In conclusione, passare a ARC appena possibile e mai guardare indietro.
EDIT
Ho visto un paio di commenti sulla falsariga di "utilizzando ARC è alcun sostituto per conoscere le regole di gestione della memoria di cacao". Questo è principalmente vero, ma è importante capire perché e perché no. Innanzitutto, se tutto il tuo codice utilizza ARC e violerai lo Three Magic Words dappertutto, non avrai ancora problemi. Scioccante da dire, ma ci vai. ARC potrebbe conservare alcune cose che non intendevi mantenere, ma le rilascerà, quindi non avrà mai importanza. Se oggi stavo insegnando una nuova classe in Cocoa, probabilmente non impiegherò più di cinque minuti sulle reali regole di gestione della memoria e probabilmente menzionerei solo le regole di denominazione della gestione della memoria mentre discuto della denominazione KVC. Con ARC, credo che potresti davvero diventare un programmatore principiante decente senza imparare le regole di gestione della memoria.
Ma non è possibile diventare un programmatore intermedio decente. È necessario conoscere le regole per il corretto collegamento con Core Foundation e ogni programmatore intermedio ha bisogno di trattare con CF a un certo punto. E devi conoscere le regole per il codice misto ARC/MRC. E devi conoscere le regole quando inizi a fare scherzi con i puntatori void* su id (che continui a dover eseguire correttamente KVO). E blocchi ... beh, bloccare la gestione della memoria è solo strano.
Quindi il mio punto è che la gestione della memoria sottostante è ancora importante, ma dove passavo molto tempo a dichiarare e rideterminare le regole per i nuovi programmatori, con ARC sta diventando un argomento più avanzato. Preferirei che i nuovi sviluppatori pensassero in termini di oggetti grafici piuttosto che riempire la testa con le chiamate sottostanti a objc_retain().
fonte
2012-01-06 16:13:45
Non esiste garbage collection su ipad/ios. Stai parlando di OS X? – dasblinkenlight
Le mie scuse, sto usando termini Java out-of-place. Intendo dire che con ARC, gli oggetti possono essere tenuti in memoria più a lungo del necessario, quindi rilasciati come gruppo in un pool di auto-rilascio qualche tempo dopo. È questo effetto di essere mantenuti e rilasciati successivamente con altri oggetti, in modo simile alla raccolta dei rifiuti di Java a cui mi riferisco. –
@TenementFunster, per lo stesso codice (meno le chiamate a rilasciare), ARC terrà l'oggetto non più lungo del codice non ARC. Infatti, spesso lo rilascerà prima di quanto non avresti. Ci sono un piccolo numero di cose che sono un po 'più lente, ma hanno accelerato gli schemi comuni così tanto da minare l'impatto sulle prestazioni. Per molti modelli comuni (conservando un oggetto che è stato restituito con un'autelease, ad esempio), letteralmente non è possibile scriverlo a mano tanto velocemente quanto ARC lo farà automaticamente. –