12

Soy un nuevo desarrollador de cacao que proviene de un fondo C#/Java. Me presentaron los patrones de administración de memoria que utiliza el lenguaje Object-c y los encuentro muy útiles para el desarrollo consciente del código.Objective-C ARC vs. MRR: ¿por qué el interruptor?

¿Por qué ahora Apple quiere que usemos ARC (recuento automático de referencias) en lugar de MRR (retención manual) y qué ventajas aparte del ahorro de tiempo ofrece ARC?

Veo una transición que afecta negativamente a los hábitos de buenos ciudadanos que los desarrolladores obtienen del ecosistema obj-c.

Nick

+1

Gracias @pst por la edición. Esa fue mi primera publicación y olvidé explicar más las nuevas siglas. –

Respuesta

12

Es desafortunado que hacer que sea más fácil para los desarrolladores competentes tener la correcta tiene un efecto secundario de hacer que sea más fácil para los nuevos desarrolladores que no aprenden, pero parece que es probable que vale la pena.

ARC es menos tolerante que un colector de rastreo como C# o el uso de Java. Si no tiene un modelo claro de propiedad de objetos, casi seguramente creará ciclos y perderá toneladas de memoria. Mi esperanza sería que esto se haga lo suficientemente obvio (a través de los instrumentos? Eso todavía requiere buscarlo ... no estoy seguro de lo que se puede hacer aquí) que los nuevos desarrolladores aprenderán rápidamente a mantener su gráfico de objetos claro y acíclico.

+3

Gracias @Catfish_Man, prefiero que ARC sea más como un sistema de advertencia de compilador compatible con el analizador estático. –

+0

@ NicholasE.Credli: Es estrictamente intencional: la mayoría de las reglas de ARC se basan en el principio de que el compilador debe estar correcto el 100% del tiempo, de modo que cuando arroje un caso ambiguo, no adivine qué significa, pero simplemente lanzar un error. La solución es simplemente hacer que su código sea inequívoco. –

9

ARC me permite concentrarme en la escritura de código útil en lugar de los métodos de etiquetado dealloc.

mayoría de las personas que conozco han utilizado autorelease detrás de cada alloc de todos modos, ya que le salvó un release tarde y no se puede olvidar que en realidad lo puso. Así que el objeto estaba disponible hasta que se drenó el grupo de autorrelease, y con ARC el objeto se desasigna cuando ya no es necesario. Creo que en esos casos, el programa compilado por ARC incluso usará menos memoria.

Y, lástima de mí, me ayuda a hacer que mis aplicaciones se bloqueen con menos frecuencia también.
Ese lanzamiento prematuro que ocurre cada 10.000 lanzamientos. El que nunca podría rastrear por completo, con suerte con ARC esto es una cosa del pasado.


veo una transición tan buenos hábitos afectar negativamente en los ciudadanos que los desarrolladores ganar con el obj-c ecosistema.

probablemente de la misma manera que un desarrollador integrado que comenzó con el ensamblador cree que las personas que comienzan con C y nunca han utilizado el ensamblador adquieren malos hábitos.

En mi opinión, la discusión MRR vs ARC es similar.
ARC y C permiten escribir código más fácil de mantener en menos tiempo. Y ambos pueden llevar a una memoria y una huella de CPU más grandes.
Si mal no recuerdo, Apple anunció que agregaron un poco de velocidad hasta retain y release para compensar ese impacto en el uso de la CPU. Y debido a eso, no hay una razón real por la cual MMR todavía esté presente.

Yo, por mi parte, damos la bienvenida a nuestros nuevos señores de ARC.

2

realmente he disfrutado mudarme a ARC, es una cosa menos en la que pensar.Además de eso, creo que los recién llegados a menudo tropezarían con la importancia de las convenciones de nomenclatura (+ alloc, -copy, etc. vs [NSString stringWith ....]). el único inconveniente es cuando empiezas a tratar con CoreFoundation, etc. (las API C), donde todavía tienes que tener en cuenta quién posee qué.

Cuestiones relacionadas