iOS4 - cambio rápido de contexto - Excelente biblioteca

Cuando la aplicación ingresa en estado de funcionamiento en segundo plano, la cantidad de usos sucios de memoria es buena. En apple video se menciona que la memoria sucia debe reducirse tanto como podamos.iOS4 - cambio rápido de contexto

Pero en mi aplicación, estoy usando el controlador de navegación para abrir y cerrar vistas. Después de pasar de aproximadamente 20 páginas diferentes, los usos de memoria sucia alcanzan los 30 MB más o menos.

También en "dismissModalViewControllerAnimated" y "popViewControllerAnimated", no se llama dealloc.

tengo dos dudas:

Con cuánta memoria sucia que es aceptable para ir a vivir?
¿Cuál es el controlador de navegación alternativo que admite el botón Atrás?

Gracias de antemano.

Fuente

2010-07-06 Sunil

1. No 30 MB. Los dispositivos iOS anteriores solo tienen 128 MB de RAM, por lo que solo tu aplicación podría llenar eso por un 23% ... 2. Si realmente estás perdiendo 30 MB, probablemente no estás liberando algo, en algún lugar, no es 'UINavigationController' s culpa. –

Hola Douwe, Gracias por responder. Por qué dudo sobre UINavigationController porque, sigo presionando los controladores de vista en él.Y cuando saco los controladores de vista del controlador de navegación, no se llama al método dealloc donde estoy liberando las variables de instancia definidas. Y la memoria no se borra utilizada por todas estas variables de instancia. ¿Estoy haciendo algo mal? ¿Debo borrar las variables de instancia en otro lugar y no en dealloc? – Sunil

¿Tiene alguna otra referencia a sus controladores de vista en otra parte de su aplicación? Si los está mostrando, pero todavía tiene una referencia en otro lugar para el controlador, no recibirá GCed – blueberryfields

Es posible que aún tenga sus UIViewControllers retenidos si no se llama a dealloc.

Quizás esté configurando delegados u otras clases en estos UIViewControllers que conservaron y referenciaron una copia de seguridad del árbol (referencias circulares).

Una forma de solucionar este problema es sobrecargar retener y liberar en su UIViewController y establecer un punto de interrupción y registrar el retainCount.

Aquí hay un fragmento mágico que dejo corriendo que me ayuda mucho cuando no puedo entender por qué todavía estoy reteniendo algo.

- (id)retain 
{ 
    NSLog(@"retain \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]); 
    return [super retain]; 
} 
- (void)release 
{ 
    NSLog(@"release \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]); 
    [super release]; 
} 
- (id)autorelease 
{ 
    NSLog(@"autorelease \t%s \tretainCount: %i", __PRETTY_FUNCTION__ , [self retainCount]); 
    return [super autorelease]; 
}

__PRETTY_FUNCTION__ es una macro especial oculta en el ruido metálico que le da un Objective-C nombre de la función bonita como una matriz de caracteres.

Fuente

2011-02-11 08:09:08

Cuando un iOS comienza a quedarse sin memoria, intenta eliminar los procesos en segundo plano que están utilizando la mayor cantidad de memoria. Entonces, aunque no existe un número absolutamente bueno, es buena idea minimizar la cantidad de memoria que usa. Dejarlo en 30Mb equivale a garantizar que su aplicación será eliminada
A menos que desee cambiar su UI, no es necesario usar otra cosa que UINavigationController para ocuparse de su botón Atrás. Creo que el problema aquí es que si dealloc no se llama en un pop o despedir, usted tiene fugas una memoria

Casi todos los controladores de vista han de datos que se almacena en caché de manera efectiva y se puede regenerar cuando la aplicación vuelve al primer plano . Piense en los datos que publica cuando recibe una advertencia de memoria cuando se ejecuta la aplicación. (Estás respondiendo a las advertencias de memoria, ¿no?) Son esas cosas las que deberían publicarse cuando pasas a un segundo plano.

Fuente

2011-02-11 10:37:03

iOS4 - cambio rápido de contexto

Respuesta

Cuestiones relacionadas