Esta é a versão mais recente do iOS (modificada com Xcode 9.3, Swift 4.1 ). Abaixo estão todos os estágios que tornam o ciclo de vida UIViewControllercompleto.
loadView()
loadViewIfNeeded()
viewDidLoad()
viewWillAppear(_ animated: Bool)
viewWillLayoutSubviews()
viewDidLayoutSubviews()
viewDidAppear(_ animated: Bool)
viewWillDisappear(_ animated: Bool)
viewDidDisappear(_ animated: Bool)
Deixe-me explicar todas essas etapas.
1 loadView
Este evento cria / carrega a visualização que o controlador gerencia. Ele pode carregar de um arquivo de ponta associado ou vazio UIViewse nulo foi encontrado. Isso torna um bom lugar para criar suas visualizações no código programaticamente.
É aqui que as subclasses devem criar sua hierarquia de visualização customizada se não estiverem usando uma ponta. Nunca deve ser chamado diretamente. Substitua esse método apenas quando você criar visualizações de modo programático e atribuir a visualização raiz à viewpropriedade Não chame super método quando substituir o
loadView
2) loadViewIfNeeded
Se a visualização da corrente viewControllerainda não foi definida, esse método carregará a visualização, mas lembre-se de que isso estará disponível apenas no iOS> = 9.0. Portanto, se você suporta o iOS <9.0, não espere que ele entre em cena.
Carrega a visualização do controlador de visualização, se ainda não tiver sido definida.
3) viewDidLoad
O viewDidLoadevento é chamado apenas quando a visualização é criada e carregada na memória, mas os limites da visualização ainda não estão definidos. Este é um bom lugar para inicializar os objetos que o controlador de exibição usará.
Chamado após o carregamento da visualização. Para os controladores de exibição criados no código, isso é pós-loadView. Para controladores de exibição desarquivados de uma ponta, isso ocorre depois que a exibição é configurada.
4) viewWillAppear
Este evento notifica viewControllersempre que a exibição aparece na tela. Nesta etapa, a vista possui limites definidos, mas a orientação não está definida.
Chamado quando a exibição está prestes a se tornar visível. O padrão não faz nada.
5) viewWillLayoutSubviews
Esta é a primeira etapa do ciclo de vida em que os limites são finalizados. Se você não estiver usando restrições ou Layout automático, provavelmente desejará atualizar as subvisões aqui. Isso está disponível apenas no iOS> = 5.0. Portanto, se você suporta o iOS <5.0, não espere que ele entre em cena.
Chamado imediatamente antes do método layoutSubviews da visualização do controlador de exibição ser chamado. As subclasses podem ser implementadas conforme necessário. O padrão é um nop.
6 viewDidLayoutSubviews
Este evento notifica o controlador de exibição que as subvisões foram configuradas. É um bom lugar para fazer alterações nas subvisões depois que elas foram definidas. Isso está disponível apenas no iOS> = 5.0. Portanto, se você suporta o iOS <5.0, não espere que ele entre em cena.
Chamado logo após o método layoutSubviews da visualização do controlador de exibição ser chamado. As subclasses podem ser implementadas conforme necessário. O padrão é um nop.
7) viewDidAppear
O viewDidAppearevento é acionado depois que a visualização é apresentada na tela. O que o torna um bom local para obter dados de um serviço de back-end ou banco de dados.
Chamado quando a visualização foi totalmente transferida para a tela. O padrão não faz nada
8) viewWillDisappear
O viewWillDisappearevento é acionado quando a exibição apresentada viewControllerestá prestes a desaparecer, descartar, encobrir ou ocultar atrás de outra viewController. Este é um bom lugar para restringir as chamadas de rede, invalidar o timer ou liberar objetos vinculados a isso viewController.
Chamado quando a exibição é descartada, coberta ou oculta.
9 viewDidDisappear
Esta é a última etapa do ciclo de vida que qualquer pessoa pode abordar, pois esse evento é acionado logo após a exibição da apresentação viewControllerter sido desaparecida, descartada, coberta ou oculta.
Chamado depois que a vista foi descartada, coberta ou oculta de outra forma. O padrão não faz nada
Agora, de acordo com a Apple, ao implementar esses métodos, lembre-se de chamar a superimplementação desse método específico.
Se você subclassificar UIViewController, deverá chamar a super implementação deste método, mesmo se você não estiver usando um NIB. (Por conveniência, o método init padrão fará isso por você e especificará nulo para os argumentos de ambos os métodos.) Na NIB especificada, o proxy Proprietário do Arquivo deve ter sua classe definida na subclasse do controlador de exibição, com a saída de exibição conectado à vista principal. Se você chamar esse método com um nome de ponta nula, o -loadViewmétodo dessa classe tentará carregar uma NIB cujo nome seja o mesmo da classe do seu controlador de exibição. Se esse NIB de fato não existir, você deverá chamar -setView:antes de -viewser chamado ou substituir o -loadViewmétodo para configurar suas visualizações programaticamente.
Espero que isso tenha ajudado. Obrigado.
UPDATE - Como @ThomasW apontou no comentário viewWillLayoutSubviewse viewDidLayoutSubviewstambém será chamado em outros momentos quando subvistas da vista principal são carregadas, por exemplo, quando células de uma exibição de tabela ou coleção são carregadas.
ATUALIZAÇÃO - Como @Maria apontou dentro do comentário, a descrição de loadViewfoi atualizada
