objective c - mini - Desactivación de iOS 6 de la vista Se descargará y se moverá a didRecibaMemoryWarning

ios 10.0 descargar

Question

Soy un nuevo desarrollador a punto de lanzar mi primera aplicación. Estoy confundido acerca de la desaprobación de viewDidUnload como se describe a continuación en las notas de lanzamiento de iOS 6 de Apple:

En iOS 6, los métodos viewWillUnload y viewDidUnload de UIViewController ahora están en desuso. Si estaba usando estos métodos para liberar datos, use el método didReceiveMemoryWarning en su lugar. También puede usar este método para liberar referencias a la vista del controlador de vista si no se está utilizando. Necesitaría probar que la vista no está en una ventana antes de hacer esto.

¿Por qué está pasando esto? ¿Qué pautas debo seguir para garantizar que este cambio no cause problemas de rendimiento en mi aplicación?

Gracias.

Answer 1

En iOS 6 deberíamos lanzar vistas por nosotros mismos, hacer algo como esto

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

Answer 2

En iOS 6, las vistas nunca se descargan.

Esto significa que loadView y viewDidLoad solo se llaman una vez, y viewDidUnload nunca se llama. Entonces, si su controlador de vista usa viewDidUnload para manejar condiciones de poca memoria, entonces tendrá que cambiar.

Si desea responder a las condiciones de poca memoria, implemente didReceiveMemoryWarning y libere sus datos y objetos temporales en este método.

Answer 3

Según Apple, han mejorado la administración de la memoria interna para vistas lo suficiente como para que las ganancias logradas al destruir cosas en viewWill/DidUnload sean mínimas. Además, tienen datos que sugieren que muchas aplicaciones fallan porque las aplicaciones no manejan adecuadamente esas notificaciones y hacen "otras" cosas no asociadas con la descarga de vistas.

Finalmente, una advertencia de memoria ahora se verifica como la primera y única advertencia que recibirá antes de que la aplicación finalice debido a poca memoria, por lo que es realmente el lugar para manejar los problemas de memoria.

Así que, básicamente, simplemente elimine los métodos viewWillUnload y viewDidUnload . Maneje los problemas de memoria en didReceiveMemoryWarning y cualquier otra administración de controlador de vista en los lugares apropiados.

EDITAR

¿Puedo preguntar: cuáles son esos "lugares apropiados"? Solía ​​usar ViewdidUnload en ciertas situaciones donde la vista [Will / Did] Disappear no era del todo adecuada. Como ir más abajo en la pila del controlador de navegación. ¿Te importaría elaborar más sobre eso? - Dan1one

Eso depende. Sé que eso no es lo que quieres escuchar, pero es la verdad :-)

En general, debes evitar la asimetría. Por lo tanto, debe "deshacer" una operación utilizando el método simétrico desde el que "hizo" el original. En general, debería poder hacer todo el viewDidUnload tipo didReceiveMemoryWarning en didReceiveMemoryWarning y dealloc .

Esto realmente no debería causar un cambio, porque de todos modos tenía que duplicar la mayor parte de ese código en ambos lugares.

No sé qué quiere decir con "ir más abajo en la pila del controlador de navegación", por lo que tendrá que aclarar ese ejemplo para que pueda proporcionar una respuesta útil.

Uno de los problemas con el uso de viewDidDisappear y viewDidAppear fue que era difícil saber cuándo aparecía la vista porque en realidad estaba apareciendo, o porque una vista que estaba encima estaba desapareciendo ... causando que apareciera.

Se supone que estas piezas de API te ayudarán a resolver esos problemas:

- (BOOL)isMovingFromParentViewController
- (BOOL)isMovingToParentViewController
- (BOOL)isBeingDismissed
- (BOOL)isBeingPresented