iOS의 viewWillAppear: 메서드의 본질과 사용 방법

viewWillAppear란

viewWillAppear는 UIKit이 View를 윈도우 계층 구조에 추가하기 직전에 호출하는 UIViewController 메서드입니다. 이 시점에서 View는 Auto Layout 패스를 거친 후 최종 크기를 가지고 있지만, 아직 사용자에게 표시되지 않습니다 — 전환 애니메이션이 아직 시작되지 않았거나 진행 중입니다. 개발자는 이 메서드를 재정의하여 화면이 표시될 때마다 수행해야 하는 작업을 실행합니다.

한 번만 트리거되는 viewDidLoad와 달리, viewWillAppear는 화면이 표시되려고 할 때마다 호출됩니다: 초기 열기, 자식 컨트롤러에서 돌아올 때, 모달 창을 닫은 후, TabBar 탭을 전환할 때. 이는 인터페이스 상태를 최신으로 유지하기 위한 핵심 메서드입니다.

이 메서드는 Bool 타입의 animated 매개변수를 받습니다. 화면 표시에 애니메이션이 수반되면 true입니다. 이 매개변수는 일관된 동작을 위해 유사한 매개변수가 있는 NavigationBar 및 TabBar 메서드에 전달하기 편리합니다.

viewWillAppear가 호출되는 시점

viewWillAppear 호출의 시점은 탐색 유형에 따라 다르지만, 일반 규칙은 동일합니다: 메서드는 View가 표시되기 전에 트리거됩니다. 주요 시나리오를 살펴보겠습니다.

첫 화면 열기 시

viewDidLoad 후, UIKit은 표시 준비를 시작합니다: View가 계층 구조에 추가되고, 레이아웃 패스가 트리거되며, 전환 애니메이션이 시작되기 직전에 viewWillAppear가 호출됩니다. 이 시점에서 화면은 아직 표시되지 않았지만, 모든 서브뷰의 크기는 정확하며, 해당 콘텐츠를 안전하게 업데이트할 수 있습니다.

NavigationController에서 돌아올 때

사용자가 뒤로가기 버튼을 탭하거나 프로그래밍 방식으로 popViewController를 호출하면, UIKit은 이전 화면으로 돌아가 해당 viewWillAppear를 호출합니다. 이것이 viewWillAppear를 사용하는 주요 시나리오입니다 — 항목 추가 후 목록 업데이트 또는 설정 동기화에 사용됩니다.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    updateBadgeCount()
}

모달 창을 닫을 때

모달로 표시된 컨트롤러를 닫은 후, UIKit은 이를 표시한 컨트롤러의 viewWillAppear를 호출합니다. 이 시나리오는 델리게이트나 클로저를 사용하여 데이터를 다시 전달하는 경우 특별한 주의가 필요합니다 — viewWillAppear는 결과를 받은 후 화면이 업데이트되도록 보장합니다.

TabBar 탭 전환 시

TabBarController는 전환이 발생할 때마다 선택된 탭의 컨트롤러에서 viewWillAppear를 호출합니다. 탭에 동적 데이터(환율, 알림, 사용자 상태)가 표시되는 경우, viewWillAppear는 이를 업데이트하기 위한 이상적인 위치입니다.

viewWillAppear에서의 실용적인 작업

viewWillAppear는 다른 메서드에서는 수행이 불가능하거나 최적이 아닌 여러 특정 작업을 해결합니다. 주요 작업을 살펴보겠습니다.

테이블 데이터 업데이트

viewWillAppear의 가장 일반적인 사용법은 화면이 나타날 때마다 UITableView 또는 UICollectionView를 다시 로드하는 것입니다. 이전 화면에서 데이터가 변경되었을 수 있는 경우(항목 추가, 상태 변경), viewWillAppear에서 reloadData를 호출하면 사용자가 최신 정보를 볼 수 있습니다.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    viewModel.synchronize()
    tableView.reloadData()
}

NavigationBar 및 TabBar 구성

viewWillAppear에서 NavigationBar의 모양을 편리하게 구성할 수 있습니다: 숨기기/표시, 색상 변경, 큰 제목 설정. 화면마다 NavigationBar 스타일이 다른 경우, viewDidLoad는 한 번만 호출되므로 viewWillAppear가 이러한 변경을 위한 적절한 위치입니다.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    navigationController?.setNavigationBarHidden(
        false, animated: animated
    )
    navigationController?.navigationBar.prefersLargeTitles = true
    tabBarController?.tabBar.isHidden = false
}

임시 알림 구독

화면이 표시되는 동안에만 의미가 있는 알림(키보드 알림, 콘텐츠 변경 알림)은 viewWillAppear에서 구독하고 viewDidDisappear에서 구독 해지합니다. 이는 화면이 활성화되지 않은 경우 불필요한 핸들러를 방지하고 메모리 누수로부터 보호합니다.

UI 상태 복원

앱에 의해 화면이 숨겨지거나 최소화될 수 있는 경우, viewWillAppear는 UI 상태를 복원하기에 편리한 위치입니다: 세그먼트 전환, 스크롤 위치 복원, 임시 변경 재설정. 사용자는 화면이 나타날 때마다 예측 가능한 상태로 화면을 받습니다.

배지 및 카운터 업데이트

읽지 않은 메시지, 평점 또는 알림 카운터를 표시하는 화면에서 viewWillAppear는 이를 업데이트하기에 적절한 위치입니다. 사용자가 다른 화면에서 수량을 변경했을 수 있는 경우, 여기서 재계산 및 UITabBarItem.badgeValue 또는 사용자 지정 표시기 업데이트가 호출됩니다. 이를 통해 사용자가 다른 화면에 얼마나 오래 있었는지에 관계없이 항상 최신 숫자를 볼 수 있습니다.

collectionView 작업에는 특별한 주의가 필요합니다: 화면의 데이터가 카운터나 상태를 포함하는 셀의 그리드로 표시되는 경우, viewWillAppear에서의 업데이트는 선택적이어야 합니다. 전체 reloadData 대신 보이는 셀에는 reloadItemsAtIndexPaths를 사용하여 깜빡임과 스크롤 위치 손실을 방지합니다.

viewWillAppear와 viewDidLoad의 차이점

viewWillAppear와 viewDidLoad의 차이를 이해하는 것은 올바른 UIViewController 아키텍처의 기초입니다. 이 메서드들은 호출 빈도, 컨텍스트 및 목적이 다릅니다.

viewDidLoad는 한 번 호출되며 시간이 지나도 변경되지 않는 구성에 적합합니다: 셀 등록, 델리게이트 설정, 상수 초기화. viewWillAppear는 표시될 때마다 호출되며 반복이 필요한 작업에 적합합니다: 데이터 업데이트, 표시 요소 구성, 상태 동기화.

황금 규칙: 작업을 한 번만 실행해야 하는 경우 viewDidLoad에 배치합니다. 화면으로 돌아갈 때마다 실행해야 하는 경우 viewWillAppear에 배치합니다.

viewWillAppear의 일반적인 실수

잘못된 사용은 성능 문제, 과도한 업데이트 및 일관되지 않은 인터페이스 상태를 초래할 수 있습니다. 가장 일반적인 실수를 살펴보겠습니다.

첫 번째 실수 — viewDidLoad 로직의 중복. viewDidLoad와 viewWillAppear 모두에서 테이블 셀을 등록하면 일회성 설정으로 충분함에도 불구하고 등록이 여러 번 실행됩니다. 모든 일회성 구성은 viewDidLoad로 이동하세요.

두 번째 실수 — 매 표시마다 무조건적인 reloadData. 데이터가 변경되지 않은 경우 테이블을 다시 로드하면 데이터 소스에 불필요한 쿼리와 셀 다시 그리기가 발생하여 성능이 저하됩니다. reloadData를 호출하기 전에 상태가 실제로 변경되었는지 확인하세요.

세 번째 실수 — 요청이 완료되기 전에 화면이 다시 숨겨질 수 있다는 점을 고려하지 않고 네트워크 요청 작업을 하는 경우. viewWillAppear에서 URLSession 요청을 시작하고 사용자가 즉시 다른 화면으로 이동하면 결과가 이미 숨겨진 View에 적용될 수 있습니다. 업데이트하기 전에 취소 가능한 작업을 사용하거나 isViewLoaded 및 window를 확인하세요.

네 번째 실수 — super 호출을 잊는 것. super.viewWillAppear를 호출하지 않으면 부모 컨트롤러(UINavigationController, UITabBarController)의 동작이 손상되고 제스처 및 전환 처리에 문제가 발생할 수 있습니다. super는 항상 호출해야 합니다.

다섯 번째 실수 — layoutIfNeeded를 호출하지 않고 제약 조건을 변경하는 것. viewWillAppear에서 프로그래밍 방식으로 제약 조건을 변경하면 UIKit이 즉시 적용하지 않습니다 — 변경 사항은 다음 레이아웃 패스까지 누적됩니다. 제약 조건 변경 후 변경 사항을 즉시 적용하려면 view.layoutIfNeeded()를 호출하세요. 이는 콘텐츠에 따라 달라지는 요소의 높이를 조정할 때 특히 중요합니다.

여섯 번째 실수 — viewWillAppear에서 애니메이션을 실행하려는 시도. 앞서 언급했듯이 UIKit은 여전히 전환 애니메이션을 처리 중이며, 사용자의 애니메이션이 시스템 애니메이션과 경쟁할 수 있습니다. 효과와 함께 요소를 표시해야 하는 경우 viewDidAppear에서 들어오는 애니메이션을 사용하고, viewWillAppear에서는 초기 상태만 구성하세요: 투명도 0, 스케일 0.8의 transform 등.

일곱 번째 실수 — animated 매개변수 무시. 일부 개발자는 viewWillAppear에서 animated 값을 확인하지 않고 애니메이션 유무에 따라 달라져야 하는 작업을 수행합니다. 예를 들어, animated = false인 경우 NavigationBar를 애니메이션 없이 숨길 수 있고, animated = true인 경우 애니메이션과 함께 숨겨 전환이 부드럽게 보이도록 할 수 있습니다. 항상 animated 매개변수를 적절한 UIKit 메서드에 전달하세요.

여덟 번째 실수 — 화면이 표시되지 않을 때 UI를 수정하는 것. viewWillAppear에서 네트워크 요청을 시작하고 해당 completion 블록이 화면이 이미 사라진 후에 UI를 업데이트하면 사용자가 깜빡임이나 일관되지 않은 상태를 보게 됩니다. 클로저에서 UI를 업데이트하기 전에 항상 isViewLoaded와 window를 확인하세요. 이 간단한 조치로 충돌과 불필요한 인터페이스 다시 그리기를 방지할 수 있습니다.