¿Debo usar la recolección de basura Objective-C cuando escribo para 10.5+?

Question

Al escribir un código Mac bastante típico en un entorno OS X 10.5+, ¿cuáles son las desventajas de usar la recolección de basura?

Hasta ahora todo lo demás que he escrito ha sido compatible con 10.4 o en el iPhone, así que me he vuelto bastante cómodo con retener/liberar, pero ahora que estoy trabajando en un proyecto más grande que es 10.5 solo ' Me pregunto si hay algún inconveniente al seguir adelante y utilizar el recolector de basura Objective-C 2.0.

¿Qué piensan?

Answer 1

Si está escribiendo un código Cocoa nuevo y está dirigido a Mac OS X 10.5, use la recolección de basura Objective-C.

Si va a escribir algo de código que también puede que tenga que ejecutar en el iPhone, puede escribir y la prueba que codifican para los dos modelos muy fácilmente manteniendo ese código en un marco separado, escrito con propiedad -retain y -release use y establezca su marco de trabajo y su objetivo de prueba unitario para compatible con GC en lugar de GC-only.

Xcode ejecutará su paquete de prueba unitaria dos veces, una con GC activado y otra con GC apagado, y su marco de trabajo se podrá utilizar en ambos modelos de ejecución. Entonces, si finalmente desea llevar ese código de nivel de modelo al iPhone, puede colocarlo en una biblioteca estática dirigida a iPhone o incluirlo directamente en su proyecto de iPhone.

Independientemente de si está considerando ejecutar su código en el iPhone, definitivamente debe apuntar a la recolección de basura si su aplicación requerirá Leopard. Facilitará el desarrollo y el recolector de basura Objective-C funciona bastante bien.

Answer 2

Si existe la posibilidad de portar su aplicación al iPhone, no debe usarla.

La recolección de basura puede tener efecto adverso en el rendimiento si tiene casos de uso especiales. Sin GC, tiene un control preciso sobre la destrucción del objeto, que no es el caso del mundo GC. En la mayoría de los proyectos, vale la pena activar GC ya que es menos propenso a errores y más fácil. teoría, la gestión de memoria sin GC siempre puede ser más rápida que con GC, sin embargo, no es el caso en la mayoría de las aplicaciones prácticas (ya que GC es generalmente más optimizado que el ser humano).

Answer 3

Prefiero manejar la gestión de memoria, simplemente porque me gusta tener ese nivel de control. Sé por experiencia en otros idiomas (C#) que GC no le permite ignorar por completo los problemas de memoria, y eso es lo mismo en Cocoa con cosas como referencias débiles y devoluciones de llamadas que usan (void *) donde el objeto no es explícitamente propiedad por otro objeto. Básicamente estás intercambiando un conjunto de desafíos (pérdidas de memoria) por otro. Personalmente, actualmente no tiendo a cometer demasiados errores de administración de memoria, y los que hago son bastante fáciles de rastrear.

Existen algunas situaciones (como la implementación de métodos de origen de datos para un NSOutlineView, donde no desea retener el objeto que se proporciona en la vista de esquema) donde he pensado que GC sería realmente útil, pero me ha Ya ha hecho pruebas reales con eso.

Apple enumera algunas otras ventajas y desventajas en el GC programming guide.

Answer 4

GC está en desuso, comenzando con 10.8. En realidad, nunca fue una buena idea adoptar esta tecnología, dejando de lado las porristas, porque nunca se cumplieron los objetivos de rendimiento y estabilidad.

Administrar la memoria "manualmente" es realmente muy simple, ya que el código de administración se puede descartar en gran medida. Mi código base tiene < 1% de código relacionado con la administración de memoria, y eso es más grande de lo que necesita ser. Así que también soy escéptico acerca de ARC, simplemente porque el problema que está resolviendo es tan pequeño que incluso los pequeños problemas con la tecnología hacen que no valga la pena.