No hay inconveniente. Úselo. Hazlo hoy. Es más rápido que tu código anterior. Es más seguro que tu código anterior. Es más fácil que tu código anterior. No es recolección de basura. No tiene overhead de tiempo de ejecución de GC. El compilador inserta retenciones y lanzamientos en todos los lugares que debería tener de todos modos. Pero es más inteligente que usted y puede optimizar los que no son realmente necesarios (al igual que puede desenrollar bucles, eliminar variables temporales, funciones en línea, etc.)
Bien, ahora le contaré sobre las pequeñas desventajas :
Si usted es un largo tiempo de ObjC desarrollador, se le contracción durante aproximadamente una semana cuando se ve el código de ARC. Lo superarás rápidamente.
Existen algunas (muy) pequeñas complicaciones en el código de Core Foundation. Hay un poco más de complicaciones al tratar cualquier cosa que trate un id como un void*. Cosas como C-arrays de id pueden tomar un poco más de pensar en hacer correctamente. El manejo elegante de ObjC va_args también puede causar problemas. La mayoría de las cosas que involucran matemáticas en un puntero ObjC son más complicadas. No deberías tener mucho de esto en ningún caso.
No puede poner id en struct. Esto es bastante raro, pero a veces se usa para empacar datos.
Si no siguió los nombres correctos de KVC y mezcló códigos ARC y no ARC, tendrá problemas de memoria. ARC utiliza la denominación de KVC para tomar decisiones sobre la gestión de la memoria. Si es todo el código ARC, entonces no importa porque lo hará de la misma manera "incorrecta" en ambos lados. Pero si está mezclado ARC/no ARC, entonces hay un desajuste.
ARC perderá memoria durante los lanzamientos de excepciones ObjC. Una excepción ObjC debe ser muy cercana a la finalización de su programa. Si está atrapando una cantidad significativa de excepciones ObjC, las está usando incorrectamente. Esto se puede reparar usando -fobjc-arc-exceptions, pero incurre en las penalizaciones que se describen a continuación:
ARC no perderá memoria durante la excepción ObjC o C++ arroja el código ObjC++, pero esto tiene un costo de tiempo y rendimiento espacial. Este es otro más en una larga lista de razones para minimizar el uso de ObjC++.
ARC no funcionará en absoluto en iPhoneOS 3 o Mac OS X 10.5 o versiones anteriores. (Esto me impide usar ARC en muchos proyectos.)
__weak los punteros no funcionan correctamente en iOS 4 o Mac OS X 10.6, lo cual es una lástima, pero bastante fácil de evitar. Los punteros __weak son geniales, pero no son el punto de venta # 1 de ARC.
Para el 95% + de código por ahí, ARC es brillante y no hay razón alguna para evitarlo (siempre que puede manejar las restricciones de la versión del sistema operativo). Para código que no sea ARC, puede pasar -fno-objc-arc archivo por archivo. Desafortunadamente, Xcode hace que esto sea mucho más difícil de lo que debería ser en la práctica. Probablemente deberías mover código que no sea ARC a un xcodeproj separado para simplificar esto.
En conclusión, cambie a ARC tan pronto como pueda y nunca mire hacia atrás.
EDITAR
que he visto un par de comentarios a lo largo de las líneas de "usando arco es ningún substituto para conocer las reglas de gestión de memoria de cacao." Esto es mayormente cierto, pero es importante entender por qué y por qué no. Primero, si todo su código usa ARC y usted viola el Three Magic Words en todas partes, no tendrá problemas. Escandaloso decirlo, pero ahí lo tienes. ARC podría retener algunas cosas que no quisiste retener, pero las liberará también, por lo que nunca importará. Si estuviera enseñando una nueva clase en Cocoa hoy, probablemente no dedicaría más de cinco minutos a las reglas de administración de memoria, y probablemente solo mencionaría las reglas de nombres de administración de memoria mientras hablaba de nombres de KVC. Con ARC, creo que en realidad podría convertirse en un programador principiante decente sin aprender las reglas de administración de memoria en absoluto.
Pero no podría convertirse en un programador intermedio decente. Necesita conocer las reglas para establecer un puente correcto con Core Foundation, y cada programador intermedio debe tratar con CF en algún momento. Y necesita conocer las reglas para el código mixto ARC/MRC. Y necesita conocer las reglas cuando comienza a jugar con los void* punteros al id (que sigue necesitando realizar KVO correctamente). Y bloques ... bueno, bloquear la administración de memoria es simplemente extraño.
Así que mi punto es que la administración de la memoria subyacente sigue siendo importante, pero cuando solía pasar un tiempo significativo estableciendo y replanteando las reglas para los nuevos programadores, con ARC se está convirtiendo en un tema más avanzado. Prefiero que los nuevos desarrolladores piensen en términos de gráficos de objetos en lugar de llenar sus cabezas con las llamadas subyacentes al objc_retain().
No hay recolección de basura en ipad/ios. ¿Estás hablando de OS X? – dasblinkenlight
Mis disculpas, estoy usando términos de Java fuera de lugar. Me refiero a que con ARC, los objetos pueden mantenerse en la memoria por más tiempo de lo necesario, y luego liberarse como grupo en un grupo de auto-lanzamiento algún tiempo después. Es este efecto de que se mantengan y liberen con otros objetos más adelante, de manera similar a la recolección de basura de Java a la que me refiero. –
@TenementFunster, para el mismo código (menos las llamadas para liberar), ARC mantendrá el objeto no más de largo que el código no ARC. De hecho, a menudo lo lanzará antes de lo que lo haría. Hay un pequeño número de cosas que son algo más lentas, pero aceleraron tanto los patrones comunes que empequeñecen el impacto en el rendimiento. Para muchos patrones comunes (que retienen un objeto que se devolvió con una liberación automática, por ejemplo), literalmente no se puede escribir a mano tan rápido como ARC lo hará automáticamente. –