objective-c - tesis - soluciones para disminuir la basura
¿Debo usar la recolección de basura Objective-C cuando escribo para 10.5+? (4)
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 son algunas desventajas de seguir adelante y usar el recolector de basura Objective-C 2.0.
¿Qué piensan ustedes?
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 usando (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.
Hay algunas situaciones (como la implementación de métodos de fuente de datos para un NSOutlineView, donde no desea retener el objeto que se proporciona a la vista de esquema) donde he pensado que GC sería realmente útil, pero no he hecho ninguna pruebas reales con eso todavía.
Apple enumera algunas otras ventajas y desventajas en la guía de programación de GC .
Si existe la posibilidad de portar su aplicación al iPhone, no debe usarla.
La recolección de basura puede tener un 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 porque es menos propenso a errores y más fácil.
En 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 generalmente está más optimizado que el ser humano).
Si está escribiendo un nuevo código Cocoa y apuntando a Mac OS X 10.5, use la recolección de basura Objective-C.
Si está escribiendo algún código que también puede necesitar ejecutarse en el iPhone, puede escribir y probar ese código para ambos modelos muy fácilmente manteniendo ese código en un marco separado, escribiéndolo con propiedad -retain y -retain y establecer tanto su marco como su objetivo de prueba de la unidad lo soportan con GC en lugar de solo GC .
Xcode ejecutará su paquete de prueba unitaria dos veces, una con GC activado y otra con GC desactivado, y su marco de trabajo será utilizable 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.
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 en realidad muy simple, porque el código de administración se puede descartar en gran medida. Mi base de código 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.