problem - iphone storage other

¿Cómo implementar didReceiveMemoryWarning?

Question

He desarrollado una aplicación para iPhone con reconocimiento de ubicación simple que está funcionando funcionalmente muy bien según nuestras expectativas, excepto en las condiciones de poca memoria del teléfono.

En condiciones de poca memoria del teléfono, mi aplicación simplemente se cuelga y si aumenta la memoria del teléfono al liberar algo de espacio, nuevamente comienza a funcionar bien sin ningún bloqueo.

cuando busqué en Google el problema encontré que en las condiciones de poca memoria el sistema operativo enviará didReceiveMemoryWarning a todos los controladores en la jerarquía actual para que cada uno de ellos implemente el método didReceiveMemoryWarning y también establezca iboutlet en nil para la vista que es actualmente no visible

También he leído en alguna parte que si la vista para ese controlador no es visible, se llamará al método setView con parámetro nil y si hay algunas variables de salida adjuntas para ver, habrá un problema al eliminarlas.

Entonces, con todas estas funciones, ¿qué es lo mejor para manejar la condición de memoria de bajo nivel creada por el Iphone al implementar los métodos didReceiveMemoryWarning y viewDidUnload ?

Por favor, proporcione un ejemplo o enlace adecuado si es posible para la solución del problema anterior.

Gracias.

Answer 1

En iOS 5 y anteriores.

Cuando el controlador recibe una advertencia de memoria, se llamará a didReceiveMemoryWarning. En ese momento, si la vista del controlador no está en la jerarquía de vista, la vista se establecerá en nil y viewDidUnload se invocará automáticamente. Entonces, las cosas que debemos hacer en viewDidUnload es liberar la subvista creada en viewDidLoad o creada desde Nib. Me gusta esto:

- (void)viewDidUnload
{
    self.subView = nil;
    self.subViewFromNib = nil;
}

- (void)didReceiveMemoryWarning
{
    self.someDataCanBeRecreatedEasily = nil;
    [super didReceiveMemoryWarning];
}

En iOS6.

El controlador no libera automáticamente la vista cuando recibe una advertencia de memoria. Por lo tanto, viewDidUnload nunca se llamará. Pero aún tenemos que liberar nuestra vista (incluida la vista secundaria) cuando ocurre una advertencia de memoria. Me gusta esto.

- (void)didReceiveMemoryWarning
{
    if ([self isViewLoaded] && [self.view window] == nil) {
        self.view = nil;
        self.subView = nil;
        self.subViewFromNib = nil;
    }
    self.someDataCanBeRecreatedEasily = nil;
    [super didReceiveMemoryWarning];
}

Tenga en cuenta que no llamamos a [vista propia] antes de saber que la vista está cargada. porque este método cargará automáticamente la vista si la vista no está cargada.

Tenga en cuenta que podemos liberar la vista solo cuando la vista no se agrega a una ventana.

Answer 2

Las advertencias de memoria son una señal para usted de que debe deshacerse de cualquier recurso que no sea absolutamente crítico. La mayoría de sus controladores se almacenarán en cachés de datos, datos intermedios u otros bits y piezas, a menudo para guardar el recálculo. Cuando reciben advertencias de memoria, deben comenzar a enjuagar todo lo que no necesitan de inmediato para funcionar.

La forma de determinar qué es "crítico" depende completamente del diseño de su aplicación. Un juego OpenGL, por ejemplo, puede determinar que las texturas actualmente en pantalla son valiosas y al ras texturas que no son visibles, o datos de nivel que están fuera de los límites del área de juego actual. Una aplicación con extensos registros de sesión (como un cliente de IRC) puede expulsarlos de la memoria y ponerlos en el disco.

Como observó, la advertencia se envía a cada controlador en su jerarquía, por lo que cada pieza debe determinar individualmente qué datos constituyen "críticos para la operación" y qué constituyen "prescindibles". Si los ha optimizado a todos y sigue recibiendo advertencias de memoria, lamentablemente es hora de volver a visitar el diseño de su aplicación central, ya que está excediendo los límites del hardware.

Answer 3

Para mi sorpresa, solo algunas aplicaciones en los ejemplos oficiales de iPhone implementan didReciveMemoryWarning . Puede usar el ejemplo de iPhoneCoreDataRecipes como referencia.

Algunas muestras (por ejemplo, TableViewSuite) incluso hacen algo más ;-)

Answer 4

También podría liberar memoria en didReceiveMemoryWarning , que asignó para variables estáticas en sus clases. Porque una vez que se asigna la memoria para las variables estáticas, no se liberará durante la ejecución de la aplicación.

Answer 5

Un ejemplo que estoy publicando ... que he copiado de algún lugar ... podría darte una idea ...

- (void)didReceiveMemoryWarning {

    // Release anything that''s not essential, such as cached data (meaning
    // instance variables, and what else...?)

    // Obviously can''t access local variables such as defined in method
    // loadView, so can''t release them here We can set some instance variables
    // as nil, rather than call the release method on them, if we have defined
    // setters that retain nil and release their old values (such as through use
    // of @synthesize). This can be a better approach than using the release
    // method, because this prevents a variable from pointing to random remnant
    // data.  Note in contrast, that setting a variable directly (using "=" and
    // not using the setter), would result in a memory leak.
    self.myStringB = nil;
    self.myStringD = nil;
    [myStringA release];// No setter defined - must release it this way
    [myStringC release];// No setter defined - must release it this way

    /* 3. MUST CONFIRM: NOT necessary to release outlets here - See override of
       setView instead.
    self.labelA = nil;
    self.imageViewA = nil;
    self.subViewA = nil;
     */
    // Releases the view if it doesn''t have a superview
    [super didReceiveMemoryWarning];
}

Answer 6

didReceiveMemoryWarning usted decidir qué hacer en didReceiveMemoryWarning . El sistema operativo le dice que la memoria es baja y que necesita liberar todo lo que pueda tan pronto como pueda. La idea es que debe liberar todos los datos en caché, descargar las vistas que no están visibles, etc. Los detalles son específicos de la aplicación.