Esto es para las últimas versiones de iOS (modificado con Xcode 9.3, Swift 4.1 ). A continuación se detallan todas las etapas que hacen que el ciclo de vida sea UIViewControllercompleto.
loadView()
loadViewIfNeeded()
viewDidLoad()
viewWillAppear(_ animated: Bool)
viewWillLayoutSubviews()
viewDidLayoutSubviews()
viewDidAppear(_ animated: Bool)
viewWillDisappear(_ animated: Bool)
viewDidDisappear(_ animated: Bool)
Déjame explicarte todas esas etapas.
1) loadView
Este evento crea / carga la vista que administra el controlador. Se puede cargar desde un archivo nib asociado o un vacío UIViewsi se encontró nulo. Esto lo convierte en un buen lugar para crear sus vistas en código mediante programación.
Aquí es donde las subclases deberían crear su jerarquía de vista personalizada si no están usando una punta. Nunca debe ser llamado directamente. Solo anule este método cuando cree vistas mediante programación y asigne la vista raíz a la viewpropiedad No llame al método super cuando anule
loadView
2) loadViewIfNeeded
Si viewControlleraún no se ha configurado la vista de corriente , este método cargará la vista, pero recuerde, esto solo está disponible en iOS> = 9.0. Entonces, si es compatible con iOS <9.0, no espere que aparezca en la imagen.
Carga la vista del controlador de vista si aún no se ha configurado.
3) viewDidLoad
El viewDidLoadevento solo se llama cuando la vista se crea y se carga en la memoria, pero los límites de la vista aún no están definidos. Este es un buen lugar para inicializar los objetos que usará el controlador de vista.
Llamado después de que la vista ha sido cargada. Para los controladores de vista creados en código, esto es después de -loadView. Para los controladores de vista no archivados desde una punta, esto es después de que se establece la vista.
4) viewWillAppear
Este evento notifica viewControllercuando aparece la vista en la pantalla. En este paso, la vista tiene límites definidos pero la orientación no está establecida.
Se llama cuando la vista está a punto de hacerse visible. El valor predeterminado no hace nada.
5) viewWillLayoutSubviews
Este es el primer paso en el ciclo de vida donde se finalizan los límites. Si no está utilizando restricciones o diseño automático, probablemente desee actualizar las subvistas aquí. Esto solo está disponible en iOS> = 5.0. Entonces, si es compatible con iOS <5.0, no espere que aparezca en la imagen.
Llamado justo antes de que se invoque el método de diseño de vistas del controlador de vista. Las subclases pueden implementarse según sea necesario. El valor predeterminado es un nop.
6) viewDidLayoutSubviews
Este evento notifica al controlador de vista que las subvistas han sido configuradas. Es un buen lugar para realizar cambios en las subvistas después de que se hayan configurado. Esto solo está disponible en iOS> = 5.0. Entonces, si es compatible con iOS <5.0, no espere que aparezca en la imagen.
Se invoca justo después de invocar el diseño de vista del controlador de vista. Las subclases pueden implementarse según sea necesario. El valor predeterminado es un nop.
7) viewDidAppear
El viewDidAppearevento se dispara después de que la vista se presenta en la pantalla. Lo que lo convierte en un buen lugar para obtener datos de un servicio de fondo o una base de datos.
Se llama cuando la vista se ha transferido completamente a la pantalla. El valor predeterminado no hace nada
8) viewWillDisappear
El viewWillDisappearevento se dispara cuando se presenta la vistaviewController está a punto de desaparecer, descartar, cubrir u ocultar detrás de otro viewController. Este es un buen lugar donde puede restringir sus llamadas de red, invalidar el temporizador o liberar objetos vinculados a eso viewController.
Se llama cuando la vista se descarta, se cubre o se oculta.
9) viewDidDisappear
Este es el último paso del ciclo de vida que cualquiera puede abordar, ya que este evento se dispara justo después de la vista presentada viewController ha desaparecido, descartado, cubierto u oculto.
Llamado después de que la vista fue desestimada, cubierta u oculta. El valor predeterminado no hace nada
Ahora, según Apple, cuando implemente estos métodos, recuerde llamar a la superimplementación de ese método específico.
Si subclasifica UIViewController, debe llamar a la súper implementación de este método, incluso si no está utilizando una NIB. (Para su comodidad, el método init predeterminado lo hará por usted y especificará nulo para ambos argumentos de estos métodos). En la NIB especificada, el proxy Propietario del archivo debe tener su clase establecida en su subclase de controlador de vista, con la salida de vista conectado a la vista principal. Si invoca este método con un nombre nib nib, entonces el -loadViewmétodo de esta clase intentará cargar una NIB cuyo nombre es el mismo que la clase de su controlador de vista. Si de hecho no existe tal NIB, debe llamar -setView:antes de -viewinvocarlo o anular el -loadViewmétodo para configurar sus vistas mediante programación.
Espero que esto haya ayudado. Gracias.
ACTUALIZACIÓN : como @ThomasW señaló dentro del comentario viewWillLayoutSubviewsy viewDidLayoutSubviewstambién se le llamará en otras ocasiones cuando se cargan subvistas de la vista principal, por ejemplo, cuando se cargan las celdas de una vista de tabla o vista de colección.
ACTUALIZACIÓN : como señaló @Maria en el comentario, loadViewse actualizó la descripción de
