2012-01-05 28 views
7

He desarrollado una aplicación de iPhone que debería ser compatible con iOS4 y iOS5 basado en iPhone/iPad.ARC o no a ARC iphone iOS5

mi aplicación pierde memoria en pocos lugares, lo cual es cada vez más difícil de depurar debido al tamaño del código. Hace poco leí sobre ARC (automático de recuento de referencia), mi consulta es

  1. ¿Es necesario modificar el código fuente (retener/liberar/alloc/dealloc) para compilar con ARC. ¿Qué cambios necesitamos realizar con ARC?

  2. ¿es aconsejable cambiar a ARC?

  3. ¿Funcionará mi aplicación en el teléfono iOS4 si uso ARC

gracias.

+0

Sugiero que hacer de esta pregunta una entrada en la wiki ... definitivamente es una buena pregunta y definitivamente relacionada con la programación, pero la mayoría de la pregunta es realmente opinión y relacionada con circunstancias específicas. –

+1

Aquí haces tres preguntas diferentes. El segundo está cubierto por [iOS 5 Best Practice (Release/retain?)] (Http://stackoverflow.com/questions/6308425/ios-5-best-practice-release-retain), y el tercero por [if convert proyecto para conteo automático de referencias (ARC), ¿sigue siendo compatible con iOS 3.X, 4.X?] (http://stackoverflow.com/questions/6421753/if-convert-project-to-automatic-reference-countingarc -is-it-still-support-on) –

Respuesta

14

Probablemente este no sea el mejor lugar para publicar esta pregunta, pero responderé porque no me importa que la pregunta esté aquí.

http://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/_index.html

  1. que va a utilizar el 'Editar> Refactor> Convertir en Objective-C ARC' herramienta de migración y de la mano arreglar cualquier cosa que la herramienta no se puede averiguar.

  2. Sí.

  3. Sí pero cero las referencias débiles no lo harán.

+0

Otra consideración es que muchas bibliotecas de terceros aún no tienen buenas versiones de arco. Esto me impide actualizar algunos de mis proyectos existentes. –

+2

Puede excluir selectivamente cualquier archivo fuente de ARC cuando ejecuta la conversión. Simplemente desmarque cualquier archivo de clase de terceros en la etapa de verificación previa de la herramienta de conversión de ARC y los omitirá y los marcará con -fno-objc-arc, por lo que se excluirán de la validación de ARC. Esta es una de las mejores características de ARC: puede mezclar y combinar archivos ARC y no ARC en el mismo proyecto. –

4

definitivamente creo que es bueno para los programadores de entender la gestión de memoria y cómo el sistema funciona realmente ... pero, creo ARC es un sistema muy bueno y funciona muy bien. Esta es realmente una pregunta de opinión, por lo que mi opinión es que casi siempre vale la pena comenzar nuevos proyectos que se destinen a aplicaciones de iOS 5 en ARC, excepto en circunstancias muy específicas.

Creo que si usa muchas librerías C en su código, ARC es un poco más difícil de usar en este momento (por lo tanto, si usa mayormente bibliotecas C de terceros y cosas como CoreFoundation, podría considerar si tiene sentido o no), pero aun así, si estas bibliotecas están aisladas en su mayoría de los controladores Objective-C, ARC sigue siendo bueno.

Para aplicaciones antiguas, debe tener en cuenta el uso y los patrones de su aplicación. Si usa muchos métodos de delegado, dado que no puede usar referencias débiles en iOS 4, se vuelve un poco más complicado y probablemente tendrá que tener código mixto ARC y código no ARC. Podría ser mejor tomar una decisión de diseño para avanzar con ARC. Por lo tanto, las nuevas funciones están diseñadas para iOS 5 y quizás no estén disponibles (o totalmente disponibles) en la versión iOS 4 de la aplicación, y las que usan ARC.

Realmente, al final, dependerá de cómo su aplicación ya esté diseñada, de su tamaño y de su comodidad con la administración de memoria administrada y el uso/restricciones de ARC. Por ejemplo, tengo tres proyectos que nunca convertiría en ARC, uno que estoy haciendo mixto ahora mismo, uno que está completamente convertido (pero aún se dirige a iOS 4+) y 2 que son ARC completos e iOS 5+ solamente.

+0

OpenGL es técnicamente una API de C, aunque sin ningún tipo de retención directa de objetos, por lo tanto, no hay necesidad de 'puentes'; Todos los objetos son internos y opacos y se accede a ellos a través de funciones e ID enteros. Aún así, ¿hay algo que tenga en cuenta al usar OpenGL dentro del código ARC Obj-C? –

1

Para ser claros, mientras que no se puede utilizar ARC referencias débiles si se dirigen a iOS 4, que puede todavía utiliza unsafe_unretained, que es básicamente el equivalente de usar assign de propiedades del objeto. Eso significa que puede convertir cualquier código no ARC bien escrito a ARC sin creación accidental de ciclos de retención en iOS 4.

Al usar unsafe_unretained se pierde la función de anulación automática de las referencias débiles, pero aún así obtiene todos los demás beneficios de ARC, como no tener que preocuparse por olvidar lanzar ivars en sus declaraciones dealloc, etc.

Cuestiones relacionadas