Aprenda & desarrollo de Juego de Maestro Cocos2D

Sin duda tengo que contando de referencia automático (ARCO) es el siguiente salto grande adelante para el Objetivo-C desde la introducción del Objetivo-C 2.0. El ARCO permite que usted ponga la carga de la dirección de memoria de (Apple LLVM 3.0) el compilador, y nunca pensar en retiene, suelta y autosuelta alguna vez otra vez.

Ya que las primeras experiencias de mucho usuario con el ARCO tratarán de convertir una existencia app, ellos aprenderán el modo difícil que la conversión del código existente para FORMAR UN ARCO no es un fuego & olvide la operación. Y ya que esto es Internet, también hay muchas asunciones, declaraciones falsas y otros mitos que giran alrededor del ARCO andar.

Así aquí está aproximadamente todo que usted tiene que saber sobre el ARCO, y algún ARCO-MYTHBUSTING también.

• Requisitos de desarrollo para ARCO apps
• Objetivos de Despliegue mínimos para ARCO apps
• Objetivos de Despliegue requeridos con referencias débiles zeroing
• Como permitir el ARCO en su proyecto
• Compile errores después de cambiar a LLVM 3.0
• La adquisición de bibliotecas de tercero construir con ARCO
• La conversión de una existencia app para FORMAR UN ARCO
• “No puede Convertirse al ARCO Objetivo-C”
• La fijación de la aguja escribe a máquina en C structs
• Fijando C/C ++ la aguja se traslada con moldes tendidos un puente
• La fijación de NSAutoreleasePool con @autoreleasepool
• Métodos usted no puede llamar (o anular) más
• Usted todavía puede anular - (vacío) dealloc {}
• Restricción de nombramiento de propiedad
• Nuevas palabras clave de Propiedad: fuerte y débil
• EL ARCO prohíbe sintetizar una propiedad sólo para leer sin el calificador de propiedad
• Para expertos: el descubrimiento en el tiempo de compilación si el ARCO es permitido
• Para expertos: permita el uso de palabras clave de ARCO con el minusválido de ARCO
• Mito: el ARCO no ha sido probado confiable
• Mito: ARCO se lleva control de dirección de Memoria
• Documentación de Referencia de ARCO

• Xcode 4.2
• El compilador de Apple LLVM 3.0 (Construyen el Ajuste)
• iOS app desarrollo: Leopardo de Nieve 10.6 y más nuevo
• Desarrollo de Mac app: León 10.7 y más nuevo

¡No hay ningún desarrollo de ARCO para Mac apps bajo el Leopardo de Nieve! Y Xcode 4.1 y antes no viene atado en un fardo al compilador de Apple LLVM 3.0 (Sonido metálico) que es la primera versión de compilador de Sonido metálico para apoyar el ARCO.

• dispositivos de iOS: iOS 4.0 o más nuevo
• Ordenador de Mac: Mac con procesador de 64 bites que dirige Leopardo de Nieve 10.6 o más nuevo.

Los Mac OS X apps con el ARCO permitido son apps siempre de 64 bites. Usted no puede construir el ARCO de 32 bites apps.

Macs con al menos una 2 CPU de Dúo Principal será capaz de dirigir apps de 64 bites. Macs con el Dúo Principal de 32 bites o Solo Principal (Yonah) CPUs no puede dirigir el ARCO apps. Macs de 32 bites han sido discontinuados cerca del final de 2006, a excepción del Dúo Principal Mac mini que fue discontinuado en el agosto de 2007. The 32-Bit Macs have been discontinued near the end of 2006, with the exception of the Core Duo Mac mini which was discontinued in August 2007.

• dispositivos de iOS: iOS 5.0 o más nuevo
• Ordenador de Mac: León 10.7 o más nuevo.

Usted no puede usar "por casualidad" referencias débiles zeroing sin notarlo. Usted tendrá que usar o la palabra clave @property débil o el __ palabra clave débil declarando una variable. Si usted usa una de estas palabras clave, el compilador generará un error si usted no ha fijado aún el objetivo de despliegue en consecuencia a iOS 5.0 o a Mac OS X 10.7. If you use one of these keywords, the compiler will generate an error if you haven’t yet set the deployment target accordingly to either iOS 5.0 or Mac OS X 10.7.

Todos Macs capaz del León que corre 10.7 pueden dirigir el ARCO de 64 bites apps. El león es primer 64-Bit-only Mac OS X sistema operativo.

Usted tendrá que asegurarse que el Ajuste Construir para el Compilador para C/C ++/Objective-C es puesto al compilador de Apple LLVM 3.0.

Esto es particularmente importante para proyectos existentes que todavía pueden ser hechos usar LLVM GCC 4.2 u otro compilador. Si usted no selecciona el LLVM 3.0 compilador, ninguno del ARCO estuvo relacionado los ajustes se revelarán en la lista de Ajustes Construir.

Con LLVM 3.0 seleccionado como el compilador el Objetivo-C de Ajuste Construir la Referencia Automática contar puede ser puesta a SÍ. Si usted crea un nuevo proyecto de una plantilla de Xcode usted también tendrá la opción de permitir el ARCO en el nuevo mago de proyecto seleccionando el Uso Referencia Automática contar.

Si usted antes usara un compilador diferente, es absolutamente posible que LLVM 3.0 genere nuevas advertencias y errores donde no había ninguno antes, hasta con el minusválido de ARCO. Esto es el LLVM 3.0 compilador que se hizo un poco mejor en el descubrimiento del código potencialmente peligroso.

Recomiendo por construir primero su app con LLVM que 3.0 compilador y ARCO incapacitaban, para asegurarse todo LLVM 3.0 cuestiones relacionadas han sido fijadas antes de intentar convertir su código para FORMAR UN ARCO.

Por ejemplo, LLVM 3.0 es capaz ahora de descubrir alguna “serie potencial de límites” cuestiones gracias al proyecto de SAFECode, y esto más se queja un poco cuando esto viene al reparto de un tipo al otro, en particular relacionado con cuerdas de formato. La mayor parte de estas cuestiones son fáciles a resolverse. De hecho, LLVM 3.0 le ayuda a determinar donde la cuestión es por el diagnóstico expresivo, pero lamentablemente Xcode esconde esto bastante bien del usuario. In fact, LLVM 3.0 helps you determine where the issue is through expressive diagnostics, but unfortunately Xcode hides that pretty well from the user.

Para ver el diagnóstico expresivo en Xcode, vaya al Navegante de Tronco (Command+7) y seleccione el tronco más reciente con la advertencia o error en ella:

Entonces haga clic en el botón de detalles a la derecha del símbolo de advertencia/error (sólo encima de "más" relación) para ver el LLVM 3.0 declaración de diagnóstico expresiva, señalando exactamente al carácter o variedad de caracteres que causan la cuestión:

La primera cosa de hacer con bibliotecas de tercero incompatibles es construirlos como una biblioteca estática separada. Tome por ejemplo Cocos2D cuya plantilla de proyecto de Xcode simplemente pone todo el código de Cocos2D en el objetivo de su proyecto. Sería una pesadilla para intentar y actualizar el código de biblioteca Cocos2D entero para apoyar el ARCO. Mientras usted puede incapacitar el ARCO para archivos de código fuente individuales con la bandera de compilador-fno-objc-arc, sería aburrido para hacer así para más que sólo unos archivos. It would be a nightmare to try and update the entire Cocos2D library code to support ARC. While you can disable ARC for individual source code files with the -fno-objc-arc compiler flag, it would be tedious to do so for more than just a few files.

Una vez que usted construye el código fuente Cocos2D por separado como una biblioteca estática, los cambios requeridos son limitados con tres sitios: CCDirector (quitan NSAutoreleasePool), CCActionManager (añaden __ unsafe_unretained) y CCArray (añaden __ unsafe_unretained, nuevo factor inline código en el archivo de realización). Tim Games diminuto ha perfilado estos cambios y proporciona un tenedor de cocos2d-I-Phone que es compatible con el ARCO – de ser construido como una biblioteca estática.Tiny Tim Games have outlined these changes and provide a fork of cocos2d-iphone that is compatible with ARC – if built as a static library.

A propósito, Kobold2D es totalmente compatible con el ARCO. ¡De hecho esto tiene el ARCO permitido en ausencia en todos los proyectos reteniendo lleno hacia atrás compatibilidad si usted no quiere usar el ARCO!

Si la construcción de una biblioteca estática todavía causa demasiadas cuestiones con aquella biblioteca, luego vaya al foro de aquella biblioteca, busque puestos relacionados del ARCO y/o apoyo de ARCO de solicitud. Muchas bibliotecas de la fuente abiertas no compilan hasta limpiamente con LLVM 3.0 aún, sin mencionar el ARCO de apoyo. Esto tiene que cambiar rápidamente porque el apoyo de revelador de biblioteca directamente influye en el precio de adopción del ARCO. This needs to change quickly because library developer support directly influences the adoption rate of ARC.

¡Hay un app para esto!

Bien, para ser precisa hay una opción de menú en Xcode 4.2 para esto. Usted lo encontrará si usted abre su proyecto en Xcode y elige Corrigen-> Nuevo factor-> Converso al ARCO Objetivo-C ….

Le presentarán una lista de objetivos que usted quiere convertir. Asegúrese que usted no selecciona ninguna biblioteca estática que usted no haya escrito usted mismo. Las bibliotecas estáticas pueden ser unidas a app permitido por el arco sin necesidad tener realmente de ser el ARCO compatible. Aunque usted debiera hacer algunos cambios en los archivos de jefe de la biblioteca. Más en esto más tarde. Static libraries can be linked to an ARC-enabled app without actually having to be ARC compatible. Although you may have to make some changes to the library’s header files. More on that later.

¡Ah querido!

En algunos casos la conversión automática no es tan automática como usted esperaría que fuera. En muchos casos esto es debido a bibliotecas estáticas incompatibles.

En mayoría de los casos los problemas están relacionados únicamente con id u otros tipos de aguja almacenados en un C struct, pasando agujas de y de C/C ++ código o el uso de la clase de NSAutoreleasePool que no está disponible construyendo un app con el ARCO permitido. Lea en para soluciones de las cuestiones más comunes.

EL ARCO se quejará de un C struct que almacena tipos de aguja:

Esto es bastante fácil a fijar por el prependiente los tipos de aguja con el __ unsafe_unretained palabra clave:

Esto dice a ARCO que la memoria para estos que la aguja escribe a máquina es manejada a mano, es decir el camino viejo y escolar. De aquí en adelante el tipo de aguja es "no retenido" por el ARCO, y es "inseguro" porque la memoria puede ser desasignada pero la aguja no es puesta a la nada automáticamente, que puede crear posiblemente una aguja pendiente. Esto es el modo que ha sido todo el tiempo, el ARCO sólo quiere que usted confiese expresamente que hace algo que se considera inseguro. That’s the way it has been all the time, ARC just wants you to expressly admit that you’re doing something that is considered unsafe.

Si su código trabajara fino antes, __ el unsafe_unretained se asegurará simplemente que compila bajo el ARCO. Pero para el nuevo código usted debería evitar necesidad tener de usar aquella palabra clave. Una opción es cambiar todo C structs en clases Objetivas-C ligeras con propiedades. One option is to change all C structs into lightweight Objective-C classes with properties.

En casos donde usted pasa id o agujas de objeto de y de C/C ++ código, el compilador se quejará de la conversión y sugerirá un molde tendido un puente:

Otra vez esto es fácil a fijar echando correctamente el tipo de aguja y prependiente esto con el __ palabra clave de puente:

El __ la palabra clave de puente simplemente significa que la aguja es transferida de o a la tierra Objetiva-C sin alterar. El ARCO retendrá ni, ni soltará aquella aguja.

Las palabras clave especiales __ bridge_transfer y __ bridge_retain sólo deberían ser usadas tratando con objetos de Fundación Principales tendidos un puente exentos de peaje donde usted tendría que llamar normalmente CFRetain y/o CFRelease para manejar la vida del objeto de Fundación Principal.

EL ARCO sustituyó la clase de NSAutoreleasePool por la directiva de compilador @autoreleasepool.

Usted debe sustituir la utilización de código NSAutoreleasePool:

Con la palabra clave @autoreleasepool:

Usted tendrá que quitar todas las llamadas a estos métodos sin la substitución:

• retener
• retainCount
• liberación
• autoliberación
• dealloc

Usted también no puede usar la palabra clave retener con propiedades más. En cambio, use la palabra clave fuerte.

Usted ya no puede anular estos métodos en su clase:

• retener
• retainCount
• liberación
• autoliberación

Usted no puede llamar dealloc pero usted todavía puede anular el - (vacío) dealloc {} método. Esto es útil para soltar la memoria de C/C ++ objetos. Por ejemplo usted todavía tiene que ser capaz de liberar la memoria de un caso mundial Box2D. De manera similar hay casos donde usted tiene que quitar mí como el delegado de otra clase cuando el mí la clase es desasignada. For example you still need to be able to free the memory of a Box2D world instance. Similarly there are instances where you need to remove self as the delegate of another class when the self class is deallocated.

Hay un hábito particular que usted tiene que dejar van de. Ya que usted no puede llamar dealloc, usted también no debe llamar [dealloc súper]. El compilador generará el [dealloc súper] llamada entre bastidores automáticamente. The compiler will generate the [super dealloc] call behind the scenes automatically.

Usted no puede crear una propiedad cuyo nombre comienza con "el nuevo". Esto es todo.

La palabra clave @property fuerte es sinónima para retener:

Mientras que débil es similar para adjudicar, salvo que una propiedad débil será puesta a la nada automáticamente cuando el objeto es desasignado (de ahí: zeroing referencia débil):

Zeroing referencias débiles sólo están disponibles apuntando iOS 5.0 y más nuevo, o Mac OS X León 10.7 y más nuevo.

Normalmente, cuando usted declara una propiedad sólo para leer, no importa lo que el tipo de almacenaje es (retenga, adjudique, copia) ya que las propiedades sólo para leer no pueden ser adjudicadas a. Tome éste por ejemplo:

Ahora con el ARCO, si usted no declara el ivar a mano (@synthesize puede generar ivars) usted encontrará un error extraño en la línea @synthesize, declarando:

error: el ARCO prohíbe sintetizar una propiedad de un objeto Objetivo-C con propiedad no especificada o atributo de almacenaje [4]

Tan raro como puede parecer, en este caso usted tendrá que especificar la palabra clave de almacenaje en una propiedad sólo para leer, añadiendo fuerte o débil:

Esto especifica al calificador de propiedad del ivar por la declaración @property. La alternativa debería declarar el ivar a mano, que forzará la propiedad de usar al mismo calificador de propiedad como el ivar.

Si usted tiene que averiguar si su código es construido con o sin el ARCO, por ejemplo si usted es el revelador de una biblioteca pública, usted puede usar los macros siguientes para determinar si el ARCO es permitido en el tiempo de compilación.

Como un autor de biblioteca, una de las cosas peores usted podría hacer para asegurar que la compatibilidad con versiones anteriores de su biblioteca es a #ifdef cada palabra clave específica para el ARCO y escriba cada tal línea dos veces: una vez sin la palabra clave de ARCO, una vez con la palabra clave de ARCO.

En cambio propongo de definir simplemente las palabras clave de ARCO como “noop” declaraciones cuando el ARCO es no disponible. Así su código usando palabras clave de ARCO todavía compilará bajo Xcode 4.1 o LLVM GCC4.2, y usted no necesita a #ifdef nada relacionado con aquellas palabras clave.

Ahora está seguro escribir el código como esto sin tener en cuenta si el ARCO está disponible o no, porque los compiladores que no apoyan el ARCO sólo verán al cliente habitual (vacío *) molde:

Como si la dirección de memoria automática tiene alguna propiedad mágica que de vez en cuando va loca.

EL ARCO todavía sigue mismo alloc, retenga, suelte el ciclo del código Objetivo-C. No hay ningunas ambigüedades y ningunos casos especiales cuando esto viene a la aplicación de pocos y reglas de alloc-retain-release simples. Esto es completamente determinista y el compilador puede hacer aquel trabajo menos mal, no, mejor que usted. No hay nada intrínsecamente y potencialmente no fiable sobre el ARCO. This is entirely deterministic and the compiler can do that job just as well, no, better than you. There’s nothing inherently and potentially unreliable about ARC.

Si usted ha oído sobre cuestiones con el ARCO, entonces ellos están probablemente relacionados con situaciones donde un ARCO app conecta con la Fundación Principal u otro C/C ++ código. En aquellas situaciones usted tendrá que aplicar correctamente varias nuevas palabras clave (moldes de puente en su mayor parte). Haga un error allí y usted se puso un problema. Pero esto no es la falta de ARCO. El mismo va para retienen ciclos, que todavía son una posibilidad en el ARCO apps. Make a mistake there and you got yourself a problem. But that’s not the fault of ARC. The same goes for retain cycles, which are still a possibility in ARC apps.

También aposté mi vida que la Manzana no anunciaría, promovería y pondría en práctica el ARCO para iOS y Mac OS X apps si no hubiera sido probado estable. Si esto no le convence, entonces tal vez esta cotización del revelador de ARCO CHRIS LATTNER hace:

EL ARCO es con cuidado construido para ser un modelo de programación confiable que se equivoca en el lado de producir un error de compilador en vez de producir silenciosamente un problema de memoria de tiempo de ejecución.

Esto también explica un poco por qué usted verá que más (inicial) compilan errores con el ARCO permitido.

Unos sostienen que el ARCO se lleva su control de la dirección de memoria. Esto por su parte llevaría menos que el rendimiento de tiempo de ejecución óptimo. De aquí en adelante el ARCO es malo y debería ser evitado. Henceforth ARC is bad and should be avoided.

Usted podría aplicar el mismo argumento inútil a la dirección asistida. Hay algunos intransigentes que no prefieren tener la dirección asistida, sólo debido a algún sentimiento subjetivo sobre el control que pierde. ¡No haga caso de esta gente! No porque ellos son incorrectos, ellos son correctos en algunas circunstancias – es sólo que aquellas circunstancias son raras, muy especializadas y requieren un alto nivel de la habilidad que el 99 % restante de usuarios simplemente no tiene, ni querría entrenarse. Ignore these people! Not because they’re wrong, they are correct in some circumstances – it’s just that those circumstances are rare, very specialized and require a high level of skill that the remaining 99% of users simply don’t have, nor would want to exercise.

Y aun si usted realmente tiene las habilidades, usted todavía es sujeto a errores del juicio u otros errores humanos. Entonces hasta los expertos se beneficiarán de usar el ARCO (o dirección asistida en realidad) en situaciones diarias.

No parece que algunas personas que sostienen que el ARCO se lleva el control entienden lo que el ARCO hace. La dirección de memoria es sobre la vida de objetos, si la dirección de memoria es automatizada con ARCO o manual. Si la vida de un objeto es en todas partes de la escena entera (visión, nivel, app, etc.) entonces que el objeto es asignado una vez cuando la escena es inicializada, y desasignada cuando la escena es desasignada. Si usted hace esto a mano, o automáticamente, causa el mismo comportamiento de la aplicación. If an object’s lifetime is throughout the entire scene (view, level, app, etc) then that object is allocated once when the scene is initialized, and deallocated when the scene is deallocated. Whether you do this manually, or automatically, results in the same behavior of the application.

Cada uno tiene que entender que el ARCO es determinista. ¡ ¡No debe ser confundido para la colección de basura! Los ciclos de colección de basura pueden dar puntapiés en en cualquier momento arbitrario a tiempo cuando el basurero encuentra necesario liberar un poco de memoria. En el ambiente coleccionado de una basura, como el C #, usted realmente pierde un poco de control de la dirección de memoria y en algunas situaciones esto lleva al rendimiento de tiempo de ejecución inestable. Pero no con ARCO. Garbage collection cycles can kick in at any random moment in time when the garbage collector finds it necessary to free up some memory. In a garbage collected environment, such as C#, you do lose some control over memory management and in some situations this leads to unsteady runtime performance. But not with ARC.

Decir que el ARCO quita el control de la dirección de memoria es el mal sólo claro y probablemente basado poniendo por caso que el ARCO sea igual a la colección de basura. Esto también puede provenir de “positives falso” que el Sonido metálico que el Analizador Estático produce, que puede haber infundido la duda sobre tecnologías de Sonido metálico "automatizadas" en general, aunque el análisis estático y el ARCO sean piezas completamente separadas de la tecnología.

El camino, en algunos casos usted tendría que ejercer el control de la dirección de memoria y con el ARCO usted todavía puede hacer esto, por lo general con las nuevas palabras clave de ARCO fuertes y débiles, así como tender un puente sobre moldes para agujas que cruzan límites de o a C/C ++ tierra. Mientras usted es consciente de la vida de sus objetos usted no tendrá ningún problema influyendo como la vida de objetos es manejada por el ARCO.

EL ARCO siempre asigna y suelta la memoria de un objeto al mismo punto a tiempo en la misma situación (determinista). Así el Objetivo-C con el ARCO no puede ser comparado con las lenguas coleccionadas de la basura como C #. si usted ve a alguien comparar el ARCO con C #, por favor envíeles esta relación.

Adelante leyendo para aquellos que quieren aprender más sobre el ARCO detalladamente.

• Sonido metálico: documentación de contando de Referencia Automática
• Manzana: Transitioning para FORMAR UN ARCO Notas de Liberación
• Manzana: Xcode Nueva Guía del usuario de Rasgos: Referencia Automática contar
Automatic Reference Counting
• Mike Ash: el viernes Q&A sobre Referencia Automática contar
• StackOverflow: ¿Cómo hace el trabajo de contando de referencia automático?
• StackOverflow: ¿Cuáles son las ventajas y desventajas de usar el ARCO?
• StackOverflow: ¿Cuál es la diferencia entre referencia automática contar y colección de basura?
• informIT: Objetivo-C de incluyendo de Referencia Automático, la Parte 1
• informIT: Objetivo-C de incluyendo de Referencia Automático, la Parte 2 Los Detalles
• Mike Ash: Zeroing referencias débiles sin ARCO
• Github: Apoyo a referencias débiles zeroing en iOS 4 / OS X 10.6

¡Por favor avíseme si yo olvidara de añadir algo sobre el ARCO! Sobre todo si usted cree que debería ser knowlARCdge común. ¡Y no olvide de piar de nuevo este artículo si le gusta esto, gracias! And don’t forget to retweet this article if you like it, thanks!